Warehouse migration budgets are wrong in a consistent direction, and the reason is not optimism about the technical work. Teams estimate the engineering reasonably well. What gets left out are the categories of cost that do not look like engineering, and those categories routinely account for more than half the total.
Here is the line-by-line we use when we help a client build the case, including the items that make the number less attractive.
Discovery, and why it is not free
Before anything is built, you need to know what exists and who depends on it. In an estate of any age, this is genuine investigation rather than a document review.
Query logs give you most of it. They will also give you a long tail of consumers nobody knew about: a scheduled extract feeding a spreadsheet that feeds a committee, a direct connection from an application built by a team that has since been reorganised, a service account whose owner left in 2021.
Budget four to eight weeks of a senior person’s time for a mid-sized estate. Organisations that skip this do not avoid the cost. They pay it in month nine, as unplanned interruptions, which is a considerably worse way to pay it.
The reconciliation harness
Parallel running requires infrastructure that produces no business value and cannot be skipped. Something has to compare outputs across two platforms, at row and aggregate level, on a schedule, with tolerances, and report differences in a form somebody can act on.
This is real software. It needs to handle floating point comparison, type differences between platforms, ordering, and the fact that the two systems will not finish loading at the same time. It gets thrown away at the end.
Estimate it as a small product in its own right. The teams that under-budget here end up reconciling manually, which is how parallel running quietly stops being a control.
Double running costs
For the duration of the transition you pay for both platforms. This is obvious and still frequently understated, because the assumption is that the legacy platform’s cost falls as consumers move off it.
It often does not. Legacy platforms are commonly on fixed capacity or committed contracts, so cost is flat until decommission regardless of utilisation. Meanwhile the new platform is carrying full load plus the reconciliation workload, which is not trivial.
Model the overlap at full cost on both sides for the whole transition, and check the legacy contract for exit terms before you commit to a date. We have seen a migration completed on schedule and still paying for the old platform for eleven months because of a renewal that nobody read.
Consumer-side change
This is the largest omitted category. Reports get rebuilt. Extracts get repointed. Scheduled jobs get updated. Someone re-tests every dashboard. Analysts learn different SQL dialect behaviour and hit the surprises personally.
Almost none of this work sits with the migration team. It sits with finance analysts, operations teams and whoever maintains the commercial reporting. That makes it invisible to the programme budget and highly visible to the people absorbing it.
Count the consumers. Estimate hours per consumer honestly, including re-testing rather than just repointing. Put the total in the business case as a real line even though it lands in other people’s cost centres. A programme that surprises three departments with unbudgeted work in month six loses their cooperation, and it needs their cooperation for the tail.
Remediation of what you find
Every migration surfaces defects in the legacy platform. Some are cosmetic. Some are figures that have been reported externally and are wrong.
The technical fix is usually small. The response around it is not: assessing the period affected, deciding whether restatement is required, informing whoever needs informing. That is legal, finance and compliance time, on a timeline you do not control.
You cannot size this in advance because you do not know what you will find. You can carry a contingency and, more usefully, you can agree the escalation path before the first discovery rather than during it.
The tail
The last consumers are the expensive ones. They are owned by teams with other priorities, they often have no clear owner at all, and by the time you reach them the programme’s political capital has been spent.
As a planning heuristic, assume the final fifteen percent of consumers consumes thirty to forty percent of elapsed time. Resource the tail explicitly rather than assuming the team that did the first eighty percent will simply continue at pace, because by then that team has usually been partially reassigned to something more interesting.
What we would put in front of a board
- Discovery and dependency mapping
- Platform build and transformation rewrite
- Reconciliation harness, built and operated
- Double running, at full cost on both platforms, checked against contract exit terms
- Consumer-side rework, counted and attributed even where it sits elsewhere
- Remediation contingency for defects surfaced
- Tail resourcing, named and separately funded
- Decommission, including archive and retention obligations
The resulting number is larger than the one most teams present, and it is defensible, which matters more. Programmes are rarely cancelled because they were expensive at the outset. They are cancelled because they became expensive in a way nobody predicted, and credibility does not usually survive the second overrun.
The benefit side is usually softer than claimed
Since we have been hard on the cost side, the same scrutiny belongs on the benefits, because business cases for migration lean heavily on two claims that deserve challenge.
The first is infrastructure saving. Modern platforms are frequently cheaper per unit of compute and frequently more expensive in total, because elastic pricing removes the constraint that was previously suppressing demand. When queries are no longer rationed by a fixed cluster, people run more of them. This is often a good thing and it is not a saving. Model the new platform on realistic post-migration usage, not on current usage priced at new rates.
The second is analyst productivity. The claim that analysts will save some percentage of their time is nearly always unsubstantiated, and even where the time is genuinely saved, it does not convert into headcount reduction or into measurable additional output unless something else changes too.
The benefits that hold up under examination tend to be capability benefits rather than efficiency ones. Things the organisation currently cannot do at all: a data volume the legacy platform cannot process, a latency it cannot meet, a workload it cannot run. Those are defensible, checkable, and considerably more persuasive than a productivity percentage that nobody will ever verify.
