Every growing company has one. It started as somebody’s working file, and at some point — without any decision being made — the business began to depend on it. Nobody chose this. It just happened, the way a footpath appears across a lawn.
The question is not whether this is embarrassing. It is not. A spreadsheet that runs a real business is a spreadsheet that solved a real problem faster than any procurement process would have. The question is whether it has crossed the line from useful to load-bearing, because those two need very different responses.
Four tests
Complexity is the wrong measure. So is size. Some enormous, hideous spreadsheets are perfectly safe, and some tidy little ones are a serious operational risk. What matters is dependency. Run these four:
Concurrency. Does more than one person need to edit it at the same time? The moment two people need write access simultaneously, you have a system that requires coordination to use, and coordination is a cost you pay every day forever.
Auditability. Can you tell who changed a number, when, and what it was before? For anything touching money, headcount, inventory, or compliance, “no” is not an acceptable answer — and version history in a cloud file is not the same thing as an audit trail, because it records the file, not the decision.
Blast radius. If a formula silently breaks, what does it cost before anybody notices? Not the worst case — the likely case. A pricing sheet with a broken lookup can quietly under-quote for a month.
Bus factor. How many people can repair it? If the answer is one, the spreadsheet is not an asset. It is an unfunded liability with a person attached to it.
Two or more yeses and you are load-bearing.
The mistake people make next
Here is where it usually goes wrong. Somebody decides the spreadsheet has to go, and the project becomes replace the spreadsheet — rebuild what it does, faithfully, in software.
This fails, reliably, and the reason is worth understanding. A mature spreadsheet is maybe two-thirds actual business logic and one-third workarounds for the fact that it is a spreadsheet. The colour-coding that means a row is provisional. The hidden tab that exists because you cannot have two views of one table. The manual re-sort every Monday. The column that is blank for the first eleven rows because someone needed a header that Excel would not give them.
Rebuild all of that faithfully and you have paid to encode a set of workarounds into a system that did not need them, and the result is worse than the spreadsheet — because at least the spreadsheet was fast to change.
The job is to separate the two. What is this actually for? Which of these behaviours are the business, and which are the tool showing through?
That work is unglamorous and it is most of the value. It is also why the person who owns the spreadsheet has to be in the room. They are the only one who knows which is which, and they usually know instantly when asked.
Build narrow
The second failure is scope. Having decided to replace one spreadsheet, it is tempting to solve the whole category — an operations platform, a single source of truth, a system that will absorb the other spreadsheets too.
Resist it. The spreadsheet earned its place by being narrow and immediate. Whatever replaces it should be narrow and immediate too: one workflow, done properly, in production quickly. You can always extend a small tool that people use. You cannot rescue a large one they have quietly gone back to Excel to avoid.
A good replacement usually covers a single workflow, enforces the rules that were previously conventions, keeps a real audit trail, and lets several people work at once without asking each other first. That is a smaller build than most people expect, and it removes most of the risk.
Sometimes the answer is: leave it alone
Not every spreadsheet needs replacing, and there is a real cost to replacing one that did not.
If it fails the four tests but only just — one editor, low blast radius, two people who understand it — the right move may be to make it safer rather than to rebuild it. Lock the formula cells. Move it somewhere with real version history. Write down what it does, on one page, so the bus factor goes from one to two.
That costs an afternoon. Rebuilding costs considerably more, and the second-worst outcome in this whole area is spending a quarter replacing a spreadsheet that was fine.
The worst outcome is the one where nobody looks until the file breaks.
