When to stop fixing your spreadsheet and build something else

Most spreadsheets people want to replace do not need replacing. Some needed replacing a year ago. The difference is not size, and it is not how ugly the formulas have become.

Notes on the boring parts · 9 minute read

There is a particular moment in a growing business where somebody says we have outgrown the spreadsheet. Sometimes that is true. Often the spreadsheet is fine and something around it is broken, and replacing the file will move the problem rather than solve it.

Getting this wrong is expensive in both directions. Rebuild too early and you have swapped a file everyone understands for a system only one person does. Leave it too late and you are reconciling numbers by hand every month and quietly absorbing the errors.

Here is how to tell which situation you are in.

Five signals it has genuinely outgrown itself

1. More than one person needs to write to it at once

This is the clearest signal, and it is about concurrency rather than volume. The moment two people are editing the same rows, you need something that can arbitrate — a real record lock, or a queue, or per-user permissions finer than "can edit this tab".

Google Sheets handles simultaneous editing far better than a shared file on a drive, so this arrives later than it used to. It still arrives.

2. The same fact is stored in more than one place

A customer's address in the orders tab, again in the invoices tab, again in a tab someone made for a mailing. Now they move house.

Every copy is a chance to be wrong, and the wrongness is silent. This is the single most reliable indicator that you want a system with one row per thing and references to it, rather than a file with the same thing typed in four places.

3. You need a real audit trail

Version history tells you a cell changed. It does not readily tell you who approved a discount, when, and on what basis — not in a form you would want to hand a regulator, an auditor, or a client in a dispute.

If the answer to "who changed this and why" matters more than occasionally, that is a requirement a spreadsheet is not built to meet.

4. The workbook is doing work on a schedule

Pulling from an API, sending mail, updating another system on a timer. This can be made to work with scripts attached to the file, and it goes wrong in a particular way: the automation fails silently while the file still opens fine, so nobody notices for weeks.

Scheduled work wants somewhere it can be monitored, retried, and alerted on. That is not a spreadsheet's job.

5. Being wrong is expensive

Not inconvenient — expensive. Payroll, tax, client billing, regulatory returns, anything where an error costs real money or credibility.

Spreadsheets fail quietly. A dragged formula that stops one row short produces a number that looks entirely plausible. When the cost of a plausible wrong number is high, you want something that can enforce a rule rather than trust a habit.

Three that look like signals and are not

The question is not whether the spreadsheet is messy. It is whether what you need is something a spreadsheet can be.

Is it the file, or the process around it?

The middle option nobody considers

The choice is usually framed as keep the spreadsheet or replace it with software. There is a third option that is cheaper than both and fits more situations than either.

Keep the spreadsheet as the place people look, and automate the work around it.

The sheet stays the interface, because everyone already knows how to read it. What changes is that nobody is retyping into it. Data arrives from wherever it comes from, gets normalized and checked on the way in, and anything that fails the check goes to a queue somebody can see rather than being silently dropped.

You keep the thing people like about spreadsheets — you can look at everything at once — and remove the thing that actually causes the errors, which is a human being retyping the same field for the fourth time.

If you do decide to rebuild

Two things worth deciding before anyone builds anything.

Keep the spreadsheet as a read-only view for a while. Run both in parallel and reconcile. It is the only reliable way to find out that the old sheet had a rule in it nobody wrote down, which is very common and always discovered late.

Decide what happens to the history. Migrating three years of rows into a system that expects clean data is where these projects usually stall. Sometimes the honest answer is to migrate the last twelve months and keep the old file, read-only, as an archive.

The short version