Where migrations actually fail
Not on moving the data — that part is well understood. They fail on data nobody cleaned, mappings nobody agreed, and a cutover nobody rehearsed. All three are avoidable and all three are commonly skipped.
Migrating CRM data is a project where the technical work is the easy half. This is what the difficult half consists of.
The phases, honestly proportioned
| Phase | Share of effort | Skipped when rushed |
|---|---|---|
| Deciding what to migrate | Small but decisive | Often |
| Cleaning | Frequently the largest | Almost always |
| Field mapping and sign-off | Moderate | Partially |
| Test migrations | Moderate | Reduced to one |
| The actual migration | Small | Never |
| Validation and reconciliation | Moderate | Often |
| Cutover and support | Moderate | Underestimated |
Cleaning before migrating, not after, is the single decision that most affects the outcome. Duplicates, dead records and inconsistent values carried into a new system arrive on day one and immediately undermine user trust. Users who do not trust the data in week one do not adopt the system in month three.
What to leave behind
- Contacts with no activity for years and no clear ownership.
- Opportunities closed long ago beyond your reporting horizon.
- Duplicate records — merged first, or the duplicates multiply.
- Fields nobody has populated in years.
- Test and demonstration data, which every system accumulates.
- Custom fields created for a project that ended.
Archive rather than delete where retention obligations or curiosity apply — an export in accessible storage costs almost nothing and removes the argument.
Mapping needs sign-off, not assumption
- List every source field and its destination, or explicitly "not migrated".
- Resolve picklist mismatches — source values that do not exist in the destination.
- Decide on required fields in the destination that the source cannot populate.
- Agree the ownership and assignment rules for records whose owner has left.
- Define the deduplication key and the merge rules.
- Get written sign-off from whoever owns the data, before any test migration.
Every unmapped field is a conversation that will happen either now, calmly, or during cutover, urgently. The first version costs an hour.
Run at least three test migrations into a sandbox, with the real dataset. The first finds mapping errors, the second finds volume and performance problems, the third proves the runbook. Teams that test once with a sample find the remaining two categories of problem during cutover.
Validating that it worked
| Check | What it catches |
|---|---|
| Record counts by object and type | Wholesale loss |
| Financial totals — pipeline, revenue | Silent field-level failures |
| Relationship integrity | Orphaned contacts and opportunities |
| Spot checks by business users | Semantic errors automation misses |
| Reports reproduced from both systems | Differences that matter to the business |
| Sample of the oldest and newest records | Date and edge-case handling |
Business users spot-checking records they know well finds problems no count reconciliation will — a correctly migrated record with the wrong meaning passes every automated test.
Cutover
- Freeze changes in the source for a defined window, communicated in advance.
- Run the migration following the rehearsed runbook.
- Validate before opening access, using the checks above.
- Open to users with support staffed for the first days.
- Keep the source available read-only for a period — this is your safety net and it costs little.
- Define the rollback trigger in advance, so the decision is not made under pressure.
Signs a migration is heading for trouble
- Nobody has looked at data quality yet.
- The mapping is "mostly obvious" and unwritten.
- One test migration is planned.
- Validation is "users will tell us".
- There is no rollback plan.
- The timeline assumes the movement is the work.
Planning a migration, or recovering from one? Tell us the systems and the volumes. See why CRM implementations fail, Zoho vs Salesforce, and ERP integration.