Spreadsheets are one of the most successful pieces of software ever built. They need no requirements document, no deployment, and no engineer. A person can model a problem in the same afternoon they discover it, and change the model the moment they learn something new. That is a genuinely hard thing for purpose-built software to match, and most attempts to replace a spreadsheet fail because the replacement is worse at exactly the thing the spreadsheet was good at.
So the useful question is not whether spreadsheets are bad. It is which specific spreadsheet in your company has stopped being a tool someone uses and become infrastructure the business depends on. That transition happens quietly, usually without anyone deciding it, and it is the point at which the economics change.
Most of your spreadsheets are fine
Before anything else: the default answer is keep it. A spreadsheet that one person owns, that models a decision rather than records a fact, and whose loss would cost an afternoon of rework is doing its job. Migrating it into an application makes it slower to change and harder to inspect, in exchange for guarantees it does not need.
- One owner, or a small group that coordinates verbally without friction
- The output is analysis, a model, or a one-off decision rather than an operational record
- Losing the file would be annoying rather than expensive
- The structure changes often because the thinking is still changing
- Nothing downstream (billing, payroll, dispatch, compliance) reads from it
The signals that it has crossed over
Row count is a poor threshold. Plenty of 80,000-row files are harmless, and plenty of 200-row files are load-bearing. What matters is whether the file has taken on obligations it has no mechanism to meet. These are the signals, roughly in the order they appear.
More than one person needs to edit it at once
This is the first and most reliable signal. The moment two people need to write to the same file in the same hour, someone starts waiting, or someone starts working in a copy. Cloud co-editing softens this but does not solve it, because it resolves conflicts at the cell level while the business rules live across rows. Two people can each make a locally valid edit and produce a globally wrong result.
It has become the system of record
Ask what happens if the file and the ERP disagree. If the answer is that people trust the spreadsheet, the spreadsheet is the system of record, whatever the org chart says. Once a file holds the only authoritative copy of something (open jobs, inventory adjustments, commission rates, who is certified for what), it has taken on a durability obligation it cannot enforce.
There is a master copy and several that disagree with it
Filenames with dates, initials, or the word final are not a naming problem. They are the observable symptom of a concurrency problem people have already solved by hand, badly. The cost is not the copies themselves; it is the reconciliation work and the decisions made from the wrong one.
- Formulas encode business rules that no one currently employed can explain, and nobody will touch column AF
- There is no record of who changed a value, when, or why, so disputes are settled by whoever remembers hardest
- Data quality depends entirely on people being careful, and it degrades exactly when the team is busiest
- The recovery plan for a corrupted or overwritten file is hope, or a version history nobody has ever tested
- Other systems now read from it: someone exports it weekly, or a macro pushes it somewhere
- Access control is the file's location, which means anyone who can open it can change anything in it
Symptom, underlying limit, smallest fix
Each symptom maps to a specific technical limit, and each limit has a smallest fix that actually addresses it. Skipping to a custom application when a shared database would do is the most common overcorrection.
| Symptom | Underlying limit | Smallest fix that works |
|---|---|---|
| People wait for the file, or edit copies | No concurrency control; the file is the lock | A shared database with row-level writes, even behind a simple form |
| Copies named final, v3, and JK-edit | No single authoritative store | One store, and reports that read from it instead of duplicating it |
| Bad data reaches downstream systems | Validation is a social norm, not a rule | Typed columns, required fields, and referential constraints at the data layer |
| Nobody can explain why a number changed | No change history and no attribution | An append-only audit log capturing who, what, when, and prior value |
| Everyone can see and edit everything | Access control stops at the file | Roles applied per record and per field, not per document |
| Formulas nobody dares to modify | Business rules live in cells with no tests | Move the rules into named, documented, testable logic |
| Weekly manual export into another system | No integration surface | A scheduled sync or API against the shared store |
| A corrupted file would stop the business | No backup, restore, or recovery target anyone has tested | Managed storage with point-in-time restore, and one rehearsed restore |
What a database-backed application actually gives you
The gains are specific, and it is worth naming them rather than assuming that structured is better than unstructured. You are buying five things.
- Concurrency: many people writing at the same time without overwriting each other, with conflicts resolved by rules rather than by whoever saved last
- Constraints: invalid data is refused at entry instead of discovered three weeks later in a report
- Audit trail: every change attributed and timestamped, which turns disputes into lookups and makes compliance answerable
- Roles: a technician, a dispatcher, and a controller see and edit different things in the same record
- Integration: other systems read and write through a defined interface, so the weekly export stops being a person's job
The first two are the ones that pay for the project. Concurrency removes a queue that people have been absorbing with their time, and constraints stop the class of errors that is most expensive to find later. The other three are what make the result durable rather than a nicer spreadsheet.
What you give up
Every one of those guarantees is paid for with flexibility, and a replacement that ignores the cost gets rejected by users no matter how correct it is.
You lose immediacy. In a spreadsheet, a new column takes ten seconds. In an application, it takes a change request, a schema migration, and a release. You lose the ability for anyone to just look. The grid showed everything at once, and a well-designed application deliberately shows less. You lose the escape hatch, where someone types a note into an unused column because the situation did not fit the model. And you introduce a dependency: the spreadsheet worked offline, on a plane, forever, with no vendor and no uptime.
The practical mitigation is to keep an export that looks like the spreadsheet people gave up, and to design the primary screen as a grid rather than a form wherever the work is genuinely list-shaped. Fighting the spreadsheet habit is a losing strategy; absorbing it is not.
The options in between
There is a wide gap between a shared workbook and a custom application, and most operations land somewhere inside it. Moving one step is usually right; moving three is usually a project that stalls.
| Option | Good when | Where it breaks |
|---|---|---|
| Structured workbook: locked ranges, validation, one owner | One editor, low stakes, and the structure is stable | The moment a second person needs to write to it |
| Spreadsheet database (Airtable, Smartsheet, and similar) | You need concurrency, typed fields, and views quickly | Complex permissions, high row volume, and per-seat pricing at scale |
| Low-code app over a managed database | The data model is settled but the interface needs to fit roles | Non-trivial business logic, offline use, and vendor lock-in on export |
| Database plus a thin internal tool layer | Data integrity and reporting matter more than the interface | External or field users who need a considered experience |
| Purpose-built application | The workflow is a competitive difference, or the rules are genuinely yours | Cost and time to first value, if the scope is not held to one workflow |
A trades services business moved dispatch, field updates, and invoicing onto a spreadsheet-database bridge in six weeks, then used that period to learn what the real platform needed before building it.
That sequence is the point. The intermediate step is not a compromise you settle for; it is how you find out what the permanent system should do, using real work rather than a requirements workshop.
How to make the call
- 1
Name the spreadsheet that would hurt most if it were lost or wrong on a Monday morning. Start there and nowhere else.
- 2
Write down what it is the system of record for. If the answer is nothing, keep it and stop.
- 3
Count the hours per month currently spent reconciling copies, chasing bad data, and waiting for the file. That number is the budget.
- 4
Identify which of the five guarantees you actually need. Needing one or two points at a shared database; needing all five points at an application.
- 5
Move one step up the ladder, not three. Keep the spreadsheet running in parallel until the replacement has survived a full cycle, including month end.
- 6
Set an exit condition for the parallel period at the start, or you will be running both for a year.
The failure mode we see most often is not moving too late. It is moving too far in one step: replacing a spreadsheet that had one real problem with an application that solves eight, takes nine months, and is rejected because it made the daily work slower. Fix the limit that is actually costing you, and let the next one prove itself before you spend on it.
Common questions
- How many rows is too many for a spreadsheet?
- There is no useful number. Performance degrades somewhere in the tens of thousands of rows with heavy formulas, but that is a nuisance rather than a reason to replace anything. The threshold is concurrency and consequence: how many people need to write to it, and what breaks if it is wrong. A 500-row file that drives payroll is a bigger problem than a 200,000-row file used for analysis.
- Can we just move it to Google Sheets or SharePoint and be done?
- Sometimes, and it is worth trying first. Cloud co-editing genuinely solves the waiting problem and gives you version history and access control at the file level. It does not give you typed fields, referential integrity, per-record permissions, or an audit trail you can defend, so if your problem is data quality or accountability rather than access, it will not hold.
- Is Microsoft Access still a reasonable answer?
- It solves the right problems (a real data model, constraints, forms, and multi-user access), which is why so many of them are still running. The difficulties are operational: file-based backends do not tolerate many concurrent users well, deployment and backup are manual, and the pool of people who will maintain it keeps shrinking. If you are already there, treat it as a data model worth keeping and a runtime worth replacing.
- What does it cost to move one spreadsheet into a real system?
- A single workflow moved onto a spreadsheet-database platform with proper fields, roles, and views is typically a few weeks of work. A purpose-built application for the same workflow starts well into five figures because it includes migration, integration, permissions, and the error cases the spreadsheet never handled. The gap between those two numbers is why the intermediate options are worth taking seriously.
- The formulas encode rules nobody understands. Where do we start?
- Do not start by reading the formulas. Start by asking the people who use the output what the rule is supposed to be, then compare their answer to what the file actually does. The differences are the valuable finding, and they are usually a mix of deliberate exceptions worth keeping and errors that have been quietly compounding.
- Should we keep the spreadsheet after the replacement goes live?
- Keep it read-only for one full operating cycle, including a month end, as a reconciliation reference. Do not keep it editable, because a spreadsheet that can still be edited will still be edited, and you will have two systems of record instead of one. Set the date it becomes read-only and the date it is archived before you cut over.