BUILD
Replacing the spreadsheet: internal tools that get used
5 min read
Internal tools replace spreadsheets successfully when they preserve the ability to handle exceptions, because the main reason a critical spreadsheet survives is that it never refuses to record something unusual.
Somewhere in most organisations there is a spreadsheet doing a job nobody would design a spreadsheet to do. It tracks orders, or shifts, or stock, or candidates. One person maintains it. It has colour-coded rows whose meaning is undocumented, and when that person is on leave, something stops.
Everyone agrees it should be replaced. Replacement projects fail at a high rate, and the reason is consistent enough to be worth understanding before starting one.
Why the spreadsheet is winning
A spreadsheet has no opinions. If a customer orders something that is not in the catalogue, you type it in the cell. If a shift is covered by two people for half a day, you write that. If the process changes on Tuesday, you change the sheet on Tuesday.
Purpose-built software usually removes all three abilities. It validates, it enforces, and it requires a developer to change. Every one of those is a feature, and together they are why a rigid replacement gets used for the easy ninety percent while the exceptions move to a second spreadsheet nobody admits to.
Keep the escape hatches
An internal tool that survives contact with a real process has somewhere for the unusual case to go. Not unvalidated chaos, but a deliberate path: a free-text note attached to a record, an exception flag that routes to someone for review, an override with an audit trail.
The practical rule is that it should always be possible to record what actually happened, even when what happened was irregular. A system that refuses to record reality gets a spreadsheet alongside it within a month.
- A way to record the exception rather than being blocked by it
- Notes on records, because the colour-coded column in the spreadsheet meant something
- Export, so people can still answer a question nobody anticipated
- Bulk edit, because the alternative is forty clicks and a return to the spreadsheet
- An admin who can correct data without a developer
Read the spreadsheet before designing anything
The existing sheet is the specification, written by the people who do the work. The conditional formatting, the hidden columns, the tab everyone forgot about, the formula with three nested conditions — each encodes a rule somebody needed.
Going through it with the person who maintains it is the highest-value day of the project. It surfaces the rules that nobody would think to mention in a requirements meeting, because to them they are not rules, they are just how it works.
Sequence so both systems do not run forever
Running the tool and the spreadsheet in parallel feels safe and is the most common way these projects fail. Double entry is tedious, the spreadsheet is faster, and after a few weeks it is authoritative again.
A better sequence is to take one complete part of the process into the tool and move it fully, so the spreadsheet no longer holds that part at all. Then the next. Each step is a real migration rather than a duplication, and the day the spreadsheet is finally closed is a formality rather than a cliff.
What success looks like
Not that the spreadsheet is deleted. That the information is in one place, that more than one person can do the job, and that the process survives somebody leaving.
Those three were the actual problem. The spreadsheet was only ever the symptom.
Questions we get asked
Should we use a low-code platform instead of building?
Often yes, particularly where the process is close to a standard pattern and the volumes are modest. The trade-offs to check are per-user licensing as the team grows, how far the platform bends when the process is genuinely unusual, and what happens to your data if you leave.
How long does replacing a business-critical spreadsheet take?
A focused first version covering the main path is typically a small number of months. The long tail is the exceptions, which is why taking one part of the process fully rather than all of it partially gets value out earlier.
What if the person who owns the spreadsheet resists?
Usually they are not resisting the tool, they are anticipating losing the ability to handle the cases they currently absorb. Involving them as the source of the rules tends to resolve it, and their objections are generally the most accurate requirements list available.