CRM Migration
CRM migration: moving the records is the easy part.
Migrations between Salesforce, HubSpot and Odoo, and off spreadsheets, legacy CRMs and ERP-embedded customer lists. Field mapping, cleaned data, rehearsed cutover, and a rollback plan agreed before the window opens rather than debated during it.
Rehearsed into staging first. Reconciled and signed off before cutover. The old system stays read-only until you say otherwise.
What breaks
Six things that survive every migration plan, and ruin half of them
The records usually arrive. What goes missing is everything that made the records useful: who they belonged to, what happened to them, and which report depended on them.
Field mapping that assumes one to one
Two source fields become one target field, or one becomes three. Without an explicit rule, the import picks whichever it reads last and the choice is never recorded.
Associations, not records
Contacts arrive. Which contact belongs to which deal, which activity to which record, which historical owner had which account, does not. The records are right and the graph is empty.
Ownership and history
Everything lands on the importing admin account. Territory, rep attribution and commission history vanish, and the first forecast after go-live is attributed to one person.
Attachments and notes
Files live in a different store with different permissions. Proposals, signed contracts and call notes are the records people actually search for, and they are the first thing dropped when the deadline moves.
Automations rebuilt from memory
The old system had approvals, routing and reminders nobody documented. On the new platform they are either forgotten or reinvented differently, and the process changes without anyone deciding it should.
Report definitions
Two reports with the same name counted different things. After migration one of them silently changes meaning, and the number in the board pack moves for reasons nobody can explain.
The part that decides the project
Moving records is a script. Preserving relationships is the work.
Moving rows between two systems is well understood, and it is rarely where the effort goes. What separates a migration from a data dump is whether the graph around each record survives it.
The easy half
Records
Accounts, contacts, deals, cases, products. Every platform will accept these in bulk, and the mechanics are well understood.
- Field-level mapping, one source field to one target field
- Value translation for picklists and stages
- Date, currency and unit normalisation
- Deduplication on entry, by a rule you approve
- Import in batches with a reject file for anything refused
The half that decides it
Associations
Which record belongs to which, who owned it, and in what order things happened. This is where a migration either preserves your history or quietly resets it.
- Contact to account, with the primary contact preserved
- Activity and email history to the right deal, not just the right contact
- Historical record ownership, preserved per record
- Parent-child structures across accounts and opportunities
- Attachments re-linked to the record they were attached to
- Ordering: what happened before what, kept intact
How it runs
Cutover is a repeat of a run that already succeeded
The migration is performed in full, into staging, before it is performed in production. Go-live is then a repetition of a known-good run rather than the first attempt at one.
Assess
Inventory the source: objects, record counts, custom fields, automations, attachments, integrations and the reports people actually use. This is a migration plan or it is guessing.
Map and clean
Field mapping written down, value translations agreed, duplicates merged by a rule you approve. Cleaning happens before import, not as a follow-up project nobody funds.
Rehearse
Full run into a staging copy of the target. Timed, logged, with a reject file for every record refused and the reason attached.
Reconcile and sign off
Counts compared object by object, associations spot-checked, reports re-run against both systems and the differences explained. You sign off on evidence, not on reassurance.
Cut over
The same run, repeated in production inside an agreed window. Source stays read-only rather than switched off, and hypercare starts the morning users arrive.
Nothing is imported into production that has not already been imported into staging. That single rule removes most of the reasons migrations go badly, and it costs one extra run.
Scope decisions
Three choices to make before the price means anything
A migration quote without these three answers is a number with nothing behind it. We ask for them in daylight so they can be priced rather than absorbed.
| Decision | What it changes | Typical answer |
|---|---|---|
| History depth | How far back activities and closed deals are carried over. Drives volume, run time and reconciliation effort. | Three to five years of closed deals, all open records |
| Attachments | Whether files move, and whether permissions travel with them. Often the largest data volume and the least planned. | All files on open records, recent files on closed |
| Associations | Whether relationships and historical ownership are reconstructed, or records land flat with a single owner. | Reconstructed, including historical owner |
What we will not promise about a migration
- That nothing will change for users
- That every historical field has a home
- That source data is clean enough to import untouched
- That automation will behave identically on the new platform
Every one of these is a decision, not an accident. Where a field has no home, you will see it on a list and choose: carry it as text, drop it, or keep the source read-only for reference. What you will not get is a version of events where it silently disappeared.
When it goes wrong
The rollback plan is written before the window opens
Cutover happens under time pressure, which is the worst possible moment to invent a decision. So the triggers are agreed, written down and signed while everyone is still calm.
Reconciliation does not close
If record counts or association checks miss the threshold you set in advance, the run stops and the window closes without a decision being argued. The threshold is a number you choose, not a judgement made at 2am.
Critical automation fails twice
If the automations that gate the business — approvals, routing, invoicing triggers — fail after two repair attempts, that is a rollback rather than a third attempt under pressure.
The source stays read-only, not off
The old system is not decommissioned at cutover. It goes read-only for an agreed period, so a reversal is a permissions change rather than a data recovery exercise.
A rehearsal already proved it
The production run repeats a staging run that reconciled and was signed off. A rollback is therefore unusual, and if it happens it is because something differed between the two environments, which is itself a finding.
What actually frightens a mid-market buyer is not the migration failing. It is finding out on Monday morning that nobody had a plan for it. Everything on this page exists to make that specific fear unnecessary.
Proof
Client results
Three engagements where the data had to arrive intact for the project to mean anything.
Donation and volunteer management for a national Red Cross society
Only around 60% of recurring donations were being processed. Bank integration and a reconciled donation record restored the flow without replacing the platform or losing donor history.
Read case studyClient onboarding transformation for a licensed EMI
Regulated KYC onboarding moved out of email and spreadsheets. Client and document history had to be preserved exactly, because the regulator would ask for it.
Read case studyCustomer service and sales management at parcel-delivery scale
Enquiry history from several channels consolidated into one service record, so a customer's previous contacts stayed attached when volumes doubled.
Read case studyName the source system and we will tell you what usually survives it
What needs a decision, and which part is likely to be the difficult one.
FAQ
CRM migration, answered
Which migrations do you handle?
Can you migrate without disrupting the business?
Will we lose history?
Do attachments and files migrate?
How long does a CRM migration take?
What happens to our old system?
Can you migrate and implement at the same time?
Before the window opens
Tell us what you are moving from, and how much of it matters
Name the source system and we will tell you what usually survives it, what usually needs a decision, and which part is likely to be the difficult one. That is the conversation that makes a migration quote mean something.