CRM MIGRATION 6 minute read
CRM migration checklist: move the work, not just the contacts
A CRM migration is successful when people can continue the right conversations with their history, ownership and next actions intact. Map the records and relationships, rehearse with a controlled sample, reconcile the results and define rollback before switching the team to the new system.
Write the reason for moving
Name the limitation the existing CRM cannot reasonably solve. It may be an unsupported workflow, a data model that no longer fits, or an operating burden the team cannot sustain. If the problem is missing ownership or inconsistent stage definitions, moving the same records may simply reproduce it elsewhere.
Identify the people and processes affected: sales, management, delivery handover and any system that reads or writes the CRM. Assign a migration owner who can resolve ambiguous records, approve mappings and make the cutover decision. The implementer cannot infer the commercial meaning of every historic note.
Inventory records and their relationships
Count companies, people, opportunities, notes, activities, attachments and active tasks separately. Document which objects are in scope and whether the destination can represent them. An export of contacts alone does not preserve a pipeline.
Work through a sample with two opportunities for the same contact, an archived company and a next action assigned to someone who has left. Agree how each will look after migration. Keep original identifiers in a controlled mapping so a reconciliation can trace a new record back to its source.
| Source item | Decision to document | Acceptance check |
|---|---|---|
| Contact and company | Identity and duplicate rule | Correct person remains linked to the correct company |
| Opportunity stage | Old-to-new stage meaning | Active work keeps its commercial status |
| Task and owner | Active assignee and due date | Someone can see and perform the next action |
| Notes and files | Included history and file access | A normal user can retrieve required context |
| Permissions | Who can view, edit and export | Everyday roles pass the agreed access checks |
Clean only with an agreed rule
Decide which source is authoritative when values conflict. Do not silently replace a verified company name with an older spreadsheet value or combine two people because they share a generic email address. Put unresolved identities in a review queue.
Preserve the original export under appropriate access controls. Record every transformation: stage conversion, date/time interpretation, owner replacement and deduplication. The transformation log should explain what happened without copying unnecessary personal information into an unrestricted project document.
Rehearse the cutover and the way back
Use a staging destination and a representative controlled sample. Reconcile counts by record type and stage, then inspect relationships and real working tasks. A matching total does not prove that notes are attached to the correct opportunity.
Agree when the source becomes read-only, how changes during the migration window are handled and what would trigger rollback. Keep outbound workflows disabled during rehearsal so imported history cannot accidentally trigger customer messages. Test the export or restore procedure rather than assuming that the menu option is enough.
Retire the old system deliberately
After cutover, have each responsible role complete its core task in the destination. Confirm that website sources, reporting and approved integrations point to the new system. Watch for retries from the previous integration creating a second version of the same enquiry.
Keep an agreed reconciliation period and a route for reporting missing context. Decide when access to the old system ends and how retained exports will be managed. That decision should follow the business's requirements, not an arbitrary rule to retain every record forever.
Questions before you start
Should we import every historic record?
Only after deciding which history is useful and appropriate to retain. Separate active opportunities, necessary history and records that need review. More imported records do not automatically create a more useful CRM.
Is a successful CSV import enough?
No. Check relationships, stage meanings, ownership, permissions and next actions. Counts are one reconciliation measure; users must also be able to continue the actual work.
Can we keep both CRMs updating at once?
That needs an explicit synchronization design, conflict rules and ownership of corrections. For a bounded migration, a controlled cutover is often easier to reason about than two independent systems accepting changes.
Assess the move before importing records
Share the business reason for moving and the record types involved. Keep customer exports out of the initial enquiry.