CRM Migration Checklist: 12 Steps from Audit to Adoption

October 16, 2026 · 13 min read

The dangerous part of a CRM migration is rarely the import button. It is discovering, after your sales team has switched systems, that an account’s owner is missing, a deal’s history is disconnected, or an automation quietly sent the wrong follow-up. A workable migration plan protects the relationships between records and the workflows around them, not just the row count.

This CRM migration checklist is for teams moving from spreadsheets, an older CRM, or several disconnected tools into a new platform or a custom CRM. It covers the decisions to make before you copy data, a rehearsal that exposes errors, and the controls to use during and after cutover. No checklist can promise zero downtime or zero data loss; the goal is to define what “complete” means, test it, and have a recovery option.

First, decide what is actually moving

“We have 20,000 contacts” says little about migration complexity. You may also have organizations, deals, activities, attachments, consent records, custom fields, ownership rules, saved views and automations. A spreadsheet-to-CRM move often needs a new data model; a CRM-to-CRM move needs a mapping between two existing models. A move into a custom CRM can change the workflow itself, so decide which old behaviors should not be recreated.

Salesforce’s data migration guidance emphasizes planning, cleaning, mapping and testing. Apply that sequence even if Salesforce is neither your source nor destination. Treat the source system’s current state as evidence to inspect, not a specification to copy blindly.

1. Name an owner and define a migration contract

Choose one business owner who can resolve questions about sales stages, record ownership and what counts as an active customer. Assign a technical owner for extracts, transforms, imports and rollback. Agree on a short written contract:

• Which record types and date ranges are in scope?
• Which system is authoritative for each field after launch?
• What must be searchable on day one, and what may arrive later?
• What makes a record invalid or a migration unacceptable?
• Who signs off, and what evidence will they review?

Without this, a technically successful import can still be a business failure. “All records loaded” does not mean a rep can find the correct account before a call.

2. Inventory sources, dependencies and hidden copies

List the CRM, spreadsheets, shared inboxes, forms, billing tools, marketing platform and any manual exports that currently create or update customer data. Record the owner, export method, update frequency, volume and whether the source can be frozen during cutover.

Include inbound and outbound integrations. If a website form keeps writing to the old CRM after the new one goes live, your data is split immediately. Draw a simple flow from lead capture to sales handoff to invoicing. StadiaSoft’s guide to connecting disconnected business systems is relevant if the move is part of a wider integration cleanup.

3. Profile data before deciding what to keep

Export a read-only snapshot and measure completeness, duplicates, invalid values and relationships. For example: how many opportunities refer to a missing account? How many contacts have no owner? Which “lead source” values mean the same thing? Group by source and age so you can decide whether old records belong in the live CRM or an accessible archive.

Do not silently delete inconvenient data. Define retention and deletion with the organization responsible for privacy and compliance. Keep an audit trail of exclusions, especially for records associated with active customers or contractual obligations. If consent or suppression status matters to outreach, migrate it as a first-class field rather than treating it as an optional note.

4. Build a field map with transformation rules

A mapping sheet should describe more than source and destination column names. It needs type, required status, transformation, default, owner and validation. Here is a small illustrative extract:

This table is a template, not a universal schema. A destination may require different objects or an extra consent field. Keep source IDs in a crosswalk so a re-run can update the same destination records and preserve relationships. Document timezone, currency, date format and enum changes explicitly. A wrong timezone can move a follow-up into the next day even when the date looks plausible in a CSV.

5. Decide how to identify duplicates

“Deduplicate contacts” is not a safe rule by itself. Two people can share an email inbox, and one person may use several emails. Agree on matching keys and a review path. A practical policy could use a stable source ID first, then a reviewed combination of normalized email, organization and name. Define which value wins when duplicates disagree: the newest verified value, a designated source, or a human decision.

Keep a merge log with the old IDs, new ID and reason. Test edge cases such as parent/subsidiary companies, renamed businesses and former employees. Make it easy to undo a bad merge; rebuilding relationship history later is much harder than pausing on an uncertain match now.

6. Migrate in dependency order

Accounts usually need to exist before contacts and opportunities can point to them; users and teams may need to exist before ownership can be assigned. Write the order down. A possible sequence is users and reference values, accounts, contacts, deals, activities, attachments and then calculated fields or automation-derived data. Your own schema may demand a different order.

Import in bounded batches and record each batch’s source count, destination count, errors and crosswalk. Do not rely on a tool’s “success” banner. Some importers accept a row while dropping an unsupported field; inspect field-level errors and spot-check important accounts.

7. Run a representative rehearsal

Do a full dry run in a safe environment with realistic data volume, not ten hand-picked clean rows. Include large accounts, duplicates, records with missing optional fields, old closed deals, attachments and non-ASCII names. Time the export, transform, import and validation stages. Record failures and update the mapping sheet before the next rehearsal.

