From spreadsheets to a single source of truth, without the big-bang rewrite

Every growing business hits the same wall eventually. The spreadsheets that got you this far can’t carry you any further, and there are now five versions of the same numbers floating around with no agreement on which one is right. The instinct at that point is to rip it all out and replace everything in one go. That instinct usually ends in tears.

Before anything else, give the spreadsheets their due. They got you here because they’re the most flexible business tool ever made: anyone can build one, change one, and email one. That’s exactly why they fail at scale. The same flexibility that let your ops manager whip up a job tracker in 2019 means there are now four descendants of that tracker, each customised by a different person, each slightly disagreeing with the others, and the only person who knows which formula is load-bearing resigned in March. The wall isn’t a spreadsheet problem so much as a growth symptom: the business outgrew tools that have no concept of one agreed answer.

What five versions of the truth actually costs

The cost hides because it’s paid in small, unglamorous increments. The Monday management meeting spends its first twenty minutes arguing about whose revenue number is right instead of deciding anything. A quote goes out based on a costs tab that hasn’t been updated since the supplier price rise, and the margin quietly evaporates. Someone makes a hiring call using a pipeline sheet that double-counts two deals. The finance person spends most of every month-end reconciling exports that should never have diverged, which is a week of skilled wages spent manufacturing agreement between systems that could just agree.

Then there’s the fragility you only price when it breaks: the crucial workbook with no version control, edit history that says “modified by whoever had it open”, and a habit of breaking silently when someone sorts a column without extending the selection. We’ve seen businesses discover a formula error that had been misstating a KPI for over a year. Nobody did anything wrong, exactly. The tool just has no way to tell anyone.

Why big-bang rewrites stall

A full replacement asks you to specify the whole thing up front, freeze the business while it gets built, and trust that the new system will be better before a single person has touched it. It’s slow, it’s expensive, and the risk all lands at the end. Worst of all you see no value until the day it ships, which is precisely the wrong way round.

The specification problem alone sinks most attempts. Nobody in the business can actually describe every workflow those spreadsheets encode, because half the logic lives in cells and half lives in habits. So the big rewrite gets specified against the official version of how the business works, gets built over nine or twelve months while the business keeps changing underneath it, and arrives late, over budget and describing last year’s operation. The team, who kept their spreadsheets going the whole time as insurance, look at the new system, find the three things it can’t do, and keep using the spreadsheets. Now you’ve got six versions of the truth and a write-off.

Consolidate one decision at a time

Pick one question your leaders actually ask. “How are we tracking this month?” will do. Then build the smallest slice of data plumbing that answers that one question reliably, wiring in only the sources it actually needs and ignoring the rest. Once people trust the number, you move on to the next question.

In practice that first slice usually means connecting two or three systems that already hold the data, the accounting package, the job or sales system, maybe a timesheet tool, into one place that cleans and combines them, with a simple view on top. Note what’s not in that scope: no one’s retyping history, no one’s migrating every spreadsheet, no one’s changing how the front-line team works on day one. The job is to make one number trustworthy end to end. For a typical small-to-mid business that first slice is weeks of work, not months, and it often lands as a dashboard people check each morning instead of a report someone assembles each month.

The trust part deserves emphasis, because it’s the actual product. A single source of truth isn’t a database; it’s a social agreement that this number is the number. You earn that agreement by letting people check the new figure against their old spreadsheet for a few weeks, chasing down every discrepancy, and being honest when the discrepancy turns out to be the new system’s fault. The first time the automated number catches an error the spreadsheet missed, the argument is over. From then on, each pass quietly retires a spreadsheet, hands you something usable straight away, and tells you what the next step should be.

Who does this work matters less than you’d think, and the shape of it matters more. The first slice doesn’t need a data team on payroll; it’s a well-bounded project for an outside builder precisely because the boundary is one question. What it does need from inside the business is a sponsor who’ll actually use the answer, and a decision about which system owns which field when sources disagree, the customer name in the CRM or the one in accounting, the job status in the ops tool or the spreadsheet. Those ownership calls are business decisions wearing technical clothes, and they’re the part no contractor can make for you.

Picking the next slice, and the one after

After the first trusted answer, the sequence tends to pick itself, because the first slice exposes where the data is dirtiest and which manual handoffs feed it. Common second moves: the sales pipeline (because the revenue view made everyone notice the pipeline sheet disagrees with it), job costing (because knowing revenue makes the missing cost side conspicuous), or wiring the operational tools into the accounting system so the reconciliation grind disappears rather than getting reported on.

Two rules keep the incremental approach from wandering. Each slice must retire something, a spreadsheet, a manual export, a re-keying step, so the estate shrinks as the system grows. And each slice must answer a question someone in charge actually asks, because plumbing built for hypothetical questions is how you end up with a data warehouse nobody opens. If a proposed step doesn’t retire anything or answer anything, skip it.

Somewhere around the third slice, the compounding starts to show. The plumbing built for the revenue question already holds the customer and job joins the pipeline question needs, so slice three costs less than slice one did and lands faster. That’s the quiet economic argument for incremental: a big-bang rewrite pays its integration costs all at once, up front, on faith, while the slice-by-slice version pays them gradually and reuses every join it’s already earned.

Expect a couple of spreadsheets to survive, and let them. A one-off analysis, a scratchpad someone uses to think: fine. The test for whether a spreadsheet has to go is whether decisions or money flow through it repeatedly. If yes, it’s infrastructure pretending to be a document, and it needs to graduate into the system. If it’s disposable, it’s doing exactly what spreadsheets are for, and it can live a long and blameless life.

After a few months of this you’ve got a single source of truth. Not because you bet the business on one giant rewrite, but because you replaced the spreadsheets one trusted answer at a time. The first slice is deliberately the cheapest thing on this whole path, which means the cost of finding out whether it works for your business is small and the answer arrives in weeks. If you’re staring at the wall now, five versions of the numbers and a month-end that eats a week, tell us which question you’d most like one reliable answer to, and we’ll scope the first slice that gets you there.