You can run a flawless data migration and still have a bad go-live. The weak points on cutover day are rarely technical. They are unclear ownership, a stale final extract, users who were told the wrong date, and nobody agreeing in advance what “failed” looks like.
This is a checklist-driven view of the final stretch. Adjust the timings to your size; the sequence holds for most teams.
Settle the Cutover Window Early
Pick a window when the business can tolerate reduced access: often a weekend or an evening at the end of a reporting period, but not the last day of a quarter when sales are closing deals. Tell people the freeze window in writing at least a couple of weeks ahead, and again two days before.
Name a cutover lead with authority to make the go or no-go call. A committee at midnight is not a decision process. Also name who covers integrations, who verifies data, and who talks to users.
The Week Before
Several things need to be true before cutover begins, not discovered during it:
- A full trial migration has been completed in a sandbox and signed off by a business user, not just IT.
- Integrations (email, calendar, billing, marketing tools) have been tested against the new system.
- Users have accounts, correct permissions and have had training on the tasks they do daily.
- The rollback plan is written and the old system will remain available, read-only at minimum, for an agreed period.
- You have a list of in-flight items that cannot wait: scheduled campaigns, automations, recurring reports, quotes awaiting approval.
Decide now which old-system automations and scheduled jobs must be turned off at cutover, or customers may get messages from both systems.
The Cutover Sequence
| Step | Action | Owner check |
|---|---|---|
| 1 | Announce freeze; set old system to read-only or restrict edits | Cutover lead confirms |
| 2 | Take final backup and extract of the old system | Data owner |
| 3 | Run final (delta) import into the new system | Migration engineer |
| 4 | Run verification queries: record counts, totals, spot checks | Business verifier |
| 5 | Re-point integrations; switch off old automations | Integration owner |
| 6 | Smoke test: create, edit, report, email sync, mobile | Pilot users |
| 7 | Go or no-go decision | Cutover lead |
| 8 | Announce go-live with login steps and support contacts | Communications lead |
Do not skip step four because the import reported success. “Imported successfully” means the tool finished, not that your data is right.
Verification That Means Something
Choose checks before the day, so you are not inventing them at 11pm. Reasonable examples are record counts by object compared with the final extract, the total value of open deals, a handful of named accounts checked end to end, and the number of contacts per owner. Pick ten or so records the sales lead knows well and confirm each field by eye.
Check relationships, not just rows. Contacts attached to the right accounts, activities attached to the right contacts, deals attached to the right owners. Broken links are the commonest silent failure.
Define Rollback in Advance
Rollback is easiest to make sensible when it is decided before you are tired. Agree on triggers: for example, “verification shows records missing or misattached beyond a stated tolerance,” or “email sync does not work for pilot users after a stated time.” Agree also on the point of no return. Once users create new records in the new system, rolling back means reconciling two sets of changes, so the decision gets harder with every hour.
Keep the old system intact, with access restricted, until you are confident. Do not decommission it on go-live day. Check licence and contract terms with the old vendor so you are not forced to cancel before your safety window ends.
A Hypothetical Example
A small team goes live on a Saturday. The final import finishes, and counts match. In the smoke test, the pilot rep’s calendar events appear, but emails sent from the new CRM are not logging against contacts. The integration owner finds the mailbox connection was authorised with a test account. They re-authorise with the correct service account and retest. The cutover lead holds the go decision until the retest passes, and sets the announcement for Sunday evening instead of Saturday afternoon.
Delaying the announcement by a few hours cost nothing. Announcing and then fixing in front of fifty users would have cost goodwill.
Hypercare: The First Two Weeks
The first fortnight after go-live is its own phase, and it deserves a plan:
- A visible channel for questions and a named person monitoring it at set times.
- A daily short list of issues, triaged into “blocks work” and “annoying.”
- Quick reference guides for the five tasks people ask about most.
- A check at the end of the first week for adoption signals: who has logged in, who is still updating spreadsheets.
- A review of data quality issues users report, because they will find records you missed.
Resist the urge to add new configuration requests during this period unless they fix something broken. Stabilise first.
After the Dust Settles
Hold a short retrospective within a few weeks. Capture what the checklist missed and update it; you or someone else will run another cutover eventually. Confirm the old system’s retirement date, archive its final export, and document where it lives.
Frequently Asked Questions
Should we go live on a weekend? Often yes, since fewer people are mid-task. Make sure the support people who will be needed are available, and avoid periods when the business is under peak pressure.
Can we migrate in phases instead of one cutover? Yes, by team, region or object. Phasing lowers risk per step but means running two systems and handling integrations twice, so weigh that complexity.
How long should the old system stay available? Long enough to catch problems that surface in a normal business cycle, often through at least one month-end. Check contract terms to avoid paying for more than you need.
What if users refuse to switch? Make the old system read-only so there is one place to enter data. Dual entry quietly destroys both datasets.
Who decides go or no-go? One named person, ideally the business owner or the delegated cutover lead, informed by the verification results rather than by optimism.
Next Step
Write the rollback triggers and the point of no return on one page this week, and get the business owner to sign it. Everything else on the checklist is easier once that is agreed.
By CRMCloudNest Editorial · Updated November 4, 2026
- CRM cutover
- go-live checklist
- rollback plan
- CRM migration