Systems and records
CRM migration checklist: history that doesn't move by default
By SourceX Editorial · Updated
Short answer
A CRM migration checklist should name the history that standard imports drop: original activity dates, original owners, field and stage history, email threads, attachments and closed-lost reasons. Most migrations move current records well and history poorly. The rule: export the full old CRM before mapping starts, then decide item by item what moves and what goes to an archive.
Key takeaways
- Imports often stamp records with the import date unless original dates are mapped on purpose.
- Records owned by former staff can fail to load or be reassigned to whoever ran the import.
- Field and stage history usually needs its own export, because record exports show only current values.
- Closed-lost reasons and other picklist values break when the new CRM's lists do not match the old ones.
- Keep a full archive of the old CRM even when only part of it moves.
Why does history get lost in a CRM migration?#
History gets lost in a CRM migration because import tools are built to recreate current records, not their past. An account, its contacts and an open deal can move cleanly while the emails, stage moves and owner changes that explain them stay behind.
For a software company, that history is the record of how the business actually sells: which segments convert, where deals stall, which objections recur and why customers churned. It also settles commission disputes and renewal questions. Once the old CRM is canceled, none of it can be rebuilt.
The checklist: history that doesn't move by default#
Use the table as the agenda for scoping meetings with your migration partner or internal team. Each row should end with a decision, migrate, archive or drop, and the name of whoever approved it.
| Item | Why it gets lost | How to keep it |
|---|---|---|
| Original created and activity dates | Imports stamp records with the import date | Map originals to settable date fields or clearly labeled custom fields |
| Original owners | Some CRMs will not assign records to inactive users | Create inactive placeholder users or store the original owner in a field |
| Field and stage history | Record exports show only current values | Export history tables or reports and load them as related records or archive them |
| Email threads | Logged emails are activities with separate bodies, recipients and attachments | Export bodies and participants with links to contacts and deals |
| Attachments and files | Files sit outside the record export | Pull files by API with a map to parent record IDs |
| Closed-lost reasons | Picklist values differ between systems | Map every old value, including retired ones, before loading |
| Notes and call logs | Often a separate object or activity type | Export with timestamps, authors and record links |
| Associations | Many-to-many links flatten to a single parent | Export the link records and rebuild them |
| Deleted and archived records | Left out of normal exports | Check recycle bins and archives before cutover |
How do you keep original dates and owners?#
Original dates survive only if someone maps them deliberately. Some CRMs let an admin set system created dates during import with a special permission; others do not, so the original dates go into custom fields labeled as historical.
Owners need the same care. If the new CRM will not assign records to people who have left, create inactive users for them or keep the original owner in a separate field. Otherwise years of deals look as if the person who ran the import closed them, which distorts win rates by rep, territory history and any commission record.
Why do field history and stage history need their own export?#
Field history and stage history need their own export because they live in separate history tables or audit logs, not on the record itself. A deal export shows today's stage; the history shows every move, its date and who made it.
Check first whether history tracking was ever switched on, and for which fields. Some CRMs track only selected fields and keep history for a limited period, so export it before any plan change or cancellation. Load it into the new CRM as related records if people will use it day to day, or keep it in the archive keyed by deal ID if they will not.
Migrate or archive: a decision rule for each kind of history#
The decision rule is simple: migrate history that people will act on inside the new CRM, and archive history they will only look up. Moving everything inflates storage costs and clutters timelines, while dropping everything loses the context sales and success teams depend on.
Whatever you choose, the archive must stay searchable by account, contact and deal ID, so a rep can find an old thread without asking IT.
| History | Migrate when | Archive when |
|---|---|---|
| Activities and logged emails | The account or deal is still active | The account is closed or dormant |
| Stage history | Leaders report on sales cycle or conversion | Only occasional lookups are expected |
| Closed-lost reasons | Win and loss analysis continues in the new CRM | The old reason list is being retired |
| Attachments | Contracts and proposals are still in force | Files relate to closed or expired deals |
| Engagement tracking | Rarely, since formats seldom match | Almost always |
Cutover steps that protect history#
The order of cutover steps matters more than the tool you migrate with. Export before mapping, test before cutover and cancel only after the archive is checked.
- Take a full export of every object, history table, file and logged email from the old CRM before mapping begins.
- Build the field and picklist map, including retired values and custom fields.
- Create inactive users or original-owner fields for former staff.
- Run a test migration and compare counts, dates and owners against the old CRM.
- Trace a sample of won and lost deals end to end: activities, emails, files and stage history.
- Freeze changes in the old CRM, run the final migration and repeat the checks.
- Keep the old CRM read-only, or the full export archived, until users confirm nothing is missing.
- Cancel the old CRM only after the archive is verified and stored.
Illustrative: a dental software company changes CRM#
Illustrative: a fictional dental practice software company moves to a new CRM to match its new marketing platform. The migration partner's plan moves accounts, contacts, open deals and closed deals with their final stage.
The COO's review against the checklist finds four gaps. Closed-lost reasons use values that no longer exist in the new picklist, stage history is out of scope, logged emails would arrive without bodies, and deals owned by former reps would be reassigned to the admin running the import.
The team exports full history first, maps every lost reason, creates inactive users, loads stage history as a related object and archives email bodies and files with deal IDs. Sales leadership can still see why practices chose competitors in earlier years, and the archive is ready for any later review.
How SourceX looks at old CRM history#
SourceX reads CRM history as a record of decisions: how deals moved, why they were won or lost and what was said along the way. Activity histories that end in an outcome are the part of CRM data most likely to interest AI developers; a snapshot of current records says little about how decisions were made.
Scoping needs only metadata, such as which CRM, how many years and which history was tracked. If a package proceeds, the Preparation step of the SourceX five-step transaction strips contact details, customer names and other personal or confidential information, and permitted use and provenance are written into the SourceX Evidence Packet.
Frequently asked questions
Should we migrate all CRM history or only recent years?
Migrate what people will work with in the new CRM, often active accounts and recent deals with their history, and archive the rest in a searchable form. Ask sales, customer success and finance which questions they still answer from older records before you set the cutoff.
Can we run a CRM migration without a partner?
Yes, for simpler setups. The hard part is not the tooling but the mapping of dates, owners, picklists and associations. If you migrate in house, plan for test migrations and sample checks, and keep the full export of the old CRM whatever you decide to move.
What happens to email tracking and engagement data?
Open and click tracking, sequences and similar engagement data often live in vendor-specific objects that a new CRM cannot accept. Export what is available as reports or raw data, keep it in the archive linked to contact and deal IDs, and do not expect it to migrate.
Do privacy rules apply when moving contacts to a new CRM?
They can. Moving records between your own systems is generally part of running the business, but privacy laws and your own notices may still apply, especially to marketing preferences. Carry opt-outs and consent records across exactly, and confirm specific questions with counsel.
How do we prove nothing important was lost?
Keep the reconciliation: counts per object, date ranges, owner distributions and the sample of deals traced end to end, with any accepted gaps noted. Store it with the archive. If a dispute or audit questions old records, it shows what moved, what was archived and who signed off.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.