Modernizing Data Warehouse: Why Fix, Migrate, and Rebuild Aren't the Same Project

Three Projects Wearing One Complaint 

Someone in leadership says "our data warehouse is old, queries are slow, let's modernize it," and the conversation jumps straight to picking a new vendor — Snowflake, BigQuery, Databricks, whatever the last conference pushed. Nobody asks why it's slow, or which part is the actual problem. Months and a large invoice later, the new platform is faster in theory. Half the reports still time out, because what was actually broken — bad table design, no maintenance, a job nobody's touched in years — got migrated along with everything else instead of getting fixed.

That single complaint is standing in for three different problems. A platform genuinely out of room needs a new platform. A platform that's fine but neglected needs maintenance, not a new address. A data model that no longer matches how the business operates needs to be redesigned, and no new platform fixes that — it just runs the same wrong answers faster. Confusing these isn't a technical miss. It's a budget spent solving the wrong one, with the real problem waiting on the other side of the invoice.

‍

A Platform Is Not a Blueprint

A renovation makes a house nicer to live in. It doesn't fix a floor plan that never worked — the awkward kitchen stays awkward, just with better fixtures. The blueprint is a separate decision from the contractor, and confusing the two means paying for the renovation and still living with the layout.

A data platform works the same way. The blueprint is the data model: what a table means, how it relates to the others, what level of detail the business actually needs to answer its own questions. The platform is what runs the blueprint. Move to a new platform without touching the model, and the company gets a faster version of whatever was already true about it — including the parts that were never right. Most "modernization" conversations skip this decision entirely: not which platform, but whether the blueprint underneath it still describes the business.

‍

Why the Wrong Path Wins Anyway

Diagnosis rarely happens first, because a platform evaluation is a project anyone can name, and "let's find out what's actually wrong with our model" isn't. Most warehouses carrying real pain were never profiled to find the handful of queries or reports actually driving the complaint — so the fix gets scoped against a guess instead of a cause. And even when the guess points the right way — someone suspects the model, not the platform — the harder path tends to lose anyway, because admitting a redesign is needed means admitting nobody currently owns the model, with no shortcut available. A platform move sounds like progress and sidesteps that admission completely.

The same avoidance shows up again even after a redesign is correctly chosen: the platform gets picked first, and the model gets treated as a detail to sort out during the build — backwards, since the model was supposed to be decided before the execution layer. And once anything is live, the original complaint rarely gets checked against what the project was funded to fix. "We modernized" becomes something that happened, not something that worked, and the same complaint resurfaces on infrastructure that costs more to run than what it replaced.

‍

‍

The Fix–Migrate–Rebuild Filter

This is what we run at Kynera before recommending anything, because these three paths aren't points on a spectrum of "more modern" — they're different categories of spend with different economics behind them.

‍

Fix

The answer when the platform's own published limits are nowhere close to being hit, tables have grown for years without maintenance, and the pain concentrates in a specific handful of reports rather than the whole system. Usually a fraction of a migration's cost, and often doesn't require taking anything offline. A quick way to tell: check whether the worst-performing query is scanning far more data than the question requires — a whole table instead of the recent slice a report needs. That's not a platform ceiling; it's a maintenance gap, and the cheapest problem on this list to close.

Migrate

The answer when the obvious maintenance has already happened and the business is still hitting a real ceiling — on concurrency, on storage economics, on a capability the platform genuinely lacks — while the underlying model remains sound. Same house, new foundation: what the data means isn't changing, only where it runs.

Rebuild

The answer when the model itself no longer reflects how the business operates — built for a reporting need from years ago, patched repeatedly for product lines or granularity nobody planned for, until every new report needs a special-case join on top of the last one. The most expensive path, the most avoided, and usually the point where a model has been quietly accumulating debt long enough that no platform swap was ever going to fix it. Worth getting right early for a second reason too: a model built to answer today's questions cleanly is the same one that can support automated processes and AI systems reliably later, while one held together by patches produces confident, wrong answers whether a person or an algorithm is asking.

‍

‍

What to Check Before the Budget Moves

‍

Which specific queries or reports are driving the complaint, and has anyone confirmed why they're slow — or is "the warehouse is old" doing all the explaining? Has the platform's actual ceiling been tested, or just assumed? If a migration went ahead tomorrow, would today's real complaints actually go away — and if the honest answer is probably not, that's a Rebuild wearing a Migrate as a disguise. For anything modernized in the last year: has anyone gone back to confirm the original complaint is gone, or just quieter for now?

‍

The Line Item That Never Shows Up

Nobody budgets for "the same problem, on newer infrastructure" — but it's what gets paid for whenever the path is chosen to avoid a conversation instead of to match the cause. The invoice says platform. What it's actually buying, half the time, is a postponement, and the real cost lands later as margin spent maintaining a warehouse that still can't answer the question it was modernized to answer. Knowing which of the three is actually needed is a five-minute check against the worst query in the business — considerably cheaper than finding out from the platform contract.