5 Data Migration Risks (and How to Avoid Every One)

The most obvious risk and still the most common. Data loss takes many forms:

How it happens

• Records dropped silently. Source has 1M Contacts; destination has 980K. The 20K rejection silently failed during load (orphan parent reference, type validation failure, invalid required field). No one notices until a customer asks why their record is gone.
• Fields dropped during mapping. Source has 47 custom fields on Contact; destination got 41. Six fields weren't in the mapping spec. The data was real and used by reps, now it's gone.
• Attachments missed. Records migrated; their associated attachments stayed in the source. Attorneys discover this during e-discovery.
• Transactions before the cutover threshold. Migration window covers last 5 fiscal years; older data discarded. Auditor asks for a 7-year-old transaction; you can't produce it.

Real example

A B2B services company migrated Salesforce → HubSpot in 2024. The migration vendor mapped Contact, Account, Opportunity, Task, Event, and EmailMessage. They didn't map ContentDocumentLink (Salesforce's join table for files). Result: 180K files orphaned in Salesforce, no longer accessible from HubSpot records they were attached to. Discovered three months post-migration when sales asked for a contract attachment.

How to avoid

• Reconciliation report at row level, not aggregate. Source COUNT = destination COUNT per object, with variance investigated to zero.
• Field-level reconciliation. For every field migrated: source NOT NULL count = destination NOT NULL count.
• Attachment count reconciliation. Source attachment count per parent record = destination attachment count per parent record.
• Source kept read-only post-migration. Even if you don't think you'll need it, keep the source for the rollback window. If data loss is discovered later, the source is your recovery path.

Plan said "2 hour cutover window." Reality was "the system was unusable for 4 days."

How it happens

• Underestimating data volume. Sandbox load took 4 hours. Production has 10x the data. Production load takes 4 days. No one rehearsed at full volume.
• API rate limits hit. Destination has a 100K-API-calls-per-day limit. Migration needed 2M. Hit the limit at 5% complete. Now waiting 24 hours per chunk.
• Integration partner can't repoint immediately. Marketing automation tool requires 5 business days to repoint to new CRM. Cutover happens Friday; marketing campaigns broken until Wednesday.
• Reconciliation reveals issues that block sign-off. Trial balance variance found post-cutover. Investigation takes 2 days. Source stays read-only, destination not authoritative. No one knows where to do their work.

Real example

A 200-person agency migrated NetSuite → QuickBooks in 2023 to reduce ERP cost post-divestiture. Migration ran Friday night. Trial balance reconciliation Sunday showed a $400K variance in Accrued Liabilities. Root cause: source had a custom GL account with a non-standard account type that didn't map. Took 4 days to fix. Operations team on payroll, payments, and AP couldn't function. Estimated cost: $80K in lost productivity plus a delayed bank deposit cycle.

How to avoid

• Rehearse at full data volume. Not 10%; 100%. Discover timing reality before cutover.
• Audit destination's API quotas in advance. Calculate required API calls per object class. Negotiate temporary quota increase with destination if needed.
• Schedule integration partners 2 weeks in advance. Each integration partner needs a confirmed cutover date. No surprises.
• Define reconciliation acceptance criteria before cutover. What variance is acceptable? What requires investigation? Decide in advance.
• Weekend cutover with Monday buffer. Allow 24-48 hour buffer between cutover and "everyone uses the new system." Catches issues before they become user-impacting.

Source data structure doesn't fit destination schema. Migration loads anyway. Data is now structurally wrong.

How it happens

• Picklist values don't match. Source has 47 picklist values for Lead Status. Destination has 12. Mapping assigns the 35 unmapped values to "Other." Reporting on Lead Status no longer works.
• Custom objects collapsed inappropriately. Source has Contacts with related Subscription custom objects (1:many). Destination doesn't have a Subscriptions custom object. Migration collapses Subscription data into Contact custom fields. Now Contacts with multiple subscriptions show only the most recent one.
• Hierarchy depth exceeded. Source has 6-level Account hierarchy. Destination supports 3 levels. Levels 4-6 collapsed into level 3, parent-child relationships flattened. Org chart reports broken.
• Required fields without source data. Destination requires a value for "Industry" on every Account. Source had Industry on 60% of Accounts. The 40% without get assigned a default value. Reporting now shows 40% of customers in "Other" Industry.

Real example

A SaaS company migrated Pipedrive → HubSpot. Pipedrive Deal had 8 custom fields including a "Renewal Probability" calculated field. HubSpot mapping created equivalent custom properties for 7 fields. The 8th (Renewal Probability) was a Pipedrive formula field that calculated from other fields. The mapping vendor migrated the calculated value (a snapshot at migration time) but didn't recreate the formula. Result: HubSpot had stale Renewal Probability values that never updated. Sales used these for forecasting for 6 weeks before noticing.

How to avoid

