Quoting Checklist for a Fixed-Price CRM Migration

Quoting Checklist for a Fixed-Price CRM Migration

A fixed-price CRM migration quote is only as good as the scope document behind it. Hand a vendor a vague brief — "move everything from Salesforce to HubSpot" — and you'll get either a padded quote that prices in every unknown, or a lowball that triggers change orders the moment your custom objects surface. Either way, you lose.

This checklist gives you the exact information to collect before you request a quote, so the number you get back is honest, complete, and comparable across vendors. It covers the data migration itself — not your wider CRM implementation, workflow rebuild, or staff retraining.

For a broader planning companion, see our Ultimate CRM Data Migration Checklist. For a breakdown of how pricing models shift risk, read Fixed-Fee vs Time-and-Materials Data Migration Providers Compared. If you are still evaluating your options, our buyer's guide to CRM data migration services compares self-service tools, managed providers, and in-house builds.

Why Fixed-Price Quoting Fails Without Proper Scoping

Fixed-price data migration means the provider commits to moving specified objects, fields, and history from system A to system B for one pre-agreed price, regardless of how many hours the work takes. The vendor estimates real effort, adds a risk buffer for unknowns, and you pay that buffer whether the risks materialize or not. Federal procurement guidance treats firm-fixed-price contracts as appropriate when specifications are reasonably definite and the cost impact of uncertainty can be estimated up front — the same logic applies here. (acquisition.gov)

When scope is vague, vendors have two rational choices: pad the quote by 30–50% to cover unknowns, or quote low and recover margin through change orders. The checklist below eliminates that ambiguity at the point where it's cheapest to eliminate: before the quote.

Fixed-Price vs. Time-and-Materials: Minimum Viable Decision Matrix

Before committing to a fixed-price engagement, verify that your situation meets the conditions that make fixed-price feasible:

If more than two rows fall in the "No" column, a T&M engagement with a defined discovery phase is lower risk than a fixed-price quote built on assumptions. The discovery output then becomes the scope document for a subsequent fixed-price migration.

Cost Estimation Framework

The single most common question buyers ask — "how much does a CRM migration cost?" — has no universal answer, but it does have a structured estimation model. The variables below map directly to engineering hours, and each tier roughly doubles complexity relative to the previous:

Object and Record Baseline

These ranges assume reasonably clean data. Add 20–40% for migrations requiring vendor-side deduplication, 15–25% for regulated-data handling (HIPAA, GDPR), and 10–20% for parallel delta-sync periods exceeding 48 hours.

Complexity Scoring Rubric

Score your migration on five axes before requesting quotes. Vendors who ask you these questions are pricing real work; vendors who don't are guessing.

Score 0–2: Straightforward migration, lower end of ranges above. Score 3–5: Moderate complexity, mid-range. Score 6–10: High complexity, upper range or custom quote required.

Step 1: Inventory Every Object and Record Count

The foundation of any CRM migration quote is a complete object-by-object record count from your source system. Not a rough guess — an actual export or API query.

For each object, document:

• Object name (standard and custom)
• Record count (total, and if possible, active vs. archived)
• Custom field count per object
• Field types that require transformation (multi-select picklists, formula fields, lookup/relationship fields, rich text)
• Whether the object has child records (e.g., line items under deals, activities under contacts)

Record count alone doesn't determine price. A clean 50,000-contact database with standard fields can be simpler to migrate than a 3,000-contact database with 30 custom objects and nested associations. But record count sets the baseline.

Step 2: Map Custom Objects and Associations

Custom objects and their associations are the single biggest cost variable in CRM migrations — and the most frequently underscoped. Standard objects (contacts, companies, deals) move with moderate effort. The moment your source CRM has custom objects with lookup fields, many-to-many joins, or labeled associations, complexity increases substantially.

Every CRM platform models relationships differently:

• Salesforce uses lookup and master-detail relationships, with polymorphic fields (like WhoId and WhatId on activities) that can point to multiple object types.
• HubSpot uses an Associations API with labeled association types. Custom objects are an Enterprise-tier feature, with each Enterprise account supporting up to ten custom object definitions. Association-label imports require Professional or Enterprise. (knowledge.hubspot.com)
• Pipedrive has no custom objects. Migrating to Pipedrive from a CRM with custom objects means flattening your data model or accepting that certain relationships cannot be represented.
• Dynamics 365 / Dataverse uses alternate keys and supports upsert for integration scenarios, but Microsoft notes a performance penalty compared with straight create operations.

