A CRM migration plan that protects customer history

A CRM migration is a controlled change to customer history, not a file-transfer task. Records, activities, ownership, permissions, integrations, and working habits all move on different schedules.

The technical import is only one part of the work.

The safest plans start by deciding what must remain true after cutover. A sales manager may need active pipeline stages and recent context. A service lead may need account relationships and open requests.

Finance may need identifiers that connect customer records to billing. Those requirements define the migration scope.

Set the scope and source of truth

Inventory every system that holds customer information, including spreadsheets and team-owned tools. For each, record the object types, responsible owner, update frequency, sensitive fields, and downstream uses.

This step often reveals that a field is copied into several places with different meanings.

Decide which records and history are necessary for the first release. Old duplicates, obsolete opportunities, unused custom fields, and attachment archives do not automatically belong in the new CRM.

Keep a retention decision for excluded material so it can be found later without quietly cluttering the new operating system.

Map and reconcile customer data

Write a contract for every important field

Create a migration map with source field, destination field, transformation rule, allowed values, owner, and sample records. Include associations between contacts, companies, deals, requests, and activities.

A migration can pass a row-count check while breaking those relationships, which is why record-level examples matter.

Define a duplicate policy before loading anything. Explain how the team identifies a likely match, when it merges records, what information wins when values conflict, and when it escalates a record for review.

Ambiguous records should remain visible to a reviewer instead of being merged because two names look alike.

Rebuild workflows before cutover

Separate useful automation from inherited complexity

Document the existing routing, notifications, task creation, campaign enrollment, service escalation, and reporting logic. For each workflow, write the trigger, conditions, action, exception path, owner, and evidence of completion.

This turns a pile of legacy rules into a set of choices the new team can evaluate.

Test rebuilt workflows with representative scenarios before live records arrive. Include missing data, repeated submissions, reassigned ownership, invalid values, and a person who should be excluded.

The goal is not to recreate every old rule. It is to restore the workflows that support an agreed process and retire the ones nobody can explain.

Cut over with checks and a recovery path

Choose a cutover window and publish what will freeze, who can make changes, how new inquiries are handled, and where teams report issues. Take a preserved export of the source data and record the exact import version.

A recovery plan should say how the team will correct a bad load without overwriting new activity created after launch.

After cutover, reconcile totals and inspect sampled records with each functional owner. Check key associations, permissions, routing, open work, and reports before declaring success.

Keep a daily issue review during the first week, then convert recurring issues into training, data fixes, or explicitly owned backlog items.

1. Count records by object, owner, status, and active versus archived state.
2. Sample simple records, highly connected records, recent records, and known exceptions.
3. Confirm timestamps, notes, associations, attachments, consent history, and open tasks.
4. Test that restricted records remain restricted under real user roles.
5. Record every correction so the final import recipe can be reproduced.

Rehearse with a migration ledger

Run at least one representative rehearsal in a non-production destination. For every load, record the source extract, transformation version, import settings, start and finish times, record counts, rejected rows, and reviewer sign-off.

The ledger turns a migration from a sequence of memories into a repeatable procedure. When a mapping changes, rerun the affected checks instead of assuming the rest of the import still behaves the same way.

Use exceptions as design evidence

Do not hide rejected or ambiguous records in a miscellaneous file. Group them by cause and assign a decision: correct at source, transform, archive, merge, or hold for an owner. The pattern may reveal a broken field definition.

Prepare people for the first real customer record

Training should follow roles and moments, not a tour of every screen. Let a representative create, update, hand off, and recover a realistic record. Include what to do when the expected field, owner, or automation is wrong.

Publish a short support route for launch week. Distinguish access problems, data defects, workflow questions, and enhancement requests so urgent corrections do not disappear inside a general improvement backlog.

Keep the old system available as read-only when the approved plan permits it, and tell people which activities must never return there. Split working histories are harder to reconcile than a defect found in the new record.

Close training with one verified task each role can perform without the project team. Record questions that point to unclear process ownership, not only screen familiarity.

Open a cutover control room

Use one decision log during the cutover window. Record the issue, affected records or users, severity, current owner, containment, evidence, decision, and next check.

Keep discussion channels linked to the log rather than treating chat as the record.

Set decision rights before the window begins. The data lead may approve mapping corrections, a functional owner may validate workflow behavior, and a release owner may pause the cutover. Everyone should know who can make which call.

• Proceed: checks passed and the next load can begin.
• Correct forward: the issue is bounded and new activity can be preserved.
• Hold: stop the affected stream while investigation continues.
• Restore: use the approved recovery path and communicate the impact.