Buying guide - Migration
Planning a CRM data migration that people trust.
Users judge a new CRM in the first hour, by looking up an account they know well. If that record is wrong, adoption is damaged before training finishes. This guide sets out the method we use - profiling, cleansing, mapping, trial loads and reconciliation - and, just as importantly, what is usually not worth bringing across.
At a glance
- Who this is for
- Teams planning a CRM move and deciding what history to carry.
- Key insight
- Scope control matters more than tooling. Less data, better validated, wins.
- Related
- The ERP migration guide covers stock, balances and reconciliation.
Method
Eight steps, in order.
Steps one to three happen before anyone writes a mapping. That is deliberate.
- 01
Profile the sources
Count records, measure completeness by field, find duplicates and identify what has no unique key. You cannot plan a migration you have not measured.
- 02
Decide what travels
Explicitly agree which objects and which date ranges migrate. Not all history belongs in the new system; some of it belongs in an archive.
- 03
Cleanse at source
Deduplicate, standardise states, phone formats and industry values, and retire obsolete records. Cleansing in the old system is cheaper than cleansing mid-load.
- 04
Map fields and owners
A documented mapping from every source field to a target field, with transformation rules, default values and record ownership decided.
- 05
Trial load
Load into a sandbox, then have real users look at their own accounts. Sample checks by consultants find far fewer problems than users recognising their own data.
- 06
Validate and reconcile
Record counts, relationship integrity, pipeline value totals and spot checks against the source. Agreed tolerances, signed off.
- 07
Freeze, final load, verify
A short freeze on the source, the production load, then verification against the same reconciliation checks before users are let in.
- 08
Post-migration checks
Re-run reconciliation after a week of live use, watch for duplicates created by integrations, and confirm reporting matches expectations.
Scope
What to migrate, and what to leave behind.
| Object | Recommendation |
|---|---|
| Accounts and contacts | The foundation. Deduplication and a decided matching key - usually email or a normalised company identifier - determine the quality of everything else. |
| Open opportunities | Essential. Map stages carefully; old stage names rarely align one-to-one with a redesigned pipeline, and forecast figures depend on getting this right. |
| Closed-won history | Valuable for reporting and account context. Often migrated in summary rather than in full detail. |
| Closed-lost history | Rarely worth full migration. A summary or an archive usually serves the same analytical purpose at a fraction of the effort. |
| Activities and notes | The largest volume and lowest value per record. Consider a cut-off date, or attaching a read-only export to the account instead. |
| Emails | Frequently better left in the mail system, where it is still searchable, than bulk-loaded into CRM records. |
| Attachments | Check storage limits and per-file constraints early. Attachment volume is a common late surprise in a load plan. |
| Users and ownership | Decide what happens to records owned by departed staff before loading, not after users notice. |
Cleansing
Five data problems to resolve before loading.
- 01
Duplicates
Agree the matching rule and the survivorship rule - which record wins and which fields merge - before deduplication starts. Reversing a bad merge is far harder than avoiding it.
- 02
Inconsistent picklists
Years of free typing produce a dozen spellings of the same value. Standardise to the target picklist during mapping, and reject rather than silently default unknown values.
- 03
Missing relationships
Contacts with no account, opportunities with no contact. Decide the rule - create a placeholder, attach to a holding account, or exclude - in advance.
- 04
Formatting
Phone numbers, postcodes, states and dates. Australian formats matter here, particularly for telephony integration and mail merges.
- 05
Dead records
Contacts who left years ago and accounts that no longer trade. Migrating them dilutes reporting and inflates the record counts everyone will use to judge the load.
Rather work through your own numbers?
A consultation covers the same ground against your systems, volumes and timeline instead of a general range.
Strategy
Fresh start or full history.
Faster, cleaner
Fresh start
- Active customers and open pipeline only
- History retained as a read-only archive
- Much shorter validation cycle
- Users adopt a clean, trusted dataset
- Some historical reporting stays in the old system
Slower, complete
Full history
- All objects and full history migrated
- Continuous reporting inside one system
- Significantly larger cleansing and validation effort
- Higher risk of importing legacy data problems
- Justified where history is used operationally
CRM migration questions buyers ask
- Should we migrate all our historical CRM data?
- Usually not all of it. Open pipeline and active customer records are essential; closed-lost opportunities and years of activity notes usually are not. A read-only archive of the old system, or an export attached to the account, preserves access without importing the problems.
- Who should own data cleansing - us or the implementer?
- Both, in different parts. Only your team can decide which customer is the real one or whether an account is still trading. The implementer should provide the profiling, the duplicate candidates and the tooling so those decisions are quick to make.
- How do we know the migration worked?
- Reconciliation against agreed criteria: record counts by object, open pipeline value matching the source, relationship integrity, and users confirming their own accounts look right. Acceptance should be defined before the load, not judged afterwards.
- What causes duplicates to appear after go-live?
- Usually an integration creating records without a matching rule - a web form, a marketing tool or an accounting sync. Migration gets the blame; the integration design is the cause. Matching rules belong in the integration specification.
- Can we migrate in stages?
- Yes, and it often reduces risk. Load accounts and contacts first, verify them, then opportunities, then supporting history. Staged loading also makes reconciliation failures much easier to isolate.
Where to go next
Related buying guides
Related architecture and services
Relevant platform guides
Not sure what your data will look like on the other side?
A short profiling exercise on your existing records will tell you the deduplication effort, the mapping gaps and the realistic scope before you commit to a plan.