CRM migration: what to preserve before changing platforms

In short

Before changing CRM platforms, agree which customer records, relationships, permissions and working stages must survive. Test a representative slice, reconcile it to the source and check that people can complete real work in the new system before retiring the old one.

In this guide

Decide what the move must improve

Moving from one CRM to another is often described as a data transfer. The commercial risk is wider. A contact may arrive without its company, an opportunity without the last conversation, or a customer without the person who owns the next step. The import can report success while sales and service lose context.

Start with the reason for moving. Is the problem unreliable reporting, poor follow-up, disconnected marketing, cost, or a platform that no longer fits the business? Name the few workflows that must work on day one. A new interface is not a benefit if it reproduces the same missing ownership and inconsistent stages.

Inventory the working record

Ask the people who use the CRM to open recent, awkward and long-running records. Capture what they need to answer a customer or make a decision. The export specification should follow that inspection, not the other way around.

Record or control	What must be understood	Acceptance check
Identity	Customers, contacts, companies and stable source IDs	The same real-world person or business is not duplicated
Relationships	Contact-to-company, opportunity-to-customer and parent-child links	Related records remain connected after import
History	Notes, activities, promises, attachments and relevant dates	A user can reconstruct the last meaningful interaction
Operating state	Stage meanings, owner, next action and open exceptions	Active work has an owner and a usable next step
Permissions	Role access, suppression, consent and restricted information	Only appropriate people can see and use each record

Not every old field deserves a place in the new system. Separate records needed for ongoing work from information retained for a defined reason and information that should not be carried forward. Record the decision and its owner.

Map meaning, not just fields

A field called "Qualified" may mean different things to two teams. A deal stage may trigger a reminder, forecast or handoff. Map its business meaning, allowed values, owner and downstream uses before choosing the destination field. Keep source IDs in a controlled crosswalk so an imported record can be traced back and relationships can be checked.

Salesforce's migration guidance recommends defining objects, preserving legacy IDs, importing in dependency order and validating counts and exceptions. HubSpot's import guidance likewise distinguishes records from their associations and explains the role of unique identifiers. Those are platform-specific capabilities to verify in the chosen edition and configuration, not a substitute for a business mapping decision.

Decide how duplicates will be resolved before import. Do not automatically merge two records because a name or email matches. A shared inbox, changed employer or different trading entity can make a plausible match wrong.

Protect customer information through the move

Limit migration access to the people who need it. Control exports, temporary files, test environments, supplier access and deletion of working copies. The OAIC's APP 11 guidance covers reasonable steps to secure personal information and to destroy or de-identify it when it is no longer needed, subject to applicable exceptions. The exact obligations depend on the organisation and the data.

Preserve the provenance of marketing permissions and opt-outs rather than treating a successful contact import as permission to send. ACMA's spam guidance sets out consent, sender identification and unsubscribe requirements for commercial electronic messages. Have the responsible team review how those controls will operate in the new platform before any campaign is enabled.

Test before cutover

Select a representative slice.
Include active opportunities, repeat customers, incomplete records, complex relationships, opt-outs and more than one business unit where relevant.
Import into a controlled test environment.
Check required fields, associations, ownership, access and failed rows. Compare individual records as well as totals.
Run real tasks.
Ask users to respond to an enquiry, update an opportunity, resolve a service issue and produce the management view they rely on.
Agree the cutover and fallback.
Set a source-system change window, a reconciliation owner and a route back if critical work cannot be completed.

Keep the old system accessible on a controlled, read-only basis for the agreed transition period. That is not a reason to run two uncontrolled sources of truth indefinitely.

Accept the working result, not the import job

Reconcile records in scope, relationships, failed rows and suppressed contacts. Then inspect the business result: can the team see the current owner, last commitment and next action? Do the pipeline and customer reports mean the same thing as the agreed baseline? Record exceptions with an owner and deadline instead of hiding them behind an overall completion percentage.

Advery can help define the migration decision, coordinate system providers and test the customer and operating workflows that matter after cutover. The related lead-handling guide shows why ownership and next actions matter once the data is in place. Start by sampling the records and workflows people rely on today.

Sources and guidance

ScopeThis article provides general operational information for Australian businesses. It is not legal, privacy, cyber security, financial or accounting advice. Confirm obligations for your business and use case.

About Advery

Advery draws on 15+ years of enterprise experience across operations, customer growth and technology, connecting leadership decisions with hands-on delivery.

Explore the experience behind Advery