47-Point CRM & ERP Migration Readiness Checklist

Include every custom field, custom object, and relationship — even ones that feel redundant. Discovery gaps are the #1 cause of post-migration data loss.

Map every Zapier workflow, API connection, webhook, and native connector. Each one needs a cutover plan before go-live.

Contacts, Accounts, Deals, Cases — each needs a named owner who signs off on data accuracy post-migration.

Scope creep during migration is extremely costly. Define the boundary in a signed scope document before work begins.

Migrating to an under-licensed system is a common failure point. Verify storage limits, user counts, and feature tiers upfront.

A deadline without a backwards-planned schedule is just a wish. Build the milestone schedule first, then assign the date.

Migrations fail when key stakeholders aren't aligned. Brief everyone before the project kicks off, not after the first problem.

Duplicates migrate and multiply. Deduplication before migration prevents a messy new system from day one.

Mandatory fields in the target system will reject records that don't have them. Resolve gaps before extraction.

DD/MM/YYYY vs MM/DD/YYYY mismatches cause silent data corruption. Audit every date field before extraction.

Invalid email addresses break email sync in the new system. Run a format check plus MX record check for key accounts.

Migrating dead records adds cost, time, and noise. Create a clear archival policy and apply it before migration.

Creates a formal baseline. Any issues discovered post-migration can't be attributed to the migration itself.

Article 5(1)(a) UK GDPR requires a documented lawful basis. If you can't evidence consent or legitimate interest, those records can't migrate.

Migrating suppressed contacts reactivates them in the new system — a direct GDPR breach and ICO enforcement risk.

If yes, Standard Contractual Clauses (SCCs) or adequacy decisions must be in place under Articles 44-50 UK GDPR.

The new system becomes a data processor under Article 28. A signed DPA is a legal requirement, not optional.

Article 30 requires your RoPA to reflect current processing. A system change is a processing change — update it.

If the migration involves high-risk processing, a Data Protection Impact Assessment may be required under Article 35.

Rate limits, authentication method, and data format (JSON, CSV, XML) all affect extraction planning. Confirm this before scoping begins.

Unmapped fields are data loss events waiting to happen. Every field needs a destination or a documented decision to exclude it.

These require custom field creation in the target before migration. Missing this step means data that has nowhere to land.

Each approach has implications for storage costs and user experience. Decide the strategy before extraction begins.

A sample extraction reveals API quirks, encoding issues, and field-type mismatches before they affect 500,000 records.

CRM/ERP plans often have record caps. Exceeding them mid-migration stops the project cold.

The target system must be fully configured before any records are loaded. Configuration after migration creates data inconsistencies.

Never test in production. A sandbox migration reveals problems that would be catastrophic in the live environment.

Row count reconciliation is the most fundamental data integrity check. Any discrepancy must be explained before go-live.

Automated counts don't catch field-level corruption. Human spot-checks do. Include oldest records and edge cases.

Workflows built against clean, newly-created records often break on migrated historical data. Test every automation.

IT sign-off is necessary but not sufficient. The business user who lives in the CRM will catch issues that technical reviewers miss.

Unexpected system changes destroy user trust and adoption rates. Five working days is the minimum — more is better.

Data entered after extraction but before cutover is lost. Agree a data freeze period and enforce it across the business.

Even a short freeze period generates new records. A delta migration captures everything up to the final cutover moment.

Never cut over without confirming the final migration count matches the source. This is your last zero-data-loss checkpoint.

Any integration still pointing at the old system will write to the wrong place after cutover. Update every endpoint.

SSO misconfiguration on go-live day locks users out. Test the new SSO connection before the old one is retired.

Users who can't log in on day one immediately lose confidence. Provision all accounts 48 hours before go-live.

New record creation in the target can mask discrepancies. A 24-hour post-go-live count confirms baseline integrity.

Production environments behave differently from sandboxes. Validate every workflow within the first 24 hours.

Email integration failures are the most-reported post-migration issue. Test sends and receives explicitly.

Dashboard numbers that don't match the old system indicate a data integrity issue requiring investigation.

Formal written sign-off from business users creates an audit trail and closes the validation loop.

The source system is your safety net. Keep it live and accessible for 30 days — insurance against any edge case discovered post-go-live.

A rollback decision made under pressure without a documented procedure will cause chaos. Write it before go-live.

Store securely for 2 years minimum. This is your forensic record if any data dispute arises after migration.

A structured review at 30 days surfaces any remaining issues, confirms business adoption, and formally closes the project.