Nobody gets excited about data migration. It is also the thing most likely to make a CRM project late — and, unlike most reasons a project runs late, it is entirely predictable before anyone starts.
Why it is not a script
Moving records between two systems is easy. Deciding what the records mean is not, and that decision cannot be made by a developer.
A real example of the kind of question that appears on day two: there are three contacts with the same email at the same company, one created in 2019 with forty deals attached, one created last year by an integration, and one created last month by a salesperson who could not find the first two. Which is the client? What happens to the deals on the other two? Who decides?
Multiply that by every kind of duplication a decade produces. That is the migration, and every answer has to come from your side.
The four questions to settle before the build
What is the identity of a client? Email, tax number, name plus city? Whatever you choose is the rule that dedupes everything else, and getting it right is worth an afternoon of argument.
How far back do you actually need? Everyone says all of it. Then you ask what they have looked up from before 2020 in the last year, and the answer is usually "nothing, except a handful of contract terms". Old data can be imported cold — searchable, not in the way — for a fraction of the effort of importing it fully live.
What do you do with the fields nobody fills in? A boxed CRM accumulates them. Carrying them forward makes your new system look exactly like the old one on day one, which defeats the point.
Who is the one person who decides? Migration questions arrive daily for two weeks. If they queue behind a committee, so does the project.
What good looks like
- A dry run, early. The first import happens in week two against a copy, not in week nine against the real thing. It is how you find out that thirty percent of phone numbers are stored in four formats while there is still time.
- A reconciliation you can read. Counts in, counts out, and a list of everything that was skipped and why. If a migration cannot tell you what it dropped, it did not migrate — it copied.
- An agreed cut-off. The old system is read-only from a date, and everyone knows the date. Two live systems for "a short while" is how records end up in both and in neither.
What it costs
In our ten-week CRM build, migration is planned as part of the first version rather than as an extra — it is included because a CRM without your history is not a CRM, it is an empty form your team will refuse to use.
The range inside that depends almost entirely on the four questions above. Answer them before the first line of code and the migration is a fortnight of careful work. Leave them until the import fails and it becomes the reason the project is late.
If you are choosing between building and buying in the first place, the test for that takes an afternoon and is worth doing first.