When a spreadsheet quietly becomes a production system
The warning signs, and an intervention that is not a six-month rewrite.
Every company runs on at least one spreadsheet that should not be one. It got there honestly: somebody needed an answer, built it in an afternoon, and it worked. The problem is not the spreadsheet. It is that nobody noticed when it became infrastructure.
The warning signs
Someone other than the author depends on it weekly. It has a scheduled refresh a human performs. It contains a formula nobody fully understands and nobody will touch. There is a copy called final v3 which is actually the live one. Any two of those and you have a production system with none of the properties of one.
What is actually at risk
Not the calculation. Spreadsheets calculate fine. What is missing is version history that means anything, access control below the file level, validation on input, and any test that would catch a broken formula before a decision is made on its output. Those absences stay invisible right up until they are extremely visible.
The cheap intervention
Do not rewrite it. Most spreadsheet replacement projects fail because they try to reproduce a decade of accumulated logic that was never written down anywhere.
Instead: put the inputs somewhere versioned, add a validation step that fails loudly on impossible values, and write down what the output is used for. Three days of work removes most of the real risk.
When to actually rebuild
When the sheet is the interface to a decision affecting money or customers, and more than one person needs to change it at once. Concurrency is the thing spreadsheets genuinely cannot do, and it is usually what forces the issue.
The goal is not to eliminate spreadsheets. It is to know which ones are load bearing, and to give those few the properties that stop them failing quietly.