When to replace spreadsheets with custom software

Almost every business platform I have been asked to build started life as a spreadsheet. Not a bad spreadsheet. A good one, usually, built by somebody who understood the work properly and needed an answer that afternoon.

Then it grew. A second sheet, then a third. A colleague got edit access. Someone added a column that another formula quietly depended on. Two years later it runs a department, three people are afraid to touch it, and one person is on holiday.

That is the moment businesses start searching for how to replace spreadsheets with custom software. This is what I have learned from being on the other end of that call.

Why the spreadsheet wins first, and deserves to

It is worth being clear that the spreadsheet was not a mistake. It won for good reasons, and any honest case for replacing it has to start by admitting them.

It cost nothing. It needed no specification, no approval and no developer. It was shaped exactly around how the work is really done rather than how a software vendor imagined it. It could be changed at eleven at night by the person who understood the problem. No custom system will ever beat that on speed of change, and you should be suspicious of anyone who says otherwise.

A spreadsheet only becomes a liability when the thing it is holding up has become more valuable than the spreadsheet is reliable.

Five signs you have outgrown spreadsheets

1. 1More than one person edits it. The moment two people can open the same file, you have a concurrency problem with no solution. Whoever saves last wins, and nobody is told they lost.
2. 2Somebody has become a human integration. If a person spends hours each week copying figures from one sheet into another, or out of a sheet into the accounting system, that is not admin. That is an unpaid, error-prone data pipeline with a pulse.
3. 3Nobody can answer "who changed this?" One institute I worked with was running classes, assignments and attendance across spreadsheets and chat threads, and the thing that finally forced the rebuild was not the workload. It was that a mark changed and nobody could say who changed it or when.
4. 4The rules live in one person's head. Not in the file. In their head. The pricing logic, the exceptions, the customer who is billed differently for historical reasons. If that person leaves, the business loses a process it cannot reconstruct.
5. 5It holds data you would be embarrassed to lose or leak. Personal details, payroll, patient information, contracts. A file that anyone with the link can copy in full is not access control.

One of these is survivable. Three or more together and the spreadsheet is no longer saving you money, it is deferring a cost while quietly adding interest.

What actually breaks

Most articles on this subject stop at the symptoms. The underlying problem is that a spreadsheet is missing four things a business system needs, and none of them can be added to it later.

• No validation at the point of entry. A database refuses an invoice with no customer. A spreadsheet accepts anything typed into any cell, including a date that is secretly text, which is why the totals are wrong.
• No relationships. Delete a customer row and their orders remain, pointing at nothing. Nothing tells you. The report simply becomes slightly less true.
• No history. Every change overwrites the previous value permanently. There is no record of what a figure was last Tuesday, which matters enormously the first time somebody disputes an invoice.
• No real permissions. Access is per file, not per row or per field. You cannot let a contractor see their own jobs without also showing them everyone else's rates.

Notice that the last row favours the spreadsheet. That is real, and it is the trade you are making: you give up the ability to change anything instantly in exchange for the guarantee that nobody can change everything accidentally.

When a spreadsheet is still the right answer

I talk clients out of building things fairly often, so it is worth saying plainly when not to replace a spreadsheet.

Keep it when the process is still taking shape and the rules change monthly, because you would be paying to harden something that is not settled yet. Keep it for genuine analysis, modelling and one-off exploration, which is what spreadsheets are actually superb at. Keep it when one or two people use it and the data would be no disaster to lose. Keep it, above all, as a prototype: a spreadsheet is the cheapest possible way to discover what a process really needs before anyone writes code.

Build or buy?

Before commissioning anything custom, look properly at off-the-shelf software. If your process is genuinely standard, somebody has already built it better than a bespoke first version will be, and they maintain it for a monthly fee.

Building earns its cost in three situations. When the process is the business, and bending it to fit a product would remove the thing that makes you competitive. When per-seat pricing has grown past what the tool is worth, which happens quickly on headcount. And when you are already paying for three tools plus a person to reconcile them, which is the expensive case dressed up as the cheap one.

A mining company I worked with was in the third situation. Each site tracked its own revenue, plant and spend separately, and head office could not say which site was actually profitable without a week of manual consolidation. The system that replaced it was not sophisticated. It just held one version of the numbers.

How the migration actually goes

1. 1Read the spreadsheet as the specification. It is the most accurate requirements document you will ever be handed, because it describes what people actually do rather than what they say they do. The workarounds in it are requirements too.
2. 2Model the entities, not the columns. Sheets flatten everything into one grid. The real structure underneath is usually customers, jobs, invoices and people, each with a life of its own. Getting that right is most of the work.
3. 3Put the rules in the database, not just the screen. Validation only in the interface is a suggestion. Constraints in the data are a guarantee, and they are what stop the new system quietly rotting the way the old file did.
4. 4Ship the slice that retires one whole sheet. Not a half-replacement of everything. One sheet, gone completely. It proves the thing works and it gives people an immediate reason to use it.
5. 5Run both for a fortnight, then actually delete the spreadsheet. This is the step people skip, and skipping it is fatal. A system that runs alongside the old file forever has not replaced anything, it has added work.
6. 6Keep an export. People need to know the data can still come out as a sheet when they want to model something. Knowing it is possible is usually enough; they rarely do it.

The first version should feel almost disappointingly small. Enrolment platforms, class management systems and site ERPs all start as one form and one list that someone uses on the Monday.

What you get on the other side

The obvious wins are the ones in the table: real permissions, a record of every change, data that refuses to be wrong, and reporting that is current rather than reconstructed. The one that surprises people is different.

Once the process lives in a database rather than a file, it can be connected to things. Notifications when something needs attention. A customer-facing portal so clients submit their own information instead of emailing it to be retyped. Payments taken at the right moment in the flow. Later, if it is useful, an assistant that answers questions over your own data. None of that is available to a spreadsheet at any price.

The question is never whether the spreadsheet works. It is whether you would be comfortable explaining to a customer how it failed.

If three or more of those five signs describe your operation, the spreadsheet has already become a business system. The only open question is whether it is one you chose deliberately, or one you inherited by accident.