When to replace a spreadsheet with a real system

Spreadsheets are excellent software, right up until the moment they are not. Here is how to tell which side of that line you are on.

Rainbow Coders, managed software and website projects

There is a snobbery about spreadsheets in software circles that is not really deserved. A spreadsheet that runs a business is not a failure of planning. It is usually the opposite: somebody understood their own process well enough to model it, and did so without waiting for a budget, a supplier or a project.

The problem is not that spreadsheets are bad. It is that they carry on appearing to work for a long time after they have stopped being the right answer, and the cost of that gap is paid quietly, in hours nobody logs and mistakes nobody traces.

Seven signs it has outgrown itself

1. Somebody is the only person who understands it

If one person built it, one person maintains it, and everybody else is faintly afraid of it, you do not have a business system. You have a dependency on an individual, and it is a dependency that goes on holiday and eventually changes jobs.

2. There are copies

Final. Final v2. Final v2 (Sarah's copy). The moment a file is copied to be worked on, you have two versions of the truth and no reliable way to say which is right. Merging them back is done by eye, and doing anything by eye at volume produces errors at a predictable rate.

3. It takes a person an afternoon a week to maintain

Copying figures between tabs, chasing people for updates, reformatting an export so it will paste in cleanly. Half a day a week is roughly twenty five days a year. Put that number in front of the cost of building something and the arithmetic often stops being close.

4. You cannot answer questions with it

"How many of these did we do last quarter, by region, excluding the cancelled ones?" If answering that means an hour of filtering and a fresh pivot table every time, the data is being stored but not made available, which is only half the job.

5. Mistakes are getting through

A dragged formula that stopped one row short. A column sorted independently of the ones beside it. Spreadsheets do exactly what they are told, silently, and they have no concept of a rule that must always hold. A real system can refuse to accept an invalid state. A spreadsheet cannot even notice one.

6. More than one person needs it at once

Shared editing helps, but it does not solve the underlying issue: two people making related changes with no notion of a transaction between them. In a system, either both changes happen or neither does. In a spreadsheet, you find out later.

7. You cannot tell who changed what

For plenty of businesses this is a nuisance. For anybody handling regulated data, financial records or client commitments it is a genuine exposure. When something is disputed, the ability to say who changed which figure and when is the difference between a conversation and a problem.

What a real system actually buys you

Not features. Guarantees.

  • Rules that cannot be broken. An invoice cannot exist without a client. A date cannot be before the one it follows. The system refuses, rather than storing something impossible and letting a person find it later.
  • One version of the truth. Everybody is looking at the same record, now, with no copies in circulation.
  • A record of who did what. Not a feature you use daily. A feature that saves you completely on the day you need it.
  • Roles. People see what their job requires and change what their job permits, which is both a security control and a considerable reduction in accidental damage.
  • Work that happens on its own. The reminder that sends itself, the report that arrives on Monday morning, the status that updates without anybody remembering to update it.

What it costs you

Being honest about this matters, because the pitch that ignores it is the pitch that ends in a disappointed client.

You lose the ability to change the shape of the thing in ten seconds. In a spreadsheet, a new column is a new column. In a system it is a change request, and it takes longer and costs money. That flexibility is genuinely valuable, and if your process is still changing every month, you may not be ready to fix it in software yet.

You also take on something that has to be maintained: hosted somewhere, backed up, updated, and occasionally fixed. That is a real ongoing commitment, and anybody who tells you otherwise is selling.

How to move without breaking anything

The failure mode here is the big bang: eighteen months of building, one weekend of switching over, and an enormous amount of hope. It rarely goes well.

The approach that works is narrower. Take the single most painful part of the spreadsheet, the one that costs the most time or causes the most errors, and build only that. Run it alongside the spreadsheet for a few weeks so people can compare the two and trust the new one. Then take the next piece.

It feels slower. It is dramatically more likely to end with something people actually use, because each step is small enough to correct and each step delivers something on its own.

The honest test

Add up the hours your team spends maintaining the spreadsheet rather than doing the work it describes. Add a fair estimate of what the mistakes have cost. Compare that annual figure to a build cost. If it is not close, you already know the answer, and you have probably known it for a while.

If it is close, stay where you are and revisit it in six months. That is a legitimate answer, and we will tell you so.

If you want a second opinion on which side of the line you are on, start a conversation. We will tell you honestly if the answer is to keep the spreadsheet.

  • business systems
  • spreadsheets
  • process automation
  • bespoke software
  • data quality

Related reading

Have a project that needs this kind of thinking?

Tell us about it. The first conversation costs nothing.

Start a project