The CRM migration checklist we use
Decide what to leave behind, rebuild processes instead of lifting them, and settle the old system’s fate before go-live.
Moving a CRM is a decision about what to leave behind before it is a technical exercise. The list we run on every migration, in the order decisions get made.
Most CRM migrations are planned as a data exercise: export, map, import, check the counts. The counts match, the project is declared done, and six weeks later the sales team is keeping a spreadsheet again because the new system has every record and none of the habits.
The migrations that hold are planned the other way around. The data is the last thing decided, not the first. Here is the list we run, in the order the decisions actually have to be made.
Decide what the new system is for
Not “replace the old one”. A migration is the one moment when a company can ask what it wants the CRM to do, because for once nobody is defending how it works today. Write down the three things the new system has to make easier — the renewal that gets missed, the quote that takes a week, the report that is built by hand every Monday.
Everything below is measured against that list. If a field, a workflow or a report does not serve one of the three, it is a candidate for leaving behind.
Inventory what people actually do, not what the system has
The old system will have four hundred fields. Perhaps sixty carry data anyone has looked at in a year. Before mapping anything, sit with the people who use the system and watch a week of their work: which screens they open, which fields they fill, which they skip, and what they keep in a notebook because the system has nowhere for it.
This is where the migration earns its cost. The fields nobody fills are dropped. The notebook becomes a field. The report that three people rebuild every week becomes the report the system produces. None of this shows up in a data map.
Rebuild the process, do not lift it
A legacy workflow encodes a decision somebody made years ago against constraints that no longer exist. Lifting it into the new system preserves the constraint without the reason. Each workflow that moves gets asked one question: if we were designing this today, for the people who run it today, would it look like this? Usually the answer is “mostly, but the approval step is in the wrong place” — and the migration is when the approval step moves.
The migrations we have seen fail were faithful. The ones that held were unfaithful on purpose.
Map the data last, and map it from the new side
Only now does the field mapping happen, and it is written from the new system’s fields back to the old ones. Starting from the old side produces a map that carries everything; starting from the new side produces a map that carries what the new system needs. Every unmapped old field is listed with a decision beside it: archived, dropped or merged. “Not sure” is not a decision; it becomes a question for the process owner with a date.
Data cleaning happens here, in the old system, before the move — duplicates merged, dead accounts closed, the picklist with nine spellings of the same value collapsed to one. Cleaning after the move means cleaning in a system people are trying to learn.
Rehearse the cutover, twice
The first rehearsal is a full migration into a sandbox with the real data, run by the people who will run the real one, timed. It will surface the field that was mapped to the wrong type, the record that breaks the import, the integration that assumed an ID format. The second rehearsal is the first one again, after the fixes, and it is the one that tells you how long the real cutover will take. If the second rehearsal is not boring, there is a third.
Run the two systems together for one cycle
One business cycle — a month for most sales teams, a quarter for some — with the new system live and the old one read-only. Not both writable: a parallel run where people can still enter data in the old system is a run in which they will. Read-only keeps the old system as a reference for the question “what did we have for this account” while making the new one the only place work happens.
The step everyone skips
Decide, before go-live, what the old system’s fate is and when. Left running “just in case”, it becomes the place where the inconvenient records live, and a year later the company has two CRMs and a reconciliation problem. The decision is a date, a person and an archive format. It is the least technical item on this list and the one most often missing.
What this looks like from the client side
Fewer fields than before. Some workflows that look different from the old ones, on purpose, with the reason written down. A cutover that took about as long as the second rehearsal said it would. And a sales team that stopped keeping the spreadsheet, because the system now has the thing the spreadsheet was for.
That last one is the test. Record counts are not. This checklist is the shape of our migration and integration work; the assessment before it is where the “what is the new system for” question gets answered.
Want this applied to your business?
Thirty minutes with a principal turns the general case into your specific list: which workflows, what they’re worth, and in what order. The article can only tell you what we would look at; the call tells you what we found.