Salesforce’s import checklist reinforces checking required fields and data preparation before loading. The point is broader than one platform: a rehearsal should prove that your actual data and workflow survive the move. If you are replacing several spreadsheets, test how the team will create a new record as well as how it will read an imported one.

8. Test integrations, permissions and automations

Repointing a connector to the new CRM is not enough. Verify form submissions, email sync, billing updates, marketing suppression, webhooks, reports and exports using test records. Know whether the new system receives historical updates from integrations or only new events. If updates can arrive late or twice, build an idempotent processing and reconciliation plan; our webhooks vs APIs guide explains the failure modes.

Test with each real role. A sales representative may need access to assigned accounts but not payroll-adjacent fields; an operations user may need export rights without permission to change deal stages. A migration that broadens access accidentally is a security incident, not a usability quirk. Record who approved the access matrix.

9. Agree on cutover and write freeze

Choose a cutover window based on business activity, not only the technical team’s calendar. Announce when the old system becomes read-only, where users should enter new work, and who handles urgent exceptions. If a freeze is impossible, design a delta import for changes made after the initial extract and prove it in rehearsal.

Write a minute-by-minute runbook: final backup, source freeze, final extract, transforms, load, validation, integration switch, smoke test, business sign-off and opening the new system. Assign an owner and a stop/go decision to each stage. Keep the old system accessible but read-only until the agreed retention and validation period ends.

10. Prepare rollback before cutover

Rollback is not just “restore the old database.” After the new CRM accepts writes, reversing direction can create two conflicting histories. Define the exact point at which you can safely switch users back, how you will capture any new entries, and whether integrations can be repointed without duplicate sends. Keep tested backups, exports, configuration snapshots and credential access available to the incident team.

Set objective stop conditions before the migration. Examples: a critical integration fails its smoke test, active accounts are missing, or ownership is wrong beyond a defined tolerance. Do not invent a percentage because it sounds reasonable; agree the threshold with stakeholders based on business risk. If the rollback plan cannot handle a later failure, call it a contingency plan and state its limits plainly.

11. Reconcile records and get user acceptance

Compare more than total counts. Reconcile counts by record type, status, owner and date band. Check key sums where relevant, such as open pipeline by stage, while accounting for legitimate transformation differences. Sample records from high-value accounts and every important edge case. Follow the full path from account to contact to deal to activity and attachment.

Ask frontline users to complete a short task list: find an account, log a call, move a deal, create a follow-up and locate a past conversation. Save defects with severity and owner. A technically green migration is not finished until the people who work in the CRM can complete their jobs. If major workflows have changed, provide brief role-based training and a place to report issues.

12. Monitor the first 30 days and close the loop

Track import exceptions, sync failures, duplicate creation, missing ownership, user access requests and support tickets. Run scheduled comparisons between source snapshots and the new CRM until the business owner accepts that reconciliation is complete. Review reports and automations after real activity accumulates; a dashboard that looked correct on day one can still classify new records incorrectly.

At the end of the agreed validation window, document unresolved exceptions, decide what to archive and confirm the owner of the ongoing data-quality process. This is also when to improve the workflow rather than recreate old workarounds. If you need a roadmap for a tailored replacement, see our custom CRM development cost guide and spreadsheet-replacement solution.

A sign-off sheet you can copy

For each row below, record the evidence link, result, owner and date. A checkbox alone is too easy to tick without proof.

If the migration includes custom connectors, StadiaSoft’s API integration service can help map ownership, retries and reconciliation—not merely move data once. The best migration plan leaves the new CRM usable on Monday morning and explainable six months later.

Common questions

How long does a CRM migration take?

There is no responsible duration without knowing the number of systems, data quality, integrations, permissions and review requirements. A small clean import can be quick; mapping and acceptance can dominate a larger move. Ask for a plan with rehearsal, cutover and stabilization separately instead of one unqualified “migration time.”

Should we migrate every historical activity?

Only after deciding what users, reporting and retention obligations require. Old data can sometimes remain in a searchable, access-controlled archive. But do not omit history that staff need to serve active customers or prove consent. Document the boundary and test the retrieval process.

Can we run the old and new CRMs in parallel?

Yes, for a defined validation period, but avoid two uncontrolled writable sources. State which system owns each field and how changes cross the boundary. Parallel operation without ownership rules often creates more reconciliation work than it prevents.

When should we use a custom CRM rather than migrate to a standard one?

Consider a custom build when a central workflow, data relationship or integration is persistently awkward in standard tools and the business value justifies ownership of the software. Compare the full lifecycle—discovery, delivery, hosting, security, support and future changes—against configurable platforms. Do not commission custom software just to preserve every old field.

Want a second pair of eyes on your cutover plan? Tell StadiaSoft what systems you are moving from and what must keep working. We can help identify the risky joins, integrations and sign-off checks before anyone presses Import.

Sources reviewed October 6, 2026: Salesforce data migration guidance and Salesforce import checklist. The template and examples above are illustrative, not a report of a StadiaSoft client migration.