Insight

When does a spreadsheet become a business risk?

19 Jun 2026

• Modernisation
• Operations
• Custom software

Spreadsheets are excellent software. They are quick to start, easy to change, and understood by almost every business team. Replacing one simply because it looks untidy is rarely a good use of money.

The problem begins when a spreadsheet stops being a document and becomes the place where the business runs.

Look for dependency, not row count

A file with 100,000 rows can be fine. A file with 200 rows can be dangerous if one person is the only one who knows why column M must never be edited after Tuesday.

These signs matter more than size:

• the workbook contains macros or formulas nobody is willing to touch;
• people make local copies because the shared version is too slow or frequently locked;
• access to sensitive data is controlled by possession of the file;
• staff copy values from email, an ERP, or another workbook every day;
• a mistake is usually discovered by a customer or during invoicing;
• the person who built it has become the unofficial support desk.

At that point the spreadsheet is already a custom application. It just lacks the safeguards normally expected from one.

Do not begin by copying every sheet into a web screen

Spreadsheets grow around exceptions. A new tab appears for one customer. A colour means “waiting for warehouse confirmation”. A blank cell has a different meaning from zero. Those details contain useful knowledge, but they are not automatically good software requirements.

Before designing a replacement, watch the work. Ask somebody to process a normal case and then an awkward one. Find out where data originates, which values are calculated, who is allowed to change a status, and what happens after an error.

This often reveals that the real system is larger than the workbook. Important steps live in email, chat, a calendar, or somebody’s memory. A literal spreadsheet replacement would preserve the visible part while missing the process around it.

Replace the risky part first

A full rebuild may be unnecessary. Sometimes the first useful change is a reliable import, a controlled approval screen, or a database behind the existing reporting workbook. Staff can keep a familiar tool while the fragile data handling moves somewhere safer.

Where a new application is justified, the first release should cover a complete piece of work rather than every tab. For example, take a request from entry through approval and export. Let the old workbook continue handling the remaining cases until the new path is proven.

Running both systems for a short period costs time. It is still safer than switching years of improvised business rules in one weekend.

Keep the flexibility people were using

Teams often like spreadsheets because they can correct a mistake without filing a support ticket. A replacement that removes all discretion can be technically neat and operationally worse.

Good internal software gives people controlled ways to handle real exceptions. It records who changed what. It can require a reason for unusual actions. It should also make common corrections possible without database access.

The goal is not to stop the business from changing the system. It is to move those changes out of hidden formulas and into behaviour that can be understood, tested, and supported.