CRM data migration checklist: move records without losing relationships

Choose the migration scope before preparing files

Inventory accounts, contacts, activities, opportunities, tickets, attachments and any custom records. Identify their owners and how they relate. Decide which historical material needs to remain operationally accessible and which can stay in an approved archive or existing system under the organisation's retention arrangements.

Microsoft's migration guidance distinguishes configuration, master data and open transactions. Apply that separation to your CRM plan: required settings must exist before dependent records can be imported. For example, importing opportunities without valid owners, currencies or pipeline stages may produce records that exist but cannot be used correctly.

Create a field map with business meaning

For each destination field, document the source, transformation, permitted values and handling of blanks. Preserve source identifiers in a reference field or mapping table so failed imports and later synchronisation can be traced. Do not use a person's display name as the only relationship key.

Review dates, time zones, phone numbers, country codes and consent-related fields with their owners. A blank value may mean unknown rather than false. Keep the original meaning when a new platform's fields do not map directly; if necessary, use an explicit migration note or a separate exception record.

• Map parent records before dependent activities and transactions.
• Identify mandatory fields that have no reliable source.
• Record who approves each transformation rule.

Rehearse and reconcile more than row counts

Run a representative sample first, including records with long histories, non-ASCII characters, attachments and unusual permissions. Then rehearse the intended volume and measure how long export, transformation, import and validation actually take. Microsoft documents mock-cutover testing as a useful part of migration performance assessment.

Compare counts by record type and status, check parent-child links, inspect field completeness and have users perform real tasks. Can a salesperson find the customer's latest activity? Can support see the open case and its attachments? A total of ten thousand rows proves little if a subset is linked to the wrong customer.

Control the cutover and post-launch changes

Agree when source edits stop or how changes made during migration will be captured. Assign the final reconciliation decision to named business owners. Define what evidence is required to proceed and when to return to the established process if the agreed checks fail.

Keep a log of exceptions and corrections after launch. Prevent old integrations from continuing to write into retired workflows, and confirm that new imports do not create duplicates. Provide users with a clear reporting route and explain any intentional differences in record ownership, history or access.