Translating polymorphic links from a system that supports them into a target CRM with strict, typed associations requires complex routing logic:

// Salesforce Task with polymorphic references
{
  "Subject": "Follow up call",
  "WhoId": "0035000000abcde",  // Can be Contact or Lead
  "WhatId": "006500000012345"  // Can be Account, Opportunity, Campaign, or Custom Object
}

If the target system doesn't support polymorphic fields, the migration engineer must resolve each ID prefix and map the task to the correct distinct object type. That routing logic takes engineering time proportional to the number of object types in play.

Schema Mismatch Resolution Paths

When the target CRM cannot represent a source field type, four resolution paths exist:

Each resolution path must be decided before the vendor can lock a fixed price. Undecided schema mismatches are the migration equivalent of undefined scope.

For your quote request, document:

• Total number of custom objects
• Parent-child and many-to-many relationships between them
• Whether associations carry labels (e.g., "Decision Maker," "Billing Contact")
• Any junction objects or polymorphic lookup fields
• Same-object relationships (parent-child companies, contact hierarchies)
• Identified schema mismatches and your chosen resolution path for each

For a deeper technical walkthrough, see our guide on how to migrate custom objects and associations between CRMs.

Step 3: Define History Depth and Activity Scope

How much history you migrate directly affects both price and timeline. Break this into explicit decisions:

Activity history migration is expensive because it's relational. Each email, call, or note must be re-linked to the correct contact, company, and deal in the target system. In a HubSpot source, extracting ticket history requires the Engagements API, which creates an N+1 query problem at scale — a portal with 50,000 tickets averaging 8 engagements each needs roughly 450,000+ API calls just for extraction.

Smaller CRMs hide this too. Pipedrive's entity responses expose files_count, notes_count, email_messages_count, and activity counts per record, and its list endpoints cap page size at 500 items. 10,000 deals can conceal a much larger migration payload once every child record and file is counted. (developers.pipedrive.com)

"Migrate all history" and "migrate the last 24 months of activity" produce very different quotes. Be explicit.

Step 4: Size Your Attachments and Files

Attachments are the hidden cost multiplier in CRM migrations. They're slow to extract, slow to upload, and they consume API rate limits faster than structured data.

Quantify:

• Total attachment storage in your source CRM (GB)
• File count and average file size
• File types (PDFs, images, contracts, call recordings, email attachments)
• Where they're stored — inline in the CRM database, in an external document management system like SharePoint, or in a cloud storage bucket
• Target system file size limits — if your source allows 50 MB attachments and your target caps them at 20 MB, the scope must define how to handle oversized files

Attachments stored inline in CRM databases (common in Dynamics 365, where the default attachment size limit is 5 MB but can be raised to 128 MB) often account for the majority of storage consumption and the slowest portion of any migration. Salesforce stores files as ContentVersion records that must be queried, downloaded as binary data, and often Base64-encoded before insertion into the target. Zendesk uses tokenized URLs. Each approach requires different extraction logic.

As a rough operational benchmark: 10,000 text files (averaging 50 KB each, ~500 MB total) migrate in minutes under normal API conditions. 10,000 call recordings (averaging 5 MB each, ~50 GB total) typically require 8–20+ hours depending on upload bandwidth and rate limits. Always scope by gigabytes, not just file count.

If your quote doesn't explicitly state whether attachments are in-scope, ask. This is the most common source of post-signature change orders.

Step 5: Define Matching Keys and Deduplication Rules

A matching key is the field or rule that decides whether a record is created, updated, merged, or rejected during the migration. A serious quote specifies the key for each object: email, company domain, external ID, account number, or a composite rule.

Platform-specific upsert behavior matters here:

• In Salesforce, upsert behavior is defined by the chosen external ID field. Bulk API 2.0 upserts require an external ID, and the REST API returns an error rather than updating when one external ID matches multiple existing records. (developer.salesforce.com)
• In HubSpot, association imports need unique identifiers, and existing emails, meetings, notes, and tasks cannot be updated via import. (knowledge.hubspot.com)
• In Dataverse, alternate keys support upsert for integration scenarios, but character restrictions can break PATCH upserts when key values include reserved characters.

If no trustworthy matching key exists, the quote needs a data-prep and deduplication step rather than pretending the load can stay fixed-fee. Also define:

