CRM migration checklist: moving without losing data
In a CRM migration it is rarely the records that get lost, but everything around them: notes, files, first source and consents. This guide gives a seven-step CRM migration checklist: inventory, what moves and what is archived, cleaning before the move, the field map, a trial migration, reconciling counts and a parallel period.
Short answer
Preventing data loss in a CRM migration takes seven steps: an inventory of everything in the old system, a decision on what moves and what is archived, cleaning before the move, a field-by-field map, a small trial migration, reconciling counts after the move and a parallel period of two to four weeks. What gets lost most is not customer records but everything around them: notes, activity history, files, consents and source. The old system should not be switched off until the final check is done.
What gets lost, and why
- Activity history: calls and notes live in a separate table and are forgotten in the export.
- Files: proposals and contracts were attached to records; the export only takes text.
- First source: the new system records the import date as the "created date" and the original date is lost.
- Consent and opt-outs: they lived in a separate field that never made it onto the map.
- Relationships: a contact's link to a company, a lead's link to a manager.
All of these surface not after the migration but months later — when someone looks for an old customer's history.
Step 1: inventory
List what the old system holds: objects (contacts, companies, leads, deals, tasks, notes, files), the count of each, the fields in use and the relationships. Write the counts down — you will need them to check the result. Also ask who uses which data: some fields are filled in by only one manager, but they cannot work without it.
Step 2: what moves and what is archived
Moving everything is tempting, but it means carrying old clutter into the new system. A practical rule:
- Moved: active customers, open leads, closed deals from the last 2–3 years, consent records.
- Moved as a summary: old activities — one "history" note per customer.
- Archived: contacts untouched for years, test records, drafts from people who have left.
- Deleted: personal data with no legal basis to keep it — agreed with a lawyer.
Step 3: clean before moving
A migration is the best time to clean duplicates and unformatted numbers, because cleaning afterwards is harder. Normalise numbers, merge duplicates, map status and source lists onto the new system's lists. New systems handle duplicates differently on import: HubSpot, for example, updates a contact with the same email rather than creating a new one, and returns a row as an error when it finds several matching records. Merging duplicates is covered in CRM duplicate records.
Step 4: the field map
For every old field, write its place in the new system, its format and its transformation rule. Two fields need special attention in a migration: the original creation date (keep it in its own field, do not let the import date replace it) and the old system's record ID. The map format is shown in detail in the CRM integration data mapping checklist.
Step 5: a trial migration
- Pick 100–200 recordsOf different kinds: complete, partial, activity-heavy, with files, linked to a company.
- Move themTo a test environment or as flagged test records.
- Check with managersEach manager opens 10 of their own customers: is everything in place?
- Fix the mapEvery error found is written into the map and the trial is repeated.
Step 6: reconcile the counts
After the full migration, the counts from the inventory are compared with the counts in the new system: contacts, companies, open leads, activities, files. Any difference gets a written reason: "duplicates merged — 340", "archived — 1,200", "returned with an error — 17". No unexplained difference should remain. Rows returned with errors are kept in their own list and resolved by hand.
Step 7: the parallel period and cut-over
For two to four weeks, the old system stays open read-only while all new work happens in the new one. When managers cannot find something, they check the old system and report the gap. The cut-over date is announced in advance: after that day, nothing new is written to the old system. A rollback plan is written too — if a serious problem appears, under what condition and how the team returns to the old system.
An illustrative example
This is an illustrative example. A travel company is moving from its old CRM to a new one. The inventory shows 18,000 contacts, 4,200 deals and 60,000 notes. The team moves the last three years of deals, turns old notes into one summary per customer, and archives 6,000 contacts untouched for over two years.
The trial migration shows that "first enquiry date" is being replaced by the import date. A separate field is added to the map. After the full migration the counts are reconciled, 23 failed rows are fixed by hand, and the old system stays open read-only for three weeks.
Common mistakes
- Migrating without an inventory — at the end there are no numbers to check what was lost.
- Switching the old system off on migration day.
- Forgetting activity history and files.
- Replacing the first source and creation date with the import date.
- Not migrating consent records, or migrating them as "given".
Limitations
Some things do not migrate technically: the old system's internal reports, automation rules and sometimes the relationship structure have to be rebuilt. If the old system's export options are limited, a full migration may not be possible — check this in advance. Moving and deleting personal data must follow local law.
Migrating to Vexvon
An existing customer base is loaded into Vexvon by CSV — name, phone and email, together with a status and tag package; repeated numbers are checked during upload. Sales stages, tags and extra fields are set up in advance to fit the company's process, so old statuses can be mapped onto them. How to carry over old activity history and files we decide together, based on how your database is built. More on Vexvon CRM.
Next step
Before setting a migration date, fill in the inventory table: the count of each object and who uses it. That table makes both the scope decision and the later check possible. Protecting consent records in a migration is covered in CRM consent management. More articles are in the AI CRM section, and we can review your migration plan together during a demo.