Nearly every operations problem we get called into starts as a spreadsheet that worked. It was the fastest way to track something, it did the job, and then the business grew around it. Nobody decided it should become the system of record. It just became one.
So the question is not whether spreadsheets are bad. They are hard to beat for quick analysis, for calculations, and for a process that is still changing shape. The question is whether one particular file has quietly taken on a job it was never built for, and what it costs you to leave it there.
Six signs the spreadsheet has outgrown itself
None of these is a reason to rebuild on its own. When several start happening at once, the file has stopped being a spreadsheet and become infrastructure.
- Two people edit it at the same time and someone's work disappears. You have lost a row and rebuilt it from memory.
- There is a copy called final, or v3, or someone's name, and nobody is certain which one is current.
- A formula in column K decides something that matters, one person wrote it, and nobody else will touch it.
- Filters and hidden columns are being used as permissions, because some people should not see everything and the file cannot enforce that.
- Someone retypes data out of it every week, into a CRM, an invoice, or another sheet.
- Onboarding a colleague means an hour of explaining the file, and they still get it wrong for a month.
Put a number on the delay
Before deciding anything, measure. Take one recurring manual step, time it honestly, and multiply: minutes per occurrence, times occurrences per week, times the number of people doing it.
As an illustration, a twenty-minute daily re-entry done by three people is five hours a week, around two hundred and fifty hours a year. Whether that justifies a replacement depends on what those hours cost and what those people would otherwise be doing. Either way you now have a number instead of a feeling.
Then add the two things the arithmetic misses: what the errors cost when they reach a client, and the risk that the one person who understands the file leaves.
When the spreadsheet is still the right answer
Plenty of sheets should stay sheets. Keep it if the process changes shape every few weeks, because software is slower to change than a column. Keep it if one person uses it, if it is a model rather than a record, or if you are still working out what the process even is.
A spreadsheet is also the cheapest way to prototype a process you are unsure about. Rebuilding too early locks in a workflow before anyone knows it is the right one, and that is more expensive than waiting.
What replacing it actually involves
- Map the process as it runs today, including the exceptions people handle by hand. The exceptions are where the real requirements hide.
- Model the data: what a record is, which states it moves through, and which fields are genuinely used rather than merely present.
- Decide permissions properly, so the filter-and-hide workaround disappears.
- Import the history. If the new application starts empty while years of useful data sit in the spreadsheet, people keep the old file open beside it, and you have added a second system rather than replaced the first.
- Run both in parallel for a short, fixed period, then retire the sheet on a date rather than on a feeling.
- Keep an export. Replacing a spreadsheet should not mean trading one dependency for a worse one, so the data has to come back out in a usable format.
What drives the cost
The price of this kind of build tracks four things: how many record types you have, how many systems it must exchange data with, how many people use it under different permissions, and whether years of history have to come along.
A single-record tool for one team is a different project from a system that syncs with your accounting software and keeps an audit trail for a regulator. Until those four are known, an estimate rests on assumptions rather than on the actual scope.
If several of the signs above sound familiar, the useful next step is not a quote. It is measuring the manual step that costs the most, then deciding whether removing it pays for itself. That is the audit we usually start with, and it is worth doing whether or not you end up building anything.