Almost every operations team runs on a spreadsheet that grew into a system nobody planned. It works — until it does not. Replacing it is rarely a technology problem first; it is a question of when it is worth it, and how to do it without a failed big-bang migration. This is the case for a custom internal tool.
Why spreadsheets hold on
Spreadsheets survive because they are genuinely good at the start. Anyone can open one, change it, and see the result immediately. There is no access process, no ticket, no vendor. For a process that is still changing weekly, that flexibility is a feature, not a limitation.
They also cost nothing to start and nothing to abandon. That low commitment is exactly why they persist long past the point where they help.
The signals it is time to move
- Version chaos: multiple copies, "final_v3", and nobody sure which is current.
- Manual re-entry: the same data typed into two systems because they do not talk.
- No audit trail: you cannot say who changed what, when, or why.
- Scale breakage: the file is slow, locks, or corrupts as rows and users grow.
- Key-person risk: the process only works because one person knows the formulas.
- Errors with real cost: a mis-keyed figure has financial or compliance consequences.
The trap: the big-bang replacement
The instinct is to replace the whole thing at once with a full-featured system. That is the most common way these projects fail. The process is undocumented, half the value is tacit knowledge, and a six-month build lands after the process has changed again.
Big-bang also removes the old system before the new one has earned trust, so any gap becomes an outage in operations. The rebuild becomes scarier than the spreadsheet it was meant to replace.
A phased path that works
- Map the workflow as it actually runs, including the workarounds, not the idealised version.
- Pick the riskiest, highest-value slice — the part where errors or delays hurt most.
- Build that slice as a working tool people can use, alongside the spreadsheet rather than instead of it.
- Migrate data for that slice, run both for a short overlap, and compare.
- Retire the spreadsheet part only once the tool is trusted, then take the next slice.
What you actually need built
- A data model that reflects how the work really is, not how a generic product assumes it is.
- Roles and permissions, so the right people can do the right things.
- An audit trail — who changed what and when — often the whole point of leaving spreadsheets.
- Integrations with the systems the data already lives in, to end manual re-entry.
- Reporting and export, so people still get the views they rely on.
Keep the good parts of the spreadsheet
Do not throw away the flexibility that made the spreadsheet popular. Support quick views, ad-hoc export and easy adjustment of rules, or people will build a shadow spreadsheet the moment the tool feels rigid. The tool should be at least as fast for the common task, or adoption quietly fails.
Key takeaways
- Spreadsheets win early on flexibility and zero commitment, then break on versioning, audit and scale.
- Avoid the big-bang replacement; build one high-value slice and run it alongside the spreadsheet.
- Build the audit trail, permissions and integrations that were the reason to leave spreadsheets — and keep the flexibility people liked.
Founder & CEO
Yashwant DanielYashwant Daniel writes on compliance and trust engineering, custom software delivery and applied AI at Solvstrat — covering how regulated and mid-market teams build systems that hold up under audit, scale and scrutiny.
LinkedIn