• Who owns data cleanup — if the client cleans data before migration, the quote covers only the transfer. If the vendor writes deduplication scripts, the price increases.
• Rules for orphaned records — contacts linked to an Account ID that no longer exists can be dropped, linked to a placeholder account, or flagged for manual review. Each choice has a different engineering cost.

Step 6: Document Transformations and Schema Field Handling

A transformation rule is any rule that changes data meaning, format, or allowed values between systems. Quotes should list:

• Pipeline-stage remaps and status normalization
• Owner remaps (especially for inactive users who no longer have accounts in the target)
• Multi-select picklist parsing
• Currency and timezone conversions
• HTML-to-markdown or plain-text conversion
• Lookup and enum rewrites — Pipedrive can return custom option values as plain IDs rather than labels, so enum translation may be part of the scope

Treat the mapping sheet as an executable spec. If you don't already have one, build it before asking any provider to lock a price. For a field-level format, see our mapping cheat sheet.

System fields require separate attention. When you insert a record into a new CRM via API, the system stamps CreatedDate as the moment of insertion and CreatedBy as the API user running the migration. For teams relying on historical pipeline velocity metrics or cohort analysis, this destroys reporting accuracy.

• Salesforce supports audit-field preservation through the "Set Audit Fields upon Record Creation" permission. (help.salesforce.com)
• HubSpot makes Create date read-only for all objects except deals, and properties like Original source cannot be manually edited.

If preserving these fields matters, the quote must specify which fields are writable, which permissions are required, and what fallback applies when the target blocks direct writes.

Also document your strategy for inactive users. If a sales rep left the company in 2021, their user account likely won't exist in the new CRM. Define whether their records map to a placeholder "Legacy User," to their manager, or to a named archive account — this decision must be made before the load runs.

Step 7: Catalog Active Integrations

Every third-party integration touching your CRM is a potential disruption point during migration. Document:

• Integration name and direction (one-way sync, bidirectional, event-triggered)
• Which CRM objects it reads or writes
• Whether it runs during business hours (relevant because API rate limits are shared across all consumers hitting the same CRM instance)

On HubSpot, the daily API limit is shared across all private apps hitting a single account. Your migration script, your marketing automation tool, and your sales engagement platform all draw from the same rate-limit bucket. A migration running alongside active integrations exhausts that budget faster, which extends timeline or forces a blackout window.

How API Rate Limits Affect Your Migration Timeline

API rate limits cap how fast data can be read from the source and written to the target. They vary dramatically by platform and subscription tier, and they directly change the cutover plan.

Salesforce enforces a rolling 24-hour API request pool of 100,000 base calls (Enterprise Edition) plus 1,000 per user license. The Bulk API 2.0 operates on a separate allocation of 15,000 batches per 24-hour window, with each batch handling up to 10,000 records. Theoretical maximum throughput is 150 million records per day, but real-world migrations rarely approach that due to triggers, validation rules, and concurrent job limits capped at 25. (developer.salesforce.com)

HubSpot limits private apps to 190 requests per 10 seconds and 650,000–1,000,000 daily requests depending on subscription tier. The Imports API is significantly more efficient for bulk loading — up to 80 million rows per day — but the CRM Search API used for verification is limited to 4 requests per second per authentication token. (developers.hubspot.com)

Pipedrive uses a token-based rate-limiting system. The daily budget is calculated as 30,000 base tokens × plan multiplier × number of seats. On a 10-person Growth plan, that's 600,000 tokens per day. Each API endpoint has a different token cost, and there is no bulk API — each record update requires its own call. Pipedrive recommends API v2 where possible because it has lower token cost per operation.

Dynamics 365 / Dataverse enforces service-protection limits per user with five-minute sliding windows across three dimensions: request count, combined execution time, and concurrency. Microsoft's current default example is 6,000 requests, 20 minutes of execution time, and 52 concurrent requests per web server — values that can change by environment and are not guaranteed in SLAs.

Timeline Estimation Model

The table below gives rough estimates for migrations with no attachments and clean data. Add time for each complicating factor listed.

Add time for:

• Attachments >10 GB: +1–3 days depending on volume and file size
• Delta sync period: +4–16 hours per sync pass
• Deduplication logic (vendor-side): +1–3 days
• Regulated data handling: +1–2 days for additional controls and documentation
• Poor data quality requiring mid-migration intervention: +1–5 days

Step 8: Plan the Cutover and Delta Sync

