The phrase "we should just rebuild it" has a seductive cleanliness to it. When a data warehouse has gone bad — numbers that don't reconcile, refreshes that fail more nights than they succeed, a model nobody dares change because nobody fully understands it anymore — the fantasy of a fresh start is almost physical. Wipe it. Do it right this time. And I understand the pull completely, which is why I want to argue against it, because in a decade around data warehouses I have watched far more organisations hurt themselves with a rebuild than with a repair. The broken warehouse you have is nearly always cheaper to fix than to replace — if you fix it in the right order.
Why the rebuild is a trap
Start with the honest case for rebuilding, because it isn't zero. Sometimes the underlying model is so wrong — the grain of the fact tables mismatched to the questions, the whole thing modelled around a business that no longer exists — that repair is genuinely lipstick on a corpse. That happens. But it's rare, and it is diagnosed, not assumed.
The trap is that a rebuild feels like progress while delivering none for a very long time. Here's the shape of the pain:
- You freeze the value while you rebuild. For the six or twelve months of the rebuild, the business still needs its reports — so you're now maintaining the broken warehouse and building the new one, double the work, none of the benefit landing until the very end.
- You rediscover every undocumented rule the hard way. That "messy" old warehouse encodes years of hard-won business logic — the odd exception, the special-case customer, the reason that one number is calculated that strange way. A clean rebuild throws all of it out and then rediscovers it, painfully, one angry stakeholder at a time.
- Big-bang cutovers are where projects go to die. The day you flip everyone from old to new is the day all the accumulated risk arrives at once. I've seen those days. I don't recommend them.
The order of operations for a repair
So when I'm handed a broken warehouse, I don't ask "what would I build instead?" I ask "what's actually broken, and in what order do I stop the bleeding?" The sequence matters more than any individual fix.
- Stabilise before you improve. The first job is not to make it good, it's to make it stop failing. Find why the refreshes break — usually a handful of fragile steps, a source that changed shape, a job with no error handling — and make the thing run reliably to completion every night, even if it's still ugly. A warehouse that runs badly but runs buys you the calm to fix everything else. A warehouse that fails nightly keeps you firefighting forever.
- Establish what "correct" even means. Before fixing the numbers, you need a reconciliation point — an agreed source of truth for a few key figures (yesterday's sales, the customer count) that you can check the warehouse against. Astonishingly often, "the warehouse is wrong" turns out to mean "the warehouse and this spreadsheet disagree and nobody's sure which is right." Pin down truth first, or you'll fix the numbers to match the wrong reference.
- Fix the model surgically, at the grain that's wrong. Now — and only now — go after the structural problems, but locally. If one fact table is at the wrong grain, fix that table and the reports on it. You do not need to re-lay the foundations of the whole house to fix one cracked room. Most "the model is broken" complaints trace to two or three specific tables, not the whole schema.
- Strangle, don't cut over. Where something genuinely must be replaced, build the new piece alongside the old, move one report or one subject area onto it, prove it, then move the next. The old warehouse shrinks as the new pieces take its load — a gradual strangling rather than a big-bang switch. Every step is small, reversible, and delivers value the day it lands.
A worked example
At a retailer whose warehouse had earned the whole catalogue of symptoms — nightly failures, numbers finance didn't trust, a model people were afraid to touch — the internal conversation had already drifted toward a rebuild, with a budget line starting to form around it. We did the four steps instead.
Stabilising the refresh — mostly adding error handling and fixing two brittle source steps — stopped the nightly failures inside a fortnight, which alone changed the emotional temperature of the whole project from panic to patience. Then we built a small reconciliation report that checked the warehouse's key totals against the operational systems each morning, which surfaced that the "wrong numbers" were, in fact, two specific measures with a genuine bug and a dozen other measures that were correct all along and merely distrusted. Fixing the two, and demonstrating the twelve, recovered most of the trust without touching the model at all. The actual structural surgery, when we got to it, was confined to two fact tables. There was no rebuild, no big-bang cutover, and no frozen half-year — just a warehouse that went from feared to boring over about three months, which in warehouse terms is a triumph.
A data warehouse is rarely as broken as the people relying on it feel it is. Half of "the numbers are wrong" is two real bugs; the other half is trust that was never rebuilt after the first time the numbers were wrong. You fix warehouses with error handling and reconciliation reports, not clean slates.
The counter-view, held honestly
I promised this wouldn't be a sermon, so: yes, sometimes you rebuild. If your reconciliation step reveals the model is at fundamentally the wrong grain for the questions the business now asks — if you're not fixing rooms but discovering the house was built for a different family — then a designed replacement, still delivered by strangling rather than big-bang, is the right call. The point isn't "never rebuild." It's "never rebuild by default, out of the emotional appeal of a clean slate, before you've diagnosed whether repair would do." The diagnosis is cheap. The rebuild is not.
Most broken warehouses are not architecturally doomed. They're under-maintained — fragile where they should be robust, undocumented where they should be legible, distrusted where a week of reconciliation would restore confidence. That's a repair job, and the repair job is faster, cheaper, and far less risky than the rebuild that feels so clean in the meeting. Stop the bleeding, pin down truth, fix what's genuinely broken where it's broken, and strangle the rest slowly. The warehouse you have is usually the warehouse worth saving.