When the Spreadsheet That Runs Your Business Stops Being Good Enough
Synergised Consulting Ltd
Last Updated: 28 September 2026
A spreadsheet has outgrown the workflow it runs when people spend more time working around the file than in it: manual joins between sheets, silent copy-paste errors, no record of who changed what, and one person who understands how it all fits together. The fix is not a bigger spreadsheet. It is moving that workflow onto a database-backed platform, and the move can be done without stopping the business, by running the old file and the new system in parallel for a full cycle before cutting over.
This happens to good businesses, not careless ones. The workbook that tracked fifteen orders a month becomes the thing that tracks the whole operation, and it crosses the line quietly. Nothing announces the moment. The signals are specific, they are visible in an afternoon, and the decision about what to do follows from them.
Why Spreadsheet Errors Are Structural, Not Careless
Most consequential spreadsheets contain at least one error, and the errors come from how spreadsheets work rather than from how people feel about them. A person entering data into cells is highly accurate, but a model with thousands of cells gives every one of those small inaccuracies thousands of chances to matter. Nothing in a spreadsheet forces a test, a review, or a record of what changed, so errors persist until something external exposes them. The error rate is a property of the tool.
The research on this is old, consistent and unusually well quantified. Raymond Panko, a professor at the University of Hawaii, compiled nine experiments in which 547 people built spreadsheets from a set task: the percentage of cells containing errors ranged from 1.1% to 5.6% across the studies and averaged 3.2% [1]. Field audits tell the same story about real spreadsheets rather than experiment ones. Panko and Halverson's review in the Journal of the Association for Information Systems reported seven audits covering 367 operational spreadsheets, with errors found in about a quarter of them; the most recent audits in that series, using more effective techniques, found errors in 91% of the 54 spreadsheets they examined [2].
The mechanism matters more than the headline. Panko and Aurigemma's taxonomy work in Decision Support Systems found that spreadsheet developers are typically 96% to 99% accurate per cell entry, and that the majority of errors are domain logic mistakes, not typing slips [3]. In other words, the error is usually a sensible-looking rule applied wrongly, which is exactly the kind of error a quick glance at the total will not catch. England's contact-tracing failure in October 2020 is the public version: Public Health England loaded test results into a legacy file format whose 65,536-row limit silently cut off everything beyond it, and 15,841 cases never reached contact tracers [4]. The totals looked entirely reasonable. That is what makes spreadsheet errors expensive: not the mistake that makes the number absurd, but the one that leaves it looking fine.
The Signals a Workflow Has Outgrown Its Tool
What to look for, concretely
The signals are boring and they are decisive: views that take seconds to load, automations that queue and run late, a manual export ritual that copies data between systems every week or every day, integrity errors that recur after each fix, and a price that climbs per seat or per record as the team grows. Agencies that carry out these migrations for a living describe the same list; Kreante's migration guide names slow views, automation delays and API limits as the operating thresholds, and Junto's comparison adds the per-user pricing cliff and the absence of any record of who changed what [5] [6]. No single signal settles it. Two or three together mean the workflow needs a system of record, not a bigger file.
The signal that does not show up in the tool
In discovery workshops, owners rarely arrive with a list of what to migrate. It gets built in the conversation, walking through a normal week task by task, and the spreadsheet-shaped bottlenecks separate themselves: the file somebody copies from an email every morning, the workbook only one person can reconcile, the monthly close that stretches out because several exports have to be pasted together by hand. When one person's holiday puts a core workflow at risk, that is the clearest outgrown signal there is, and it never appears in any feature comparison.
What Moving Without Stopping the Business Looks Like
The move is a database swap behind the workflow, not a rebuild of the business. The sequence that works is: map what the spreadsheet actually does, including the hidden rules that live only in someone's head; build the new schema with real relationships and constraints; run both systems in parallel over at least one full business cycle; then cut over and keep the ability to export, forever. Migration guides converge on the same point: never cut over without a parallel run, because the spreadsheet's logic is always messier than anybody remembered [5].
A worked before and after, as an illustration
Take a twelve-person firm tracking orders in a workbook, and to be clear this is an illustration of the pattern, not a case study of any real engagement. Before: a team member copies order details from email into the sheet each morning, a summary formula was written months ago and stops at the row where the data used to end, and nobody notices because the total still looks plausible. One person built the file, so every question routes to them. After: each order is a record in a proper table, entered once through a form; totals are queries, not fragile formulas, so they cannot silently stop at row 400; every change carries a timestamp and a name; and three people can answer any question about the data, not one.
What the parallel run actually tests
The parallel run is not a formality. It is where the spreadsheet's undocumented rules surface, usually as disagreements between the old totals and the new ones. Each disagreement is a decision that was hiding in a formula: what counts as an order, when a refund leaves revenue, which customers get the trade price. Resolving those explicitly, and writing the answers down, is the part of the migration that has value beyond the migration itself.
When Keeping the Spreadsheet Is the Right Answer
Plenty of workflows should stay exactly where they are. If one person uses the file, the data is small, the logic is stable, and the owner could reconstruct the numbers from source documents if the file were lost, migrating it buys little and costs attention that the business needs elsewhere. Kreante and Junto both make the same point from the other direction: where non-technical staff need to change the structure themselves, a spreadsheet's flexibility is the feature, not the defect [5] [6].
Two habits make any retained spreadsheet materially safer, and both come from Panko's own prescriptions: never hardwire a number inside a formula when it could reference a cell, and never enter the same number in two places [7]. Those two rules remove the most common way a workbook drifts out of line with reality. A retained spreadsheet with an owner, those habits, and a note of what it is for is a legitimate system. An untended one running a core workflow is a liability with a friendly interface.
What Actually Changes When the Workflow Moves
Speed is the least of it. What changes is the questions the business can answer without asking a person: who changed this figure, when, and under what rule. That is the difference between data that lives in someone's head and data the business actually holds. It is also the property a future buyer, an auditor or a new manager needs first, before anything else about the system matters.
We see the same shape in discovery workshops: the workflows worth moving are rarely the ones with the cleverest formulas, they are the ones where the business currently depends on one person's memory of how the file works. Move those, and the dependency is gone. Keep the register of which workflows you decided about, and why, because in a few years it will read as the record of when the business stopped being run from a grid.
Sources
- [1] Raymond Panko, Spreadsheet Development Error Experiments, University of Hawaii Spreadsheet Research site:
- [2] Panko and Halverson, "An Experiment in Collaborative Spreadsheet Development", Journal of the Association for Information Systems, 2001:
- [3] Panko and Aurigemma, "Revising the Panko-Halverson Taxonomy of Spreadsheet Errors", Decision Support Systems, 2010:
- [4] The Register, reporting Public Health England's contact-tracing data loss, October 2020:
- [5] Kreante, "Airtable as Database vs Supabase 2026: When to Migrate":
- [6] Junto AI, "Airtable vs Supabase vs PostgreSQL Compared":
- [7] Raymond Panko, Spreadsheet Research publications page, University of Hawaii:
