Data migration is a business project, not an IT chore

When a new system is on the way, data migration tends to get filed under technical detail. It sounds like plumbing: take the records from the old place, put them in the new place, done. So it gets pushed to the end of the plan and handed to whoever is most comfortable with a database. That framing is where a lot of otherwise sound projects start to wobble, because almost every genuinely hard question in a migration is a business question wearing technical clothes.

Consider what actually has to be decided. You have a customer recorded three different ways across three systems. Which version is the real one. You have ten years of history, some of it accurate, some of it the residue of processes that changed long ago. How much of it comes across, and how much do you leave behind on purpose. You have fields that one team treats as essential and another ignores entirely. Whose definition wins. None of these can be answered by looking at the data alone. They need someone who understands the business and is allowed to make a call.

This is the part people underestimate. A migration is not really moving data. It is deciding what your data should have been all along, and then making it so on the way through. Done well, it is a rare chance to clear out the duplicates, retire the dead categories and agree on the definitions that should have been settled years ago. Done as a pure technical lift, it faithfully carries every old mess into the shiny new system, where it is now harder to fix because everything depends on it.

The symptom of getting this wrong is familiar. The new system goes live, and within weeks people are saying it is worse than the old one. Usually the software is fine. What happened is that bad data came across unexamined, and now nobody trusts the reports, the searches return nonsense, and the team drifts back to their private spreadsheets. The system did not fail. The migration did, because it was treated as a chore rather than a decision.

So we treat it as a business project with technical execution, not the other way round. Someone from the business owns the rules. We work through what is duplicated, what is stale, what is the source of truth, and what each field is genuinely for. The cleaning happens before the move, in daylight, with the people who know the answers, rather than being discovered as a surprise afterwards.

There is a quieter payoff too. Data that has been deliberately cleaned and given a clear structure is exactly the data you want underneath anything you build later, including anything that uses AI to surface patterns. A model is only as trustworthy as what it reads, and a migration done properly is one of the best opportunities you will get to make that foundation sound. Spend the effort here. It is not the boring bit. It is the bit that decides whether the new system is loved or quietly abandoned.