Moving a CRM to a new host, whether from on-premises servers to the cloud or from one cloud environment to another, is rarely hard because of the copying. It is hard because of everything the CRM quietly depends on. This checklist walks through the work in the order it tends to matter, so the cutover weekend is boring rather than dramatic.

Phase One: Inventory What You Actually Have

Start by documenting reality, not the original design. Look for the following:

• Every component: application servers, database, file storage, scheduled jobs, search indexes, caches and message queues.
• Every inbound and outbound integration, including the ones nobody remembers building. Check outbound firewall rules, API key lists and scheduled task logs for clues.
• Custom code, plugins, extensions and database-level objects such as stored procedures, triggers and views.
• Email sending and receiving paths, including DNS records for sender authentication.
• Certificates, secrets and where each is stored.
• Users, roles, single sign-on configuration and service accounts.

Integrations are the usual source of surprises. A forgotten nightly export to a finance spreadsheet will announce itself loudly on the first Monday after cutover unless you find it first.

Phase Two: Define Success and Limits

Agree on measurable acceptance criteria before touching anything. Examples include record counts matching between old and new systems, key workflows completing end to end, and report outputs agreeing on a sample of known figures. Also agree on the maximum downtime the business will tolerate and the point at which you will roll back instead of pressing forward.

Put a named person in charge of the go or no-go decision. Committees are poor at making that call at two in the morning.

Phase Three: Build and Rehearse

Construct the target environment from infrastructure code where possible, so it can be rebuilt identically. Then rehearse the migration at least once with a full copy of production data in a protected environment, and time each step. A rehearsal reveals schema mismatches, character-encoding problems, permission gaps and underestimated data transfer durations. If rehearsal data contains personal information, protect it as strictly as production, or mask it, and follow the privacy rules that apply in your jurisdiction.

Repeat the rehearsal until it runs without manual improvisation. A migration that depends on someone remembering a command from memory is not ready.

The Migration Checklist

Stage	Check	Done when
Before	Integrations inventoried and owners notified	Every connection has a named contact
Before	Backups verified by an actual restore	Restore succeeds in a test environment
Before	DNS time-to-live lowered ahead of cutover	Lower value has had time to propagate
Before	Rollback plan written and rehearsed	Steps and decision trigger documented
During	Writes frozen or queued on the old system	No records changing during final sync
During	Final data sync completed and compared	Record counts and sample checks match
After	Integrations re-pointed and tested	Each connection passes a live test
After	Monitoring and alerting active on new host	Alerts fire in a deliberate test
After	Old environment retained read-only for a period	Retention period agreed and calendared

Phase Four: The Cutover

On the day, follow the written runbook rather than improvising. The typical sequence is: announce the maintenance window, freeze changes, take a final backup, perform the final synchronization, run validation checks, switch traffic, and confirm with a small group of users before wider announcement.

Two practices reduce risk considerably. First, keep the old environment intact but read-only until you are confident, so that rolling back is a configuration change rather than a rebuild. Second, communicate clearly to users what is happening, what they should avoid doing during the window, and whom to contact if something looks wrong.

Phase Five: Validate and Stabilize

The first days after cutover deserve closer attention than the cutover itself. Watch error logs, queue depths, integration failures and database performance. Ask a few power users to run their normal routines and report anything odd, particularly around reports, email logging and automation rules, which often behave subtly differently on new infrastructure because of time zone, locale or permission settings.

Scheduled jobs deserve a specific check. Confirm they are enabled on the new host and that they are not running in both places, which can cause duplicate emails or double-processed records.

A Hypothetical Example

Imagine a team migrating a CRM database and application to new cloud hosting over a weekend. Their rehearsal succeeded, but during the live cutover a nightly integration to a billing system failed silently because the billing system only accepted connections from the old server’s network address. The team caught it because their checklist included a live test of each integration after switching traffic, not just a check that the application loaded. They updated the allowlist, reran the sync and avoided a week of mismatched invoices. The lesson is that a successful login screen proves very little.

Common Mistakes to Avoid

• Treating DNS changes as instant. Cached records can send some users to the old system for a while.
• Migrating and upgrading the CRM version in the same step. Changing two things at once makes failures harder to diagnose.
• Forgetting file attachments, which often live outside the database.
• Decommissioning the old environment too early.
• Skipping a post-migration review, so the same lessons are relearned next time.

Frequently Asked Questions

How long should a migration window be? Base it on your rehearsal timings plus a generous margin for validation and rollback. Do not estimate from file sizes alone.

Should we migrate in phases or all at once? Phasing by business unit or region reduces risk when the CRM supports it, though it prolongs the period of running two environments. Choose based on how interdependent your data is.

What if rehearsal and production behave differently? Treat the difference as a finding. Compare configuration, data volume and network paths until you can explain it.

How long do we keep the old environment? Long enough to cover at least one full business cycle, such as a month-end close, then decommission with sign-off. Check any retention obligations that apply to you.

Who should be involved besides IT? Sales operations, finance, customer support and whoever owns integrations. They know what the CRM is used for in practice.

Next Step

Start the inventory now, even if migration is months away. Ask every department which systems send data to or receive data from the CRM, and record each answer with an owner.