CRM data migration: Preserve contacts and their relationships

A spreadsheet import may be enough when the structure is manageable and the required relationships are supported. Check how identifiers, multiple associations, attachments and activities are handled. The ability to read a file does not mean it contains every part of the CRM record.

An import tool or API integration may be appropriate when multiple objects, repeated runs or specific transformations are required. An API is a system's technical interface. Check which data it exposes, which limits apply and how it reports errors in both systems.

The appropriate method follows the agreed target model. If the relationships between organisations, people and opportunities are still unclear, define them first in the CRM requirements specification.

Mapping assigns each relevant source field to a target field. It also defines transformations and how relationships are resolved. A list of column names alone is insufficient.

Use stable source identifiers to trace each record. If identifiers change in the target system, retain a mapping between old and new IDs. A company name on its own is a problematic relationship key when businesses share a name or spelling differs.

The model below shows why objects and relationships need to be checked together. An imported contact with no correct company association may be visible in the CRM and still be wrong for business use.

Record formats, empty values and mandatory information as well. An unknown telephone number remains unknown; it should not be filled with an invented replacement. For choice fields, old and new categories must match in meaning. Assigning every open opportunity to the first pipeline stage would change its previous status.

Microsoft's documentation on CRM migration to Dataverse also identifies differing source and target structures, data quality and relationship dependencies as separate challenges. The specific import mechanisms remain system-dependent.

Similar names or the same email address may indicate a duplicate. They do not prove one. A shared mailbox can serve several people; companies with identical names may be separate entities. Separate detection of a potential conflict from approval to merge records.

Define which signals create a review case and who decides it. For a merge, record which record survives, which field values are retained and where activities, documents and opportunities should point afterwards.

Contradictory information needs a rule too. The most recently modified record does not necessarily contain the correct business information. For significant conflicts, a named person should check the source and record the decision.

Select test records that cover your different cases: multiple contacts, parallel opportunities, former owners, long notes, attachments and known duplicates. A random handful of simple contacts will not test those differences.

After the import, compare counts and error logs first. The reconciliation needs to match the agreed scope: imported records, deliberate merges, excluded records and open errors. Matching row counts alone do not prove a correct transfer.

Then check the business meaning. Open a customer record and follow its relationships, recent activities, ownership and active opportunities. Check dates and relevant time zones. For histories, distinguish between preserving the original time and person as information and the target system creating new technical import timestamps.

Test with the intended user roles as well. An administrator may see a fully imported record while sales lacks the permissions to use it. Conversely, the transfer must not unintentionally broaden access.

Record the expected result, observed result and approval. Define in advance which failures prevent the production switch. A missing contact relationship on active opportunities could be one such stop condition. The responsible business role accepts the result; a successful import status is insufficient.

Records continue to change between the test run and the switch. Agree a cut-off and how new or modified records will be handled. Use either an agreed pause on writes or a tested transfer of changes. The responsible people need to know when each system becomes authoritative.

Before the production import, test how automations and integrations react. New records could trigger tasks, notifications or further transfers. Decide which functions remain disabled during import and how they will be re-enabled under controlled conditions.

Prepare a fallback procedure with a backup, clear ownership and an abort decision. Account for changes already made in the new system. Simply returning to the old dataset could otherwise omit them. Also test how an interrupted import can be repeated without creating new duplicates.

After approval, run a defined follow-up period with an issue list and a responsible contact. The CRM implementation guide adds team preparation and the move into everyday use to this technical plan.

The CSV template for mapping and review cases contains example rows for fields, relationships and duplicate decisions, plus room for your own entries. The Markdown approval template adds scope, cut-off, stop conditions and follow-up. These are planning documents, not files to import directly into a CRM.

Complete the templates with the business data owner. Record open questions explicitly and check the result against a sample export. If the transfer is part of a custom CRM solution, these documents provide a concrete starting point for defining the project scope.