The Spreadsheet Ceiling: Knowing When You Have Hit It
Spreadsheets are excellent software and most businesses run on them correctly. But there is a specific point where they start costing more than they save — here is how to recognise it.
Spreadsheets get unfairly maligned by people selling alternatives. They are extraordinary software — instantly available, universally understood, infinitely flexible, and requiring no engineer to change. A business running its operations on a well-built spreadsheet is not doing something wrong. It is usually doing something sensible.
But there is a point where the same properties that made a spreadsheet the right choice make it the wrong one, and the transition is gradual enough that it is easy to miss by a couple of years.
Six signals you have crossed it
One person is the system. There is someone who knows why column AF has that formula, which tabs must be updated in which order, and what to do when the import looks wrong. Everyone else follows a ritual. This is the clearest signal, because you no longer have a process — you have a dependency on a person, and it is not fair to them either.
Concurrent edits are a coordination problem. People message each other before opening the file. Or there are three versions with a date in the filename. Or the shared version has a “do not touch” note. Spreadsheets were designed for one author and they never fully escaped it.
The same data is typed in twice. Records get entered in the spreadsheet and then again in the CRM, the accounting system, or the ordering tool. Every duplicate entry is a chance for divergence, and divergence in operational data compounds quietly until a reconciliation reveals it.
Errors are discovered downstream. A wrong figure reaches an invoice, a report, or a customer before anyone notices. Spreadsheets have essentially no validation — any cell accepts anything — so the first check on data quality is often a person noticing something looks odd.
History is unrecoverable. Someone asks what a record looked like in March, or who changed a value and why. A spreadsheet’s answer is usually a shrug and a folder of monthly copies.
The file has become slow. Recalculation lag, crashes on open, formulas referencing other workbooks that reference other workbooks. This is the symptom people notice first and it is actually the least important — a slow file is annoying, but silent data corruption is expensive.
What usually should not change
The instinct once a team decides to replace a spreadsheet is to buy a large platform. Sometimes that is right. Often it trades a flexible tool your team understands for a rigid one that fits eighty percent of your process — and the other twenty percent becomes a new spreadsheet alongside it, which is where you started, now with a subscription.
Two things deserve preserving:
The flexibility to change without an engineer. Whatever replaces the spreadsheet needs configurable rules, or you have traded agility for structure and made your team slower.
The visibility of everything at once. People like spreadsheets partly because you can see the whole dataset and spot the outlier. Interfaces that only show one record at a time lose something real. Good replacements keep a table view.
The migration that works
Do not migrate everything. Most spreadsheets contain one genuinely critical dataset and a lot of accumulated scratch work. Identify the core, move that, and leave the rest where it is. Half of it will turn out to be unused.
Model the data before designing screens. What are the entities, how do they relate, what states can they be in, what transitions are legal? A spreadsheet flattens all of this into a grid; recovering it is the actual work, and it is where the value is. Interfaces are comparatively easy once the model is right.
Enforce validation from day one. The whole point is that bad data becomes impossible rather than merely discouraged. Required fields, typed values, referential integrity, legal state transitions.
Run both in parallel briefly. The spreadsheet keeps going while the new system is populated, and the outputs get compared. Nobody switches on faith. Two or three weeks of agreement builds more confidence than any amount of testing.
Keep an export. People need to know they can get their data back into a grid to do something unanticipated. Guaranteeing that removes most of the resistance to the move — and it is an honest guarantee, because it is their data.
When to leave it alone
Genuinely: if the spreadsheet is maintained by one person, is not a shared dependency, changes rarely, and nobody is re-keying its contents elsewhere, leave it alone. Not everything needs to be a system, and a focused tool built to replace something that was working fine is a cost with no return.
The trigger is the coordination overhead, not the file. When more than one person needs to depend on it, at the same time, with data that has to stay consistent with something else — that is the ceiling. Below it, the spreadsheet is not just acceptable. It is correct.
We build the systems that replace spreadsheets when it is genuinely time. See how, or read about which internal tools justify the build.