A migration is not successful because the import job turns green. It is successful when people can find the right customer, understand the history, continue the work, and reconcile the information they rely on. That requires decisions about identity, authority, exceptions, and cutover well before anyone uploads a file.
Inventory the operational dependency
List the sources that actually support work: CRM tables, shared spreadsheets, document folders, billing records, and the small trackers teams maintain outside the formal system. Identify who uses each source and what breaks if it disappears.
Do not assume every field deserves migration. Classify information as active operational data, required history, reference material, or a candidate for retirement. Retention and deletion decisions need the appropriate business and policy owners; they should not be made implicitly by an import script.
Resolve identity before mapping columns
A person can change employers. A company can have multiple trading names. A shared email address can represent several people. Establish stable identifiers and explicit rules for matching customers, contacts, and engagements.
Create an exception path for uncertain matches. Automatically merging two customers because their names are similar can destroy context. Preserve source identifiers and a mapping record so the team can investigate where a new record came from and reverse a mistaken association where feasible.
Rehearse with difficult records
Use representative samples, including duplicates, inactive accounts, partial payments, attachments, missing owners, and unusual date formats. Test transformations in a staging environment before the final move.
Compare more than record counts. Reconcile relationships, selected field values, financial control totals where relevant, and whether users can complete key tasks. Official migration tooling such as AWS DMS distinguishes data transfer from validation; the same principle applies even when the chosen migration method is different.
Plan the moving boundary
Decide how changes made during migration are captured. Will there be a write freeze, a final incremental transfer, or a controlled period of parallel operation? Who tells users which system is authoritative at each stage?
Define a go/no-go owner, a rollback decision window, and the handling of work entered after cutover. A rollback plan that restores yesterday’s database but loses today’s customer commitments is incomplete. Rehearse the decision, not just the technical steps.
Keep evidence after the move
Retain the agreed mapping, transformation rules, validation results, exceptions, and approvals. Give users a clear route to report missing or incorrect information during stabilization.
A migration scope should state what is included, what will remain in an archive, how quality will be checked, and who accepts the result. Centravon™ discovery can use this evidence to distinguish a simple import from a broader data-remediation project before delivery commitments are made.
Your discussion checklist
- Name the authoritative source for each important record type.
- Define identity and duplicate-resolution rules.
- Rehearse with difficult records, not only clean samples.
- Reconcile counts, relationships, values, and business tasks.
- Document the freeze, final transfer, stop decision, and rollback window.
Further reading
Primary references for the technical principles discussed.
What would this look like
in your organization?
Share your source-system inventory and a redacted sample of the hardest records to move. We can discuss the migration questions that belong in your custom CRM scope.
Start a scoping conversationRequirements, investment, and delivery terms defined for your engagement.