How you switch from the old CRM to the new one defines the final phase of the migration. A hard cutover over a weekend is cheaper. Running both systems in parallel requires a delta sync, which increases engineering scope.

Key scoping questions:

• Is a system freeze possible? Can the sales and support teams stop updating the source CRM on Friday at 5 PM and log into the new CRM on Monday at 8 AM?
• If not, do you need a delta sync? A delta sync captures records created or modified after the initial bulk migration and pushes them to the target. This requires the source system to have reliable LastModifiedDate tracking or webhooks. Legacy systems without proper modification timestamps may require polling-based workarounds that introduce brief sync delays.
• Is a rollback point defined? If something goes wrong after the full load, what's the decision point for rolling back vs. fixing forward? This decision point should be documented in the contract, not decided under pressure at 2 AM on a Sunday.

In a fixed-price quote, confirm explicitly whether account connection, sample runs, the full load, the delta pass, the freeze window, and the rollback decision point are all included or billed separately.

Step 9: Specify Validation and Acceptance Criteria

Validation confirms that data transferred correctly. Acceptance criteria are the contractual conditions under which you sign off that the migration is complete. These are technically distinct: validation is a process; acceptance is a threshold. Both must be defined in writing before work starts.

Production-grade validation typically includes:

• Record-count parity between source and target, per object
• Field-level spot checks on a sample of records across each object
• Association and relationship verification — do deals still link to the right contacts and companies?
• Attachment integrity — are files accessible and associated with their parent records?
• Referential integrity checks — no orphaned child records
• Owner, stage, and timestamp verification — are preserved system fields correct?

Sample Size Guidance for Validation

"Spot check a sample" is not an acceptance criterion. Use these minimums as a starting point:

For each sampled record, verify: all custom field values match source, all associations are intact, all attachments open correctly, and system timestamps match (where preserved). A migration that passes count parity but fails field-level checks for 3% of records is not complete — field-level error rates above 0.5% typically indicate a systematic mapping error requiring a corrective reload.

Step 10: Lock Exclusions in Writing

The strongest defense against scope creep is a written exclusion list agreed before work starts. In fixed-price engagements, everything not explicitly in scope should be explicitly out of scope.

Common items to address:

• Workflow and automation rebuilds in the target CRM
• Report and dashboard recreation
• User training on the new system
• Integration reconnection or rebuilding
• Data cleanup or deduplication before migration
• Custom field creation in the target system
• Permission and role configuration

A data migration provider moves your data. They don't rebuild your Salesforce Flows in HubSpot Workflows, retrain your sales team, or reconnect your billing system. For more on this distinction, see why data migration isn't implementation.

Data Privacy and Compliance Scoping

GDPR, HIPAA, and industry-specific regulations affect migration scope in concrete ways that must be decided before work begins, not after.

Classification decisions required before scoping:

1. Does the migration touch personal data covered by GDPR? If yes, a Data Processing Agreement (DPA) with the vendor is legally required. The DPA must specify legal basis for processing, data categories transferred, sub-processors used, and deletion timelines.

2. Does the migration touch protected health information (PHI)? If yes, a Business Associate Agreement (BAA) is required before any data leaves your systems. The migration vendor becomes a business associate under HIPAA at the moment they access PHI.

3. What is the data residency requirement? Some regulated industries require that data remain within specific geographic boundaries during transit and staging. Confirm where the vendor's staging infrastructure is located.

4. What are the retention and deletion terms for staging data? Migration vendors typically hold a copy of your data in a staging environment during the project. Your compliance requirements may mandate a specific deletion timeline and a deletion certificate.

5. Are there fields that must be masked or excluded? Social security numbers, credit card data, and certain health identifiers may need to be excluded from the migration entirely or pseudonymized during transit.

These requirements impose real engineering and administrative overhead. A vendor who has not asked about data classification is not equipped to quote a regulated-industry migration.

Most Common Causes of Fixed-Price Migration Failures

Based on the structural failure modes observable across the migration pattern:

1. Undiscovered custom objects or associations — stakeholder assumptions about data scope diverge from reality once an actual API inventory is run. Mitigation: require a vendor-run object inventory as part of scoping, not as an assumption.

2. Attachment volume underestimation — buyers report storage in GB for the CRM database but forget that attachments stored in external buckets (SharePoint, S3, Google Drive) don't appear in CRM storage metrics. Mitigation: pull storage reports from both the CRM and any connected document systems.

