A CRM migration moves more than a collection of rows. It moves relationships, history, ownership, and the working habits that have grown around them. Before calling it complete, I want a clear account of what was in scope, how it was mapped, what was left behind, and whether the people using the new system can still do their work. That evidence belongs in the migration plan from the beginning.
Source
A platform decision creates a data decision
GDS purchasing guidance, updated in September 2026, explicitly considers build, buy, and combined approaches. Every such choice leaves a practical question about the information that must move.
I would make migration acceptance part of the selection process. Ask each option to demonstrate one difficult relationship, one restricted record, and one usable export before committing to the broader move. A platform that fits the interface but loses meaning in the data needs a different plan.
Define the migration boundary
Begin with an inventory of what the business expects to retain. People and organizations are only part of it. Lists, notes, activities, files, ownership, permissions, and relationships can carry much of the value.
Record what each export or connector actually includes. An administrator’s ability to see an object does not automatically establish that the chosen export contains every associated field or private record. Product behavior needs to be checked against the authorized scope.
Give exclusions a visible place in the plan. A historical attachment left in a searchable archive may be acceptable. An omitted ownership relationship that no one noticed is a different outcome. The business owner should understand both the destination and the exceptions.
Proposal
Reconcile meaning as well as quantities
Counts provide a starting point. Compare source totals, attempted transfers, accepted destination records, rejected rows, and known exclusions. Explain differences using a consistent unit: a person, an organization, a relationship, or an activity.
Then inspect the relationships. Did contacts remain connected to the right organizations? Did list membership survive? Were notes associated with the correct record? Can a merged duplicate still be traced to its source identifiers?
A hypothetical migration could match its total contact count and still connect several contacts to the wrong organizations. Checking a representative set of relationship paths would expose something the count alone cannot show.
Describe this figure
Two groups; no numbers, since the piece prints none. The first is the counts reconciliation, in one counting unit (a person, an organization, a relationship, or an activity): five counts in a row, source count (source totals), attempted (transfers), accepted (in the destination), rejected (rows), and excluded (known exclusions), with the differences explained in that unit, one row per object. The second, marked hypothetical, is a migration whose total contact count matches; checking a representative set of relationship paths shows, highlighted, a relationship path in which a contact, one of several, is connected to the wrong organization while the count still matches. The highlight marks what the count alone cannot show.
Use stable identifiers wherever the systems support them. Keep the mapping and exception log separate from informal notes so a later correction can be traced and repeated safely.
Ask users to perform real work
Give authorized reviewers a small set of familiar tasks: find a relationship history, prepare a meeting view, update a record, locate an attachment, and export an approved subset. Include different access roles. An administrator’s successful test does not demonstrate that ordinary users can work or that restricted material stays restricted.
Record the expected result and the observed result for each task. If a workflow has intentionally changed, make that explicit and provide the new path. Otherwise a workaround can quietly become the migration’s unresolved support burden.
Treat cutover as a decision point
AWS’s cutover guidance addresses validation, rollback ownership, and changes made after cutover. Those concerns apply directly to the planning questions a CRM move creates, even though the product-specific checks differ.
Set the decision owner, the acceptance conditions, and the last practical point for reversal. Decide how new or changed records will be handled during the transition. Returning to the old system without reconciling post-cutover work can introduce another data problem.
Keep the previous system or an appropriate archive available for the agreed period, subject to retention and access requirements. Decommission it only after the acceptance decision and remaining exceptions have been recorded.
Completion should leave a readable account of what moved, how it was checked, what changed for users, and who owns anything still unresolved. That record is part of the migration deliverable.
Proposal
What I would test next
Before a full migration, I would run a small representative transfer with relationships, files, and permission differences. The decision to scale it would depend on explained reconciliation results and successful user workflows, including a credible reversal path.