Direct answer
A CRM migration is done when a rep can open the new system on Monday and trust what is in it. The final stage, after your mapping is signed off, has eight parts: a test import into a sandbox or trial, a record-count reconciliation between old and new, a sample-record review by people who know the accounts, a freeze window with a start and end, a go-live sequence written as a run-of-show, a post-cutover validation, a defined rollback trigger, and a first-week watch. This page covers that stage only. Deciding whether to migrate is in the CRM migration checklist; the field, stage and owner map that must exist first is in CRM data mapping for migration. No checklist can promise zero downtime or a lossless move, and we do not; the point is to find losses while they are cheap.
1. Run a test import
Import a representative slice into a sandbox, trial or test account if your target platform offers one; check what yours provides. A good slice is not the first hundred rows. Include recent and old records, records with missing data, records with unusual characters, records with several associations, and a few of each deal stage. Then look at what actually happened, not at whether the import said 'success':
- Which rows were rejected or skipped, and why
- Which fields arrived blank when the source had a value
- Dates, currencies, phone numbers and accented characters, since these break quietly
- Whether picklist values and stages landed where the map said they would
- Whether associations are intact: contact to company, deal to contact
- Whether owners, creation dates and activity history came across as the map expected
Fix the map, not the records
When something breaks, change the mapping or transformation rule and re-run, rather than hand-editing the imported records. Hand edits vanish on the next run and hide the real fault. Repeat until a test run passes with no unexplained differences, then keep the final run's settings as the recipe for the real one.
2. Reconcile record counts
Counts are the cheapest test you have. For each object, write down the source count, the number you intended to migrate after the drop list, the number imported, and the difference. Every difference must have an explanation: rejected rows, merged duplicates, records dropped by rule. A gap you cannot explain is a defect until proven otherwise. Reconcile by segment as well as in total: by owner, by pipeline stage, by year created and by record status. A correct grand total can hide a whole owner's contacts missing and another owner's duplicated. Also compare a few totals that matter to the business, such as the number of open deals and the sum of open deal value, and explain any difference.
3. Review sample records with real people
Counts do not catch wrong data. Pick a sample, roughly proportionate to the size of your database and chosen so it includes your biggest accounts, and ask the people who know them to compare old and new side by side. For each record: does the company and contact detail match, is the owner right, are the notes and last activities there, are the deal amount, stage and close date right, do the linked records make sense? Record every discrepancy in a list with a category, so patterns show up: if the same field is wrong in most samples, it is a mapping problem, not a data problem.
4. Define the freeze window
Between the final export and go-live, changes in the old system would be lost. Decide when the freeze starts and ends, tell the team early, and say what they do during the window: write to a shared sheet, keep notes locally, or hold non-urgent updates. Keep the window as short as your process allows, and schedule it away from month-end and busy selling periods. If a full freeze is not realistic, plan a delta pass: after the main import, export what changed since the first export and import that too, and test the delta procedure as part of the test import.
5. Write the go-live sequence as a run-of-show
On the day nobody should be deciding what comes next. Write the steps in order with an owner and a time next to each:
- Announce the freeze and make the old system read-only, or agree that it is treated as read-only, where your platform cannot enforce it
- Take a final export of the old system and store it safely; this is your fallback
- Run the import from the tested recipe, in dependency order: companies, contacts, deals, then activities and associations
- Reconcile counts against the pre-agreed table before anything else
- Switch integrations: forms, email sync, calendars, telephony, billing and automations. Turn on one at a time and confirm each
- Update users' access, pipelines, views and saved reports; verify permissions with a rep account
- Send the go-live message with where to get help and what has changed
6. Validate after cutover
Before you declare it done, run through a short list as a rep would use the system. Create a lead through the website form and check it appears with the right source and owner. Create a contact, a deal and a task manually. Move a deal through stages. Log an email and a call. Run the three reports people use most and compare them with the last old-system version. Confirm that automations fire once and not twice. Check that a departed employee's records are owned as the map said. Any failure here goes onto a fix list with an owner and a date.
7. Set a rollback trigger before you need it
Rollback is a decision made calmly in advance. Write down the conditions that trigger it, such as reconciliation failing beyond a stated tolerance, a business-critical integration not working by a stated time, or a data problem in the top accounts that cannot be fixed within the window. Write down who makes the call and by when. Then check that rollback is feasible: is the old system still available, is the fallback export intact, and what happens to data entered in the new system in the meantime? Keep the old system running, read-only, for a defined period after go-live; ending its subscription on the same day removes your fallback. Cancellation timing is your commercial decision, so check your contract terms.
8. Watch the first week
Most problems show up after the first few days of real use. Keep a single channel for reports of missing or wrong data and triage it daily. Look at three signals: new records created per day compared with normal, integrations failing or duplicating, and people falling back to spreadsheets, which tells you which part of the new setup is not trusted. After the first week, hold a short review, close the fix list, and only then retire the old system and archive its export. Adoption problems are a separate topic, covered in sales team not using CRM.
Where to go next
If you want the test, reconciliation and cutover run by someone who has a written recipe for it, see CRM Migration. To gauge how complex your migration is before you plan, the free CRM migration complexity estimator helps, and CRM migration cost explains what drives scope.
Questions
How long should a CRM cutover take?+
It depends on record volume, how many integrations you must switch and whether a delta pass is needed, so we do not give a fixed duration. The test import is the best predictor: time it, and plan the freeze window around that timing plus reconciliation.
What is the most important check?+
Reconciliation by segment, backed by a sample review by people who know the accounts. Counts show that records arrived; the sample review shows whether they arrived correctly.
Do we need a full freeze of the old CRM?+
Not always, but you need a plan for changes made after the final export. Either freeze for a short window or run a delta import and test that procedure beforehand.
When should we cancel the old CRM?+
Not on go-live day. Keep it available as a fallback for a period that suits your risk, and cancel only after the first-week review and after you have archived a final export. Check your contract's notice terms.
Can a migration be guaranteed lossless?+
No honest vendor can guarantee that for every platform and data set. What you can do is reconcile, sample-check and keep a fallback so that any loss is found quickly and can be corrected.