Almost every company between $2M and $100M has one. A workbook, usually with a version number in the filename, that runs something the business cannot operate without. Dispatch. Quoting. Commission. Inventory allocation. Capacity planning. It was the right tool when it was built and nobody chose for it to become load-bearing.
The instinct to replace it is often correct and the instinct about when is often wrong. Spreadsheets do not fail because they get large. They fail on concurrency, continuity, and traceability, and those failures arrive suddenly.
The seven signals
1. More than one person edits it
A single-author spreadsheet is a personal tool. The moment two people edit the same file, you have a system with no locking, no merge resolution, and no record of who changed what. The failure is not hypothetical: it is two people making reasonable edits to the same cell within an hour and one silently winning.
2. One person is the only one who fully understands it
Ask yourself what happens if that person leaves in a month. If the honest answer involves a scramble, you are not running a process, you are running a person. This is the single most common reason companies finally build the system, and it is usually triggered by a resignation rather than by planning.
3. Errors are being caught downstream
When mistakes surface at invoicing, or in a customer complaint, rather than at the point of entry, the process has no validation. Every downstream catch is more expensive than an upstream one, and the ones you do not catch are the real cost.
4. Reconciliation takes longer than the work
If someone spends Monday morning making the spreadsheet agree with the accounting system, the CRM, or the warehouse, the spreadsheet is no longer the source of truth. It is a second, competing truth with a manual synchronisation job attached.
5. Nobody can answer a question about last quarter
Spreadsheets overwrite. If you cannot reconstruct what the state was in March, you have no history, which means no trend analysis, no audit trail, and no way to investigate a dispute.
6. New hires take weeks to become useful
Long onboarding on a process usually means the rules live in someone's head rather than in the tool. Every undocumented rule is a training cost and a source of variance between how two people do the same job.
7. It is stopping you from doing something
The strongest signal is a business decision deferred because the process cannot support it. Not opening a second location, not taking a class of customer, not changing a pricing model, because the workbook could not handle it. That is no longer a tooling inconvenience. It is a constraint on strategy.
Quantify it before you propose anything
Nobody funds a replacement on the grounds that the spreadsheet is annoying. Three numbers make the case, and all three can be gathered in a week without a project.
- Hours. Have the people who touch the process log time against it for two weeks, including reconciliation, error chasing, and answering questions about it. Annualise. This is the number that funds the build.
- Error rate. Count how many downstream corrections were made last quarter and estimate the cost of each, including the ones that reached a customer. Small percentages on large volumes are usually startling.
- Key-person exposure. Write down, plainly, what happens operationally in the four weeks after the person who owns it gives notice. Put it in a memo. It will be the most persuasive paragraph in the proposal.
A process consuming 500 hours a year, generating quarterly corrections, and resting on one person is a straightforward case for a build in the low tens of thousands. A process consuming 60 hours a year with a clean error record is not, and the honest recommendation is to leave it alone.
Replace the riskiest step, not the workbook
The most common way these projects fail is ambition. Somebody scopes a system that replaces the entire workbook, it takes nine months, the business changes underneath it, and it launches as a worse version of what people were used to.
Do the opposite. Find the single step where errors are most expensive or the concurrency risk is highest, and build only that, with the spreadsheet still in place around it. A quoting workbook might become a small quoting application while pipeline tracking stays in the sheet for another year. That is not a compromise, it is correct sequencing: the risk leaves the business early, and you learn what the real requirements are before committing to the rest.
You are not replacing a spreadsheet. You are removing the two or three ways it can hurt you, in order of how badly.
How to cut over without stopping operations
- Run both in parallel for at least one full business cycle, with the spreadsheet still authoritative.
- Compare outputs at the end of each cycle and investigate every difference. Differences are usually undocumented rules, which is exactly what you needed to discover.
- Switch authority to the new system only after a full cycle with no unexplained differences.
- Keep the spreadsheet read-only for a quarter. It costs nothing and it removes the fear that makes people quietly keep using it.
- Migrate history if you can. A new system with no past is one people distrust.
The parallel period feels wasteful and is not. It is where you find the rules nobody wrote down, and it is what makes the cutover a non-event rather than an incident.
When the answer is to leave it alone
Not every spreadsheet should be replaced. A workbook with one owner, low volume, no downstream dependency, and a clean error record is a perfectly good tool and building software to replace it is a bad use of capital.
The distinction is not sophistication. It is exposure. A spreadsheet that would be a mild inconvenience to lose can stay. One that would take a week to reconstruct and would stop invoicing while you did is a business risk that happens to be stored in a file.