When is a CRM migration actually ready?
A clean import log can still leave a salesperson without tomorrow's follow-up, an account without its signed proposal, or a service team unable to see an open case. Those gaps rarely show up in a record count. They show up when someone tries to do their job.
So we define ready in business terms. Every active opportunity has the right owner and stage. Every open task and service request is still assigned. The documents people need sit on the right records. Each role can see what it should and nothing more. A high import success rate on its own does not prove any of that.
What should you check before moving any data?
Start with the work the business cannot lose. List the open pipeline, scheduled follow-ups, renewals, open service requests, pending approvals, and the reports leaders read each week. Note who owns each item and who needs to see it.
Then pick a validation set before anyone extracts data. Include normal records and awkward ones: a contact linked to several accounts, open tasks owned by someone who has left, two companies that merged, an inactive account with an unresolved issue, and a document with restricted access.
Write the expected result for each case in plain language. "The new owner can see the open renewal and its latest approved proposal" is a test someone can pass or fail. "Accounts imported" is not. Give each check a business reviewer and a technical owner.
How do you stop records from duplicating?
Keep a stable source ID for every record, either in the new CRM or in a cross-reference table you control. Names and emails change, so they make poor keys.
Most platforms support this. Microsoft Dataverse, for example, offers alternate keys, which Microsoft describes as essential when an outside system does not store the platform's own record IDs. In its import wizard, choosing an alternate key for a CSV or XML file means existing rows are updated instead of duplicated.
Decide early what happens when two source records look like the same customer. Separate exact ID matches from likely matches that need a person to review. Do not merge on similar names alone.
Do not count on duplicate rules to catch everything during a bulk load. Microsoft notes that its newer detect and merge experience works when people enter data in the app, not during import. Check how your own platform behaves before you rely on it.
In what order should CRM data be loaded?
Load data in the order the target model needs. Accounts usually come before contacts, and both come before opportunities, activities, and files.
Keep a short manifest for each batch: source scope, extract time, mapping version, records accepted, records rejected, and relationship checks. A record rejected because its parent is missing stays on the open list until it is fixed. Counting it as processed hides unfinished work.
Plan for platform limits as well. The standard Dataverse import accepts .xlsx, .csv, and .xml files up to 8 MB, or .zip files up to 32 MB, and tracks each job from Submitted to Completed with success and failure counts. For attachments, check the link as well as the file. A proposal that opens but sits on the wrong opportunity is still a defect.
Why rehearse the migration more than once?
We run at least one full rehearsal in a test environment with approved data and access controls. Mapping and load settings are versioned.
Rehearsals should test the bad days: an interrupted batch, a repeated batch, a corrected mapping, and a rejected parent record. Decide whether a rerun updates existing records or creates new ones. Upsert, which Microsoft describes as a combination of update or insert, helps where it is supported. It cannot fix unclear matching rules.
Turn off or isolate outbound automation in the test environment so no real customer receives a test email. Time each step on its own: extract, transform, load, reconcile, and review. The longest step is often fixing exceptions, not moving data.
How do you reconcile the new CRM against the old one?
Reconcile at several levels. Compare counts by object and by meaningful status, such as open versus closed deals. Then check IDs, parent and child links, open work, owners, and required fields. Run a few key reports in both systems with the same filters and cutoff.
Test access with real roles, not an admin account. An admin sees everything, so the migration can look complete while a regular user cannot open the records they need. The opposite also happens: a broad default role can expose records that were private before. We take the same owner-first approach for file moves in our SharePoint migration guide.
Keep an exception register with severity, affected workflow, source IDs, owner, fix, and retest result. Agree on launch blockers in advance. Missing active opportunities or broken access to key documents should block launch, even when the overall import rate looks high.
How do you control the final cutover?
Pick a clear write boundary: the moment the old CRM stops taking normal updates and the new one becomes the system of record. If the business cannot pause writes, design and test a way to capture changes made after the final extract, with a named owner for conflicts.
List every system that writes to the CRM: web forms, email capture, marketing tools, support desks, and scheduled jobs. Moving user logins without repointing these leaves data flowing to the wrong place. Our API integration team maps these connections before the first rehearsal, and our migration and database services cover the data side.
Use a go or no-go checklist with business sign-off. Be honest about rollback. Once new work exists in the new CRM, going back means reconciling that work too. A backup alone is not a rollback plan. Set the decision deadline and the owner in advance.
What should you watch in the first week?
After launch, watch the flows that matter: new leads arriving, tasks created, owners assigned, documents opening, and the reports people actually use. Sort tickets into data defects, access issues, training needs, and integration failures.
Track open critical exceptions, failed sync jobs, new duplicates, and records with no next action. Keep read access to the old system until the business has closed every open question.
Frequently asked questions
No. Check relationships, open activities, owners, permissions, documents, and key reports. Equal counts can still hide missing work, duplicates, or records linked to the wrong parent.
Not always. Move what supports active work, reporting, and retention needs. Some history can live in a searchable archive, as long as access and ownership are defined before the old system is switched off.
Yes, with a clear final write boundary or a tested process to capture late changes. Without one, updates made after the final extract can be lost or conflict with the new system.
No. A backup keeps an earlier state, but new work may already exist in the new CRM. A real rollback plan explains how that work is reconciled, when the decision must be made, and who makes it.
Sources
- Microsoft Learn: Define alternate keys using Power Apps
- Microsoft Learn: Import data in model-driven apps
- Microsoft Learn: Synchronize data with external systems using change tracking and upsert
- Microsoft Learn: Detect duplicate records
Planning a CRM move?
Bring a list of your active work, connected systems, and the checks your team must pass on day one. We will map the data, the cutover, and the evidence that shows you are ready.
