Migrating a warehouse without losing trust in the numbers
Moving the data is the easy half. The half that decides whether the migration is judged a success is proving the new numbers match the old ones, to people who are accountable for them.
Migrations are usually planned as an engineering problem and judged as a trust problem. The plan covers extraction, modelling, orchestration and cutover. The verdict, months later, comes down to whether the finance director believes the number on the new dashboard.
That gap is worth planning for explicitly, because the techniques that close it are not the same as the techniques that move the data.
Assume the old numbers are wrong too
The first uncomfortable discovery in most migrations is that the legacy system was not producing correct figures either. It was producing familiar ones. People had learned its quirks, applied mental corrections, and built a working relationship with a system they knew to be approximately right.
So a reconciliation that finds a discrepancy is not automatically a defect in the new build. Sometimes it is the new platform being correct for the first time. Handling that well matters enormously: if every difference is treated as a migration bug, the team will spend months faithfully reproducing errors.
Reconcile to explain the difference, not to eliminate it. An unexplained match is worth less than an explained gap.
Parallel running earns its cost
Running both platforms side by side for a period is expensive and almost always worth it. It converts an argument about trust into a set of observations. Each reporting cycle produces two answers, and each difference gets a written explanation: a known legacy defect, a definitional change agreed in advance, a timing difference, or a genuine bug to fix.
Keep that log. By cutover it is the single most persuasive document in the programme, because it demonstrates that every difference was noticed and accounted for rather than smoothed over.
Decide what you are not migrating
Every legacy warehouse contains reports nobody reads and tables nobody owns. Migrating them is the default because deleting them requires a decision and a named person to make it.
Take the decision early. Usage data tells you most of what you need, and a short round of conversations tells you the rest. Retiring a third of the estate before you start is the cheapest scope reduction available, and it will never be politically easier than at the beginning.
Cut over in pieces if you can
A single dated cutover concentrates all the risk into one weekend and gives the business one opportunity to lose confidence. Where the domains are separable, moving one at a time is slower on paper and considerably faster in practice, because each successful move buys credibility for the next.
Name who signs it off
Migrations drift when nobody is clear about who declares the new platform trustworthy. It should be the people who use the numbers to make decisions, not the team that built the pipelines. Agree at the start what evidence they will want, then produce exactly that evidence as you go.
Done that way, the final sign-off is a formality rather than an event. Which is what a good migration should feel like from the business side: not a launch, but a gradual realisation that everyone has quietly stopped opening the old system.
Written by the Semantic team. If it is relevant to something you are dealing with, tell us about it