3. History depth scope creep — a stakeholder not present during scoping later requests additional years of activity history. Mitigation: get explicit written sign-off on history depth from all stakeholders before migration starts, not just from the project lead.

4. System field unwritability surprises — buyers assume historical timestamps can be preserved; the target CRM blocks direct writes to those fields. Mitigation: test system field writability in the target environment during scoping, before the full load.

5. Inactive user mapping gaps — departed employees have no accounts in the target CRM; records fail to load or load without an owner. Mitigation: run a user reconciliation before migration, not on cutover weekend.

Red Flags in a Fixed-Price CRM Migration Quote

• No scoping call or data audit before quoting. A vendor who quotes without seeing your data is pricing a guess. That guess protects them, not you.
• Per-record pricing without a cap. Understand whether the price is truly fixed or variable with record count.
• "All data" with no object-level breakdown. The quote should list exactly which objects, fields, and history depth are included.
• No mention of sample or test migrations. A vendor who goes straight to production without validating on a subset is skipping the step most likely to catch mapping errors before they're expensive.
• Timeline promises with no rate-limit acknowledgment. If the quote says "2 days" for 200,000 records with 50 GB of attachments and doesn't mention API constraints, the timeline is fabricated.
• Scope document missing an exclusion list. What's not included matters as much as what is.
• No DPA or BAA discussion for regulated data. If your data touches personal information or PHI and the vendor hasn't asked about compliance requirements, they are not equipped for your migration.

The Information Your Vendor Needs

Bring this to your scoping call:

Start scoping at least 3–4 months before your internal go-live. Not because the migration itself takes months — most don't — but because the upstream work (data cleanup, target CRM configuration, compliance agreements, integration planning, stakeholder alignment on history depth) needs runway. The migration is rarely the bottleneck; the decisions that must precede it are.

A Scope Template You Can Send to Vendors

The fastest way to get comparable quotes is to send every provider the same scoping template and force assumptions into writing:

source:
  platform: Salesforce Enterprise
  extraction: API
  objects:
    - Contact
    - Account
    - Opportunity
  records:
    contacts: 48000
    opportunities: 12500
  history:
    notes: 190000
    files: 8400
    total_file_gb: 38
  schema_mismatches:
    - field: Formula_Field__c
      source_type: formula
      resolution: compute_at_migration_time_store_as_text
    - field: Multi_Select__c
      source_type: multi_select_picklist
      resolution: concatenate_to_text_field
 
target:
  platform: HubSpot Sales Hub Enterprise
  api_version: 2026-03
 
keys:
  contact: email
  company: domain
  opportunity: legacy_opportunity_id
 
requirements:
  preserve_created_date: true
  preserve_owner_history: false
  custom_objects: 2
  custom_associations: 5
  transforms:
    - stage remap
    - owner remap
    - html_to_markdown
    - currency normalization
 
compliance:
  gdpr: true
  dpa_required: true
  data_residency: EU
  staging_deletion_sla: 30_days
 
cutover:
  sample_runs: included
  delta_sync: included
  rollback_point: defined
  go_live_window: weekend
 
validation:
  record_count_parity: true
  referential_integrity_checks: true
  attachment_spot_checks: true
  sample_size: 1_percent_stratified_by_object
 
excluded_work:
  - workflow rebuild
  - dashboard redesign
  - user training
  - integration reconnection

If a provider cannot fill this in before quoting, they are guessing. If they can, you can compare quotes on scope instead of anecdotes.

What Makes a Quote Trustworthy

Fixed price is not the real question. Defined scope is. When two providers quote from the same checklist, you can compare real differences: who priced custom associations, who noticed the API throttle, who separated implementation from migration, who documented schema mismatch resolution paths, and who wrote down acceptance criteria.

A well-structured fixed-price migration quote includes:

1. Explicit scope — objects, fields, history depth, attachments, all listed by name
2. Explicit exclusions — what's not covered, in writing
3. Schema mismatch resolution — documented decision for each field type incompatibility
4. Validation method — sample size, stratification approach, and acceptance threshold
5. Timeline range — with caveats for API rate limits and customer availability
6. Change order policy — what happens if scope changes mid-project, and how undiscovered objects are handled
7. Re-migration terms — whether corrections are included or billed separately
8. Security and compliance terms — encryption standards, data retention, deletion timelines, DPA/BAA availability