Every organisation has a spreadsheet that started as a list and became a system. It tracks orders, or stock, or jobs, or who owes what to whom. It has tabs that reference each other, a column of formulas somebody wrote three years ago, and one person who really understands it.
This is not a failure. Spreadsheets are the most successful end-user programming environment ever built, and the workbook exists because it solved a real problem faster than anything else could. The question is not whether it should have been built. The question is whether the business now depends on it in ways it was never designed to support.
The signs
Some of these will be familiar:
- Versions. The workbook is emailed around, and there is a “final” and a “final v2”. Two people have made changes to different copies and someone has to merge them by hand.
- Rules in formulas. Business logic, such as how commission is calculated or when an order is late, exists only as a formula. Nobody has written it down anywhere else, and the formula has been edited since.
- Re-keying. Data is copied from the spreadsheet into the finance system, or from the ordering system into the spreadsheet, as part of somebody’s job.
- A single author. One person maintains it. When they are on holiday, changes wait. When they leave, the organisation inherits something it cannot read.
- Month-end assembly. Reports are built by hand from this workbook and two or three other sources, and the people who build them do not fully trust the result.
Individually, none of these is a crisis. Together they describe a system of record that has no audit trail, no concurrency, no access control, and a key-person dependency the business has not priced.
What replacement should look like
The mistake is to treat the replacement as a data-entry exercise: build screens that mirror the tabs and move on. The workbook’s value is not its layout. It is the process it encodes, including the exceptions and workarounds that nobody would have put in a requirements document.
A good replacement starts by reading the spreadsheet as a specification. What does each tab actually represent? Which columns are entered and which are derived? Where do the numbers come from and where do they go? What happens in the edge cases the formulas handle with an IF?
From that reading, three design decisions follow.
Which data the new system owns. Some of what the spreadsheet holds belongs elsewhere: customer records in the CRM, ledger balances in finance. The new system should own the operational data that has no other home and read the rest through integration, rather than becoming another copy.
What the rules are. The formulas become tested code with the rule written beside it. This is the moment to find out whether the rule is what the business thinks it is; it often is not.
How the work is done. Screens are designed around tasks, not tabs. The person who used to filter a sheet to find overdue orders should now open a list that is already filtered, with the action they need to take beside each row.
Migration without a cliff edge
The historic data has to move, and it has to reconcile: the new system’s totals must agree with the workbook’s before anyone trusts it. That reconciliation usually surfaces errors in the spreadsheet that nobody knew about, which is uncomfortable and useful in equal measure.
Then the two run side by side for an agreed period. The spreadsheet is retired only when the new system has proven itself in live use. Nobody should be asked to trust software on the strength of a demonstration.
The result
What the organisation gets is not just a database with screens. It gets one place where the data is true, rules that are enforced rather than remembered, a history of who changed what, the ability for the whole team to work at once, and a system that someone other than its original author can support.
The spreadsheet did its job. The point of replacing it is to keep what it knew and lose what it could not do.