A data migration plan needs more than an export and an import. It must say what moves, how values change, how you prove the result is usable and what happens if the switch fails.
Use this checklist when moving records between business systems, such as two CRMs or an old application and its replacement. It is a planning guide; the implementation depends on the systems and the data you are authorised to handle.
Define the records and their owner
List the record types, date ranges, attachments and relationships in scope. For example, a customer may have several contacts, each with notes and permissions. Moving the customer row alone may leave the destination unusable.
Name who can decide whether an incomplete record should be corrected, excluded or moved with a warning. Keep an exclusion log with reasons. Do not silently treat a failed import as a decision to discard data.
Map values and relationships
For each field, write the source, destination, data type, transformation, default and validation rule. Check time zones, currencies, empty values, list options and identifiers. A blank field and a zero may mean different things.
In a fictional CRM move, the source might allow “New”, “Contacted” and “Qualified”, while the destination uses different stages. Agree the mapping with the team that uses those stages. Keep a source-to-destination ID map so contacts and notes attach to the intended customer.
Decide how duplicates are resolved. Matching only by a company name or shared email address may combine distinct records. Record the rule and review ambiguous matches.
Rehearse in a safe environment
Run a trial before the production move. Use appropriate access controls and a dataset you have permission to process. Include messy records, large attachments and unusual relationships, as well as ordinary examples.
Test re-running the job after an interruption. It should identify already processed records and report what remains. Measure the transfer and validation time so the proposed switch window is based on a rehearsal.
Validate meaning as well as totals
- Reconcile source records against imported, excluded and failed records.
- Compare important field values, including agreed transformations.
- Check relationships: each contact, order or note points to the right parent.
- Open attachments and test permissions with the intended user roles.
- Have an authorised user complete ordinary tasks in the destination.
- Investigate every unexplained mismatch before sign-off.
Matching totals cannot establish that the right data reached the right fields. For database-level validation, AWS DMS documentation describes comparing source and target rows and reporting mismatches. That tool has endpoint and validation limits; it is an example of a check, not a requirement to use AWS or a substitute for testing your application.
Plan the switch and the way back
Agree when the old system stops accepting changes, how changes during the move are captured and when the destination becomes the source of truth. Name the person who decides to proceed or stop.
Set the conditions for rollback before starting. A backup is useful only if restoration has been tested and fits the required recovery window. Once people add new records in the destination, returning to the old system also requires a plan for those records. Two systems accepting independent changes create a reconciliation problem.
Leave a migration record
Keep the mapping, run log, validation results, known exceptions and sign-off together. Agree how long temporary exports are needed, where they are stored and who removes them. Transfer access and operating instructions to the person maintaining the destination.
Drevhe scopes data migration within Integrations, Automation & AI. If the move also needs an ongoing connection, use the form-to-CRM integration guide to plan new records arriving after launch.