• Detailed field mapping document. Every source field mapped to a destination field, with explicit handling for unmapped values.
• Picklist value reconciliation. Every source picklist value either maps to a destination value or has a documented disposition (drop, default, create new).
• Validate complex scenarios manually. Pick the 5 most complex source records and verify field-by-field on the destination.
• Identify calculated/derived fields. These need to be recreated as formulas/calculations on the destination, not migrated as static values.
• UAT by power users. Power users from each affected team validate that workflows work. They notice schema mismatches that engineers miss.

Migration of regulated data without proper controls. The legal exposure can dwarf the migration cost.

How it happens

• PHI moved outside HIPAA boundary. Source was on a HIPAA-compliant tier; destination is on a tier that doesn't include a BAA. Migration vendor didn't realize. Now PHI is in a non-compliant system, every record is a HIPAA violation.
• EU customer data moved out of EU. Source was hosted in EU; destination defaulted to US. GDPR Article 44 violation. Penalty: up to 4% of global annual revenue.
• PCI data migrated through non-PCI infrastructure. Credit card tokens passed through a migration tool that wasn't PCI DSS certified. Even if data ends up in a compliant destination, the transit violated PCI.
• Audit log discontinuity. Source had 7-year audit log; destination starts fresh. SOX-relevant approval history missing for migrated records.

Real example

A telehealth company migrated Salesforce Health Cloud → HubSpot. The migration vendor was not on a HIPAA BAA. Patient data passed through their staging environment for 3 weeks during the migration. Discovered post-migration during the company's annual HITRUST audit. The remediation: full breach notification, documented BAA execution, retroactive risk analysis. Total cost (legal, audit, breach notification): $340K. Migration cost was $35K.

How to avoid

• Audit destination tenant compliance before scope. HIPAA BAA, GDPR DPA, PCI DSS attestation, SOC 2 Type II. Confirm in writing before starting.
• Audit migration vendor compliance. Same checklist for the migration vendor. Their staging environment is in scope for any compliance regime your data is subject to.
• Data residency confirmation. Source region == destination region. Both vendor's staging and destination must be in the same regulatory region.
• Audit log preservation. Migration plan explicitly addresses audit log: either migrated to destination, or source retained read-only for retention period, or both.
• Legal review before cutover. Privacy/compliance counsel signs off on the migration plan before execution.

Migration "should take 6 weeks" turns into 18 weeks. Budget triples. Team burns out. Sometimes nothing goes live.

How it happens

• Discovery surfaces unknown dependencies. Audit reveals 14 integrations no one documented. Each needs scope addition. Each adds 1-2 weeks.
• "While we're at it" requests. "Since you're touching the CRM, can you also clean up our duplicate accounts?" Each "while we're at it" is a separate project bolted onto the migration.
• Stakeholder turnover mid-engagement. Sponsor gets reorged out; new sponsor wants to add scope or change destination platform. Restart cost: 4-6 weeks.
• Custom workflow re-implementation. "We need our 47 Salesforce Apex triggers re-implemented as HubSpot Workflows." Discovered to be 4 months of work. Wasn't in original scope.
• Hourly billing. Vendor bills hourly. Every additional discovery is more hours. No incentive to be efficient.

Real example

A manufacturing company contracted a Big-4 consultancy for an SAP → NetSuite migration in 2022. Original quote: $480K, 9 months. After 18 months and $2.1M of billings, they paused the project. Root cause: hourly billing, scope expanded continuously based on discovery findings, no fixed-fee anchoring decisions to "did we cover that in scope?" They eventually completed the migration with a different vendor on a fixed-scope engagement for an additional $320K, 6 months.

How to avoid

• Fixed-scope, fixed-fee engagement. Define exactly what's in scope before signing. Out-of-scope work is a documented change order with separate pricing.
• Detailed discovery before quote. Vendor should audit your environment before quoting fixed price. A quote without discovery is a guess.
• Single accountable owner on your side. One person decides what's in or out of scope. Distributed decision-making invites scope creep.
• Define "done" before starting. What does successful migration look like? Specific reconciliation criteria, specific go-live milestones.
• Don't combine migration with cleanup. Data cleanup is a separate project. Doing both at once means you can't isolate which change caused which issue.

Five risks, each with a specific mitigation:

• Data loss → Row-level reconciliation; source kept read-only post-migration.
• Extended downtime → Full-volume rehearsal; integration partner coordination; reconciliation acceptance criteria defined upfront.
• Schema mismatch → Field-level mapping document; picklist value reconciliation; UAT by power users.
• Compliance violations → Audit destination tenant compliance; audit migration vendor compliance; legal review before cutover.
• Scope creep → Fixed-scope, fixed-fee engagement; single accountable owner; detailed discovery before quote.

None of these are novel. They've been failing migrations for 30 years. The discipline that prevents them is well-known. The migration checklist codifies it. Or have us run the migration with all five mitigations baked into the engagement model.