Data Migration Checklist: The Complete Step-by-Step Guide
A successful data migration depends less on moving data and more on controlling scope, quality, mapping, validation, cutover, and recovery. Use this checklist from discovery through post-migration sign-off.
What is a data migration checklist?
A data migration checklist is a structured list of tasks used to plan, prepare, move, validate, and approve data when transferring it from one system to another. It typically covers scope, data cleanup, mapping, transformation, testing, backups, cutover, reconciliation, rollback, and post-migration verification.
Table of Contents
Data Migration Checklist
Phase 1: Discovery & Planning
Phase 2: Data Audit, Cleansing & Preparation
Phase 3: Data Mapping & Transformation
Phase 4: Migration Build
Phase 5: Testing & Validation
Phase 6: Cutover
Phase 7: Post-Migration Validation
Nex.Tech implementation perspective
The migration is not complete when the import finishes. It is complete when business-critical records, relationships, integrations, automations, permissions, and reporting have been validated and signed off.
Phase 1: Data Migration Discovery and Planning
Discovery and planning define what you are migrating, why, and how. This phase sets the scope, identifies stakeholders, and determines the migration approach — big-bang or phased, full or incremental. Skipping this phase leads to scope creep, missed dependencies, and timeline overruns.
Define business goals and success criteria first. Identify source and target systems, data domains, and dependencies. Assign a migration owner and project manager. Determine whether a systems integration approach is needed for connected platforms.
Compliance considerations — GDPR, HIPAA, financial regulations — must be identified here, not during cutover. Document blackout windows and business constraints that affect when the migration can occur.
Phase 1 checklist:
- Define business goals and success criteria
- Define migration scope
- Identify source and target systems
- Assign migration owners and stakeholders
- Inventory data domains
- Identify dependencies and integrations
- Define security and compliance requirements
- Determine migration approach (big-bang vs phased)
- Define timeline and cutover window
Phase 2: Data Audit, Cleansing, and Preparation
Migrating bad data into a new system creates bigger problems than leaving it in the old one. Duplicates multiply, invalid values break workflows, and missing fields cause reporting errors that are expensive to fix after go-live.
Start with a full data inventory — record counts by table and domain. Profile data quality to find missing fields, nulls, invalid values, and orphaned records. Identify duplicates and obsolete data. Normalize formats for dates, addresses, phone numbers, and currencies.
Define retention rules: how much history to migrate versus archive. Identify PII and sensitive data requiring special handling. Resolve ownership ambiguities — records with no assigned owner cause access and reporting issues in the target system.
Data-quality checklist:
- Inventory all records by domain
- Profile for missing, null, and invalid values
- Identify and deduplicate records
- Remove or archive obsolete data
- Normalize and standardize formats
- Define retention and archival rules
- Identify PII and sensitive data
- Resolve ownership ambiguities
- Cleanse in source before migration
Phase 3: Data Mapping and Transformation
Data mapping defines how every field in the source system corresponds to a field in the target system, including any transformation required. This document is the single source of truth for the migration build and must be reviewed and signed off by business stakeholders.
Map reference and master data before transactional data. Define data type conversions, picklist value mappings, ID and foreign key handling, and rules for calculated fields. Document date and time zone conversions, currency conversions, and null handling.
| Source Field | Target Field | Transformation | Validation |
|---|---|---|---|
| CustomerName | account_name | Trim, title case | Not null, max 255 chars |
| Phone | phone | Format to E.164 | Valid phone format |
| CreatedDate | created_at | Convert to UTC ISO 8601 | Valid date, not null |
| TotalAmount | total | Cast to decimal(12,2) | Greater than 0 |
| Status (Active=1) | status | 1 → active, 0 → inactive | Enum match |
Phase 4: Build the Migration Process
The migration process must be repeatable before production cutover. If you cannot run the migration multiple times with consistent results, you are not ready for cutover. Build scripts, ETL jobs, or iPaaS flows that can be re-run, logged, and audited.
Sequence the migration: master data first, then transactional data. Implement batching and throttling to avoid API limits. Build error handling with retry logic and exception logging. Create a migration runbook that documents every step so the process can be executed by anyone on the team.
Phase 5: Data Migration Testing Checklist
Testing is the phase that prevents production failures. A migration that has not been tested with full volume in a staging environment is not ready for cutover. Test sample data, run a pilot, run full-volume tests, and conduct UAT with business users.
Testing checklist:
- Unit test with small sample
- Pilot migration with representative subset
- Full-volume test in staging
- Reconcile record counts
- Validate financial and control totals
- Validate referential integrity
- Test role and permission assignments
- Test integrations with connected systems
- Test workflows and automations
- Conduct UAT with business users
- Review and resolve all exceptions
- Document test results and obtain UAT sign-off
Data Migration Validation Checklist
Validation confirms that the data in the target system matches the source and meets business requirements. Use multiple validation methods — record counts, control totals, field-level sampling, and critical-record verification.
Reconciliation formula:
Source records − intentionally excluded records = expected target records
Compare expected target records against actual loaded records. Any variance must be explained and resolved.
- Source vs target record counts for every domain
- Control totals and financial totals match
- Null counts are within expected range
- Duplicate counts are zero or explained
- Data types are correct in target
- Referential integrity is intact
- Field-level sampling of critical records
- Audit trail is complete
- Attachment and file integrity verified
- Timestamps and ownership are correct
- Permissions are correctly assigned
Data Migration Cutover Checklist
Cutover is the execution of the production migration. It must follow a documented runbook with a go/no-go decision, a data freeze, and a defined rollback point.
Before cutover:
- Final go/no-go decision meeting
- Communicate outage window to users
- Freeze changes in source system
- Take final backup of source
- Confirm all credentials and access
- Confirm migration scripts are final
- Confirm rollback decision point and criteria
During cutover:
- Extract data from source
- Transform per mapping rules
- Load into target system
- Reconcile record counts and totals
- Run validation checks
- Verify integrations
- Review and resolve exceptions
After cutover:
- Business validation by end users
- Grant user access to target system
- Monitor for errors and issues
- Release system to production use
- Communicate completion to stakeholders
Data Migration Rollback Plan Checklist
Every production migration should define rollback criteria before cutover. If the migration fails or produces unacceptable data issues, you need a clear path back to the source system.
- Define rollback trigger criteria (e.g., record count variance > 0.1%)
- Identify the decision owner who can authorize rollback
- Define the latest point at which rollback is possible
- Document the source restoration process
- Define target system cleanup procedure
- Plan integration rollback steps
- Prepare user communication for rollback scenario
- Verify system state after rollback is complete
Post-Migration Checklist
Post-migration work does not end at go-live. Monitor the target system, resolve user issues, verify integrations and automations, and maintain legacy-system access until the transition is confirmed stable.
- Validate data accuracy with business users
- Monitor target system for errors and performance
- Reconcile source vs target totals
- Track and resolve user-reported issues
- Verify all integrations are functioning
- Verify automations and scheduled jobs are running
- Validate permissions and access
- Verify reports and dashboards are correct
- Confirm backups are configured in target
- Monitor exception queue
- Maintain legacy-system read-only access
- Archive or decommission legacy system per policy
- Obtain final business sign-off
- Document lessons learned
Need a second set of eyes on your migration plan? Talk to a migration expert at Nex.Tech for help with planning, mapping, testing, or executing your migration.
Common Data Migration Risks and How to Prevent Them
Most migration failures are preventable. The table below covers the most common risks, what happens when they occur, and how to prevent them.
| Risk | What Happens | Prevention |
|---|---|---|
| Incomplete source data | Required fields are missing or null in the source system | Profile data early; define handling for every field before migration |
| Duplicate records | Same customer or vendor appears multiple times | Deduplicate in the source system before migration, not after |
| Broken relationships | Foreign keys do not resolve in the target system | Migrate parent records before child records; validate referential integrity |
| Bad field mapping | Data lands in the wrong field or with wrong format | Review and sign off mapping document with business stakeholders |
| Changed source data during migration | Users continue editing the source system during cutover | Enforce a data freeze before extraction; communicate the window clearly |
| Incomplete testing | Issues discovered after go-live when fixes are expensive | Run pilot, full-volume, and UAT before cutover; never skip test cycles |
| Integration failures | Connected systems break after migration | Test all integrations in staging; verify them immediately after cutover |
| Incorrect permissions | Users cannot access records they should, or can access records they should not | Test role and permission assignments during UAT |
| Missing attachments | Files and documents linked to records are not migrated | Inventory attachments separately; verify file integrity post-migration |
| Performance problems | Target system is slow or unresponsive after load | Run volume tests; optimize batch sizes and indexing before cutover |
| API limits exceeded | Migration fails partway due to rate limiting | Implement throttling and batching; monitor API usage during runs |
| Inadequate rollback plan | No way to revert when cutover fails | Define rollback triggers, decision owner, and restoration steps before cutover |
| Sign-off delays | Business stakeholders cannot validate in time | Involve business users early; define sign-off criteria before UAT begins |
Data Migration Checklist by System Type
CRM Data Migration Checklist
CRM migrations require careful handling of relationships, ownership, and activity history. Key considerations:
- Accounts and contacts with correct relationships
- Leads and opportunities with pipeline stages
- Activities, notes, and attachments
- Ownership and territory assignments
- Duplicate management rules
- Automation and workflow configuration
- Custom fields and picklist values
See our CRM implementation service for guided migrations.
ERP Data Migration Checklist
ERP migrations carry the highest risk because financial data integrity is non-negotiable. Key considerations:
- Customers and suppliers with correct balances
- Products and inventory with accurate quantities
- Open orders, invoices, and payables
- GL balances and opening balances
- Tax codes and tax data
- Financial reconciliation against source totals
- Chart of accounts mapping
See our ERP data migration checklist and ERP migration guide for more detail.
Cloud Data Migration Checklist
Cloud migrations add infrastructure, security, and transfer-method considerations. Key considerations:
- Identity and access management configuration
- Encryption at rest and in transit
- Transfer method (batch, streaming, physical)
- Bandwidth and network capacity
- Data residency and compliance requirements
- Security group and firewall rules
- Backup and recovery configuration
- Downtime window and validation plan
See our cloud migration service for guidance.
Who Should Own Each Part of a Data Migration?
Clear ownership prevents gaps. Responsibility varies by organization, but the table below provides a practical starting point.
| Task | Typical Owner |
|---|---|
| Scope and objectives | Project sponsor / project manager |
| Data quality and cleansing | Business / data owner |
| Field mapping | Business analyst / solution architect |
| Migration scripts and ETL | Technical migration team |
| Validation and reconciliation | Business + technical team |
| Cutover execution | Project manager / technical lead |
| Business sign-off | Executive / business owner |
How Long Does a Data Migration Take?
There is no universal timeline. Duration depends on the number of systems, data volume, data quality, complexity of relationships, transformation rules, integrations, testing cycles, compliance requirements, and cutover constraints.
A focused CRM migration with clean data may take a few weeks. A full ERP migration with financial reconciliation, multiple integrations, and years of transactional history can span several months. The testing and validation phases typically take as long as the build phase — do not compress them.
For directional planning, see our ERP implementation timeline guide.
What Makes a Data Migration Successful?
- Clear scope with documented boundaries
- Clean data — cleansed before migration, not after
- Documented and signed-off field mappings
- A repeatable migration process that can be run multiple times
- Rigorous validation — record counts, totals, relationships, and field-level sampling
- Active business involvement throughout testing and UAT
- A rollback plan with defined triggers and decision owners
- Post-cutover monitoring until the system is confirmed stable
Data Migration FAQs
A data migration checklist is a structured list of tasks used to plan, prepare, move, validate, and approve data when transferring it from one system to another. It typically covers scope, data cleanup, mapping, transformation, testing, backups, cutover, reconciliation, rollback, and post-migration verification.
The main stages are discovery and planning, data audit and cleansing, mapping and transformation, migration build, testing and validation, production cutover, and post-migration monitoring. Each stage has its own checklist of tasks and sign-off criteria.
A data migration plan should include scope and objectives, source and target system identification, data inventory, mapping documents, transformation rules, migration sequencing, testing strategy, cutover plan, rollback plan, risk assessment, stakeholder roles, and a project timeline with defined milestones.
Validate by comparing source vs target record counts, reconciling financial and control totals, checking referential integrity, sampling critical records at the field level, testing integrations, and conducting user acceptance testing. Validation should confirm that every business-critical record, relationship, and value is correct before sign-off.
Data migration moves data from one system to another, typically with structural transformation. Data conversion transforms data from one format or structure to another, often within the same system. Migration changes where data lives; conversion changes how data is structured.
Prevent data loss by taking full backups before migration, profiling source data to identify gaps, validating record counts after every migration run, testing with sample data before production, and maintaining access to the legacy system until post-migration validation is complete.
A rollback plan should define the rollback trigger criteria, the decision owner, the latest point at which rollback is possible, the source restoration process, the target system cleanup procedure, integration rollback steps, user communication, and verification steps after rollback is executed.
Test by running a sample migration, then a pilot with representative data, then a full-volume test in staging. Validate record counts, financial totals, relationships, permissions, integrations, workflows, and automations. Conduct UAT with business users and resolve all exceptions before cutover.
Clean data in the source system during the audit and preparation phase, before any migration build begins. Migrating bad data into a new system creates bigger problems — duplicates, invalid values, and broken relationships are harder to fix after the target system is live.
Reconcile by comparing record counts for every data domain, matching financial and control totals, verifying that no records were dropped or duplicated, and sampling critical records to confirm field-level accuracy. The formula is: source records minus intentionally excluded records equals expected target records.
Sign-off should come from the business owner or executive sponsor who is accountable for the data, with input from the data owner, technical lead, and end users who conducted UAT. The sign-off confirms that all validation criteria have been met and the migration is accepted.
The most common failures are incomplete data cleansing, bad field mapping, inadequate testing, broken relationships from wrong migration sequencing, source data changing during cutover, integration failures, and no rollback plan when something goes wrong.
Planning a Complex Data Migration?
Use the checklist internally, or talk with Nex.Tech if you need help planning, mapping, testing, or executing a CRM, ERP, cloud, or business-system migration.
Prepared by Nex.Tech