The hardest part of a warehouse migration is not technical. It is the fact that the business does not stop while you do it. Reports are still due. Regulators still expect submissions. The commercial team still wants a new segmentation by Thursday. Any migration plan that assumes a quiet period is planning for a company that does not exist.
This is why big-bang cutovers keep being proposed and keep going badly. They are attractive on a slide because they promise a clean end state and a single date. They are dangerous in practice because they concentrate all risk into one weekend, and because the fallback plan is almost always weaker than it looks.
Run both, prove equivalence, then switch
The approach we default to is parallel running with automated reconciliation. It is slower and less satisfying than a cutover, and it is materially safer.
The new platform is built alongside the old one. Both are loaded from the same sources. Both produce the same outputs. A reconciliation job compares them on a schedule and reports every divergence. Nothing is switched off until the divergences are either zero or individually explained and accepted.
The critical word is automated. Manual reconciliation, meaning an analyst comparing two spreadsheets, does not scale past a handful of reports and does not survive the fourth week when everyone is tired of doing it. If the comparison is not a job that runs on its own and shouts when it fails, parallel running degrades into hoping.
Divergences are the product
Teams treat reconciliation failures as bad news. They are the most valuable output of the entire exercise, and the reason is that a meaningful share of them are not migration defects at all.
On one engagement, a revenue figure differed by a fraction of a percent between old and new. The team spent two days assuming they had mis-implemented the transformation. They had not. The legacy job had been silently dropping a small set of records for years because of a join that excluded nulls in a currency field. The new implementation was correct. The old number, which had been reported externally, was not.
That discovery was worth considerably more than the migration itself, and it only surfaced because two independent implementations were forced to agree. Every migration we have run has turned up at least one of these. Budget for them, in time and in the awkward conversation they sometimes require.
Migrate by consumer, not by table
The instinct is to sequence work by the dependency graph, starting at raw ingestion and working up. It feels orderly. It delivers nothing usable for a long time, and it makes the programme politically fragile because there is no visible result to point at when someone asks for a status update in month four.
Sequencing by consumer works better. Pick a report or a team. Migrate everything that report depends on, all the way down. Prove equivalence. Move that consumer across. Then take the next one, which will find part of its dependency chain already done.
You do redundant work at the start and you get a genuinely migrated consumer within weeks. That first completed slice changes how the programme is perceived and how easy the next round of resourcing is.
Decide the fidelity question early
Every migration hits the same fork within the first month. The legacy platform has accumulated behaviours that are wrong but load-bearing. Rounding applied at an odd stage. A hardcoded exclusion from 2018 nobody can explain. A timezone assumption that is incorrect but consistently incorrect.
Reproduce them and you carry the debt forward, possibly forever, because a behaviour reimplemented deliberately is far harder to remove later than one that was merely inherited. Fix them and your reconciliation will never reach zero, and every divergence becomes a discussion.
Our position is to reproduce faithfully during parallel running, log every known deviation as an explicit exception with a ticket, and fix them in a scheduled wave after cutover. This keeps reconciliation clean, which keeps the safety mechanism trustworthy, and it prevents the migration from absorbing an unbounded remediation backlog. What it requires is discipline about the second wave actually happening.
Plan the decommission before you start
The most common way these programmes fail is not a bad cutover. It is never finishing. The new platform goes live, most consumers move, a handful of stragglers remain on the old system, and the organisation quietly runs two warehouses indefinitely at roughly double the cost and considerably more than double the confusion.
Three things prevent it. A dated decommission commitment made at the start, not negotiated at the end. A named owner for every remaining legacy consumer, so stragglers have a face rather than being a category. And a cost line for the legacy platform that appears in a report someone senior reads monthly, because a visible number creates pressure that a project plan does not.
Roughly what to expect
- Discovery and dependency mapping takes longer than estimated, every time, because undocumented consumers surface throughout rather than up front.
- The first consumer slice is disproportionately slow. It is building the reconciliation harness as much as it is migrating anything.
- Throughput improves sharply from the third slice onward as shared dependencies land.
- The tail is the risk. The last fifteen percent of consumers hold a disproportionate share of the difficulty and none of the momentum.
None of this makes a migration quick. It makes it survivable, reversible at every step, and honest about where it actually stands, which is what the business needs from it while it carries on trading.
Who should own it
A point that gets settled too casually. Migrations are frequently owned by the platform team, on the reasoning that it is platform work. It is not, or not only. The decisions that determine whether it succeeds are business decisions: which consumers move when, what fidelity deviations are acceptable, when the decommission date is defended against a request for an extension.
A platform team can execute those decisions. It cannot make them stick against a commercial objection, because it has no standing in that argument. The programmes that finish tend to have a business sponsor who reads the reconciliation summary, holds the decommission date, and takes the call when a team asks to stay on the legacy platform for one more quarter.
Without that, the technical work can be flawless and the migration still never ends.
