When a spreadsheet becomes load-bearing

Every article about replacing Excel is written by somebody selling the replacement, which is why they all read the same: eleven reasons spreadsheets fail, then a signup button. They are not wrong, exactly. They are just answering a question nobody asked, because the question is never “is Excel a database”. It obviously is not, and the people running their operation on one already know that.

The real question is narrower and much harder: has this particular spreadsheet stopped being a spreadsheet? Most have not. Some have, and the ones that have are expensive to leave alone.

The moment it changes

A spreadsheet holds numbers. A system holds rules.

The transition happens quietly, usually through kindness. Someone adds a formula so a colleague does not have to remember a markup. Someone colours a row red when a date has passed. Someone adds a lookup tab so the same client name is spelled consistently. Each of these is a small, reasonable improvement, and each one moves a piece of business logic out of somebody’s head and into a file.

At some point the file knows things nobody has written down anywhere else. That is the moment. Not a row count, not a file size — the moment the sheet became the only place a rule lives.

Signs you can actually observe

Skip the generic list. These are the ones we have seen precede an actual failure, and each is something you can check this afternoon.

Two people cannot work in it at once, and the workaround has a name. Not “it is a bit awkward” — an actual established practice. -final-v2-JULY-USE-THIS.xlsx. A person whose job includes merging versions. A rule that Maria has it in the mornings.

Somebody re-types its numbers into another system. This is the strongest signal in the list, because it is measurable in hours and it is where errors enter. If the month-end figures reach accounting by hand, the sheet is not a document any more, it is an integration — one performed by a human, at typing accuracy, once a month.

You cannot reconstruct last Tuesday. Ask what the state was a week ago and see what happens. If the honest answer is “we would have to ask whoever changed it”, the sheet has no history, and anything that has no history cannot be audited, disputed or debugged.

One person understands the formulas. Not “wrote them” — understands them today. A twelve-tab workbook with cross-sheet references is software, and it is software with exactly one maintainer and no documentation. Its bus factor is one. Ask what happens when they take a holiday and listen for whether the answer is a joke.

Changes during the day exist only verbally. This is the one that shows up in operations rather than finance. The plan is in the sheet, the plan changed at 11am by phone, and the sheet still says what it said at 9. Everyone downstream is working from a document that is quietly wrong, and nobody knows which parts.

Nobody will touch a formula without a backup. When the file has become frightening, it is already load-bearing. Fear is a reasonable response to something that runs the business and cannot be tested.

Three or more of these together is a different situation from any one of them alone. One is friction. Three is a system nobody has agreed to maintain.

The signs that are not signs

Size. A 90,000-row export that one person filters twice a month is fine. It is a big file, not a system.

Age. A sheet that has worked unchanged for six years is evidence for leaving it alone, not against.

“It looks unprofessional.” Not a reason. Nobody outside the company sees it, and the cost of replacing working software with different working software is real money for zero operational change.

Somebody said the word AI. A spreadsheet is not blocking anything until you can name the thing it blocks, in a sentence, without using the word platform.

The honest case for leaving it

We turn this work down more often than we take it, and the reason is usually the same: the spreadsheet is doing a job it is genuinely good at.

Spreadsheets win at exploration. When the shape of the problem changes week to week — a new column, a different grouping, a one-off comparison a director asked for — a spreadsheet absorbs that in seconds and any custom system needs a change request. If your process is still finding its shape, freezing it into software is not progress. It is committing to a shape you have not finished discovering, and paying for the privilege.

Spreadsheets also win on staffing. Everybody can already use one. That is not a small advantage, and it disappears the moment the replacement needs training.

The cases where replacement actually pays are narrower than the marketing suggests: the process is stable, several people need it at the same time, the data is re-typed somewhere, and being wrong costs something you can name.

What actually breaks first

Not the file. The file usually survives fine.

What breaks is everything around it. Two versions of the truth for the same day. A number re-typed with a transposed digit that nobody catches until reconciliation. A decision made at 11am that never reached the person who needed it. A holiday during which the process pauses, because the process was a person.

We built dispatch software for a fleet of more than 200 vehicles where every one of those had happened. Routes were planned in spreadsheets, assignments went out by phone, the changes made during the day lived in the dispatcher’s head, and the month-end numbers were re-typed by hand into accounting. It worked — that is the part people miss. It worked completely, right up until the moment it needed to work while somebody was away, or needed to explain what had happened last Thursday.

Two constraints shaped the replacement more than any feature did, and neither of them appears in a feature list. Drivers are offline for half the day, so anything assuming a live connection would have failed exactly where the work happens. And the accounting system was not in scope and was not going to be replaced, so the new system had to agree with it rather than own the numbers — which made reconciliation part of the design rather than a report at the end. The full case study has the rest.

If three or more of those signs are yours

The first move is not a tool. It is writing down the rules currently living in the file: what turns a row red, what the lookup tab is for, which column nobody is allowed to sort. That document is useful whatever you decide next, and producing it is often the point where a team discovers that two people believed different rules were in force.

If you get through that and the answer is still “we need something else”, that is the kind of thing our custom software work is. And if the answer is that the sheet is fine, that is a good outcome — it cost you an afternoon and it saved you a project.