The pitch to migrate your data warehouse is constant. There is always a vendor with a benchmark and a case study. Most migrations are not worth the cost. A small number are. Here is how I tell the difference, having watched a few of these go well and several go badly.
The default position is to stay
A data warehouse migration is one of the most disruptive things a data team can take on. It absorbs senior engineering attention for two to four quarters. It produces no new business value during the migration. It introduces risk to every downstream consumer. The cost is high and concentrated in time.
The benefits are usually some combination of cost savings, performance improvements, and capability expansion. These have to be material to justify the cost. Most of the time, they are not. The default answer to "should we migrate" is "no".
The cases where you should migrate
A few specific situations where the math actually changes.
Your current warehouse cannot handle the volume. The signs are concrete. Loads are taking longer than the SLA. Queries that worked last year are now timing out. Adding compute is producing diminishing returns. You have run the optimisation play and exhausted it. This is a capacity problem, not a preference problem. Migration is on the table.
Your current warehouse is end-of-life or end-of-support. Some vendors deprecate products on a slower schedule than their marketing suggests. If the support contract is expiring, the answer is forced.
Your governance posture has changed and the current warehouse cannot meet it. The most common version is a regulatory requirement that mandates encryption, residency, or auditing that the current platform does not support. This is a compliance problem, not a preference problem. Migration is on the table.
The cost trajectory has diverged from the business trajectory. The warehouse cost is growing faster than the business that depends on it, and the optimisation play has been run. This is an unusual case in 2026, because most of the major warehouses have priced competitively, but it does happen.
A meaningful capability is on a competitor platform that you need and cannot replicate. This is rare. Most platforms have converged on capability. When it does happen, the capability is usually around a specific data type, a specific governance feature, or a specific compute paradigm.
The cases where you should not migrate
The cases that look compelling and usually are not.
The vendor benchmark suggests a cost saving. The benchmark was run on a workload that does not look like yours. The real-world saving will be smaller. Often it will be smaller than the migration cost.
A senior engineer prefers the new platform. This is a real factor for retention, but it is a weak basis for a strategic decision. The right response is to invest in the engineer's growth on the current platform.
The new platform has a feature that solves a current pain point. The right comparison is the cost of the feature against the cost of the migration. The feature is rarely worth the migration cost on its own.
The old platform feels old. This is a feeling, not a business case. Old platforms that do their job well are strategic assets, not liabilities.
What to do before you migrate
Before committing to a migration, run an optimisation play on the current platform. Most of the warehouses I have seen recommended for migration were not running well on the current platform. Bad clustering. Inefficient transformations. Queries that should have been pre-aggregated. Workloads that should have been moved to a different compute service.
A serious optimisation effort, run for a quarter, often recovers thirty to fifty per cent of cost on a well-run warehouse. On a poorly run warehouse, it can recover more. That savings is achieved without migration risk. If the optimisation play closes the gap with the migration target, the migration is no longer required.
What a clean migration looks like
The migrations that go well share a few properties.
A frozen scope. The target environment is a one-for-one replication of the source environment, minus deprecated artefacts. New features are not in scope during the migration. They are in scope after.
A parallel run. The new warehouse runs alongside the old for a defined period. Outputs are compared. Discrepancies are investigated. The old warehouse is not turned off until the new one has been verified on real workloads.
A clear cutover criterion. There is a stated condition under which the old platform gets turned off. It is not "when we feel ready". It is a measurable condition, agreed with stakeholders.
An honest accounting of the cost. The migration cost includes engineering labour, vendor cost during the parallel run, and the opportunity cost of work that was not done. A migration that pencils out at engineering cost alone is under-scoped.
The decision framework
The framework I use with clients. First, run the optimisation play on the current platform for a quarter. Second, after optimisation, recompute the cost trajectory and the capability gap. Third, if the gap still warrants migration, scope the migration honestly with all costs included. Fourth, if the migration still pencils out, commit.
This sequence kills a meaningful fraction of migration proposals at the optimisation step. The remaining migrations that survive it are usually genuine. They are the ones that go well.