The spreadsheet is often innocent

A spreadsheet may be a perfectly good calculation, a quick way to learn a process, or the simplest shared tool the team has. Treating every spreadsheet as a failed software product skips the diagnosis.

Replace it when the grid itself blocks the work: people overwrite one another, permissions are too coarse, history matters, integrations must react to events, or a row has become a customer case with states and owners. If the real problem is an unclear handoff, a custom interface will reproduce it in a more expensive shape.

The complaint is usually about the work around the sheet

“We need to get out of spreadsheets” sounds specific. It often contains several different problems:

• the same customer is copied into three files;
• nobody knows which version is current;
• a manager cannot see who should act next;
• formulas are fragile and understood by one person;
• access to one row means access to every row;
• a customer event should trigger another system but does not; or
• the business has changed, while the sheet still encodes last year’s process.

Only some of these are properties of spreadsheets. Duplicate entry may come from disconnected systems. Missing ownership may come from a missing operating rule. A fragile formula may only need to be made smaller, documented, and protected from accidental input changes.

The useful first move is to take one real row and follow it. Who creates it? What makes it ready for the next person? Where does someone leave the sheet to ask a question? What is supposed to happen when the ordinary route fails?

That small trace is more likely to find the constraint than a platform migration workshop built around people’s recollection of the process. The same trace is the basis of software discovery before a line of code is written.

A spreadsheet can play three very different roles

A calculation someone owns

One person maintains a forecast or pricing model. Inputs are controlled, outputs are reviewed, and the file does not coordinate a live queue of work.

This can be an excellent spreadsheet. The grid makes assumptions visible, changes are cheap, and the person doing the work can inspect the formulas. Rebuilding it as a web application may remove the very flexibility that makes it useful.

The right improvement could be mundane: name the owner, separate inputs from formulas, add a change log, protect sensitive data, and test the cells that affect important outputs.

A shared inbox wearing rows and columns

Many people add records, write notes, change statuses, and use colours to signal what happens next. The file is no longer only calculating. It is coordinating work.

This can function for a small team when the state model is simple and everybody sits close enough to resolve ambiguity. It starts to strain when two people update the same item, a row needs a durable owner, or management asks what changed and when.

Before replacing it, write the missing rules in plain language. What states exist? Who can move work between them? Which fields are required? What counts as done? Software can enforce those rules once the team has chosen them.

An operational database connected by memory

The sheet now holds the operational record. Other systems depend on exports from it. Staff remember which tab feeds which report. Customer-facing actions rely on someone noticing a cell has changed.

At this point the grid may genuinely be the constraint. Rows do not naturally provide granular permissions, reliable event handling, transactional updates, or a well-defined API. The cost appears as waiting, repeated checking, reconciliation, and recovery when the informal chain breaks.

This is where an integration or purpose-built system can earn its place.

Spreadsheet errors are real, but the familiar slogan is too easy

It is common to argue that spreadsheets must be replaced because they contain errors. The evidence is more interesting than the slogan.

In a study of 25 operational spreadsheets from five organizations, Stephen Powell, Barry Lawson, and Kenneth Baker found that many identified errors had no quantitative impact, while some did materially affect key outputs. The sample is small, but it is enough to challenge a simple error count as a risk measure. Read the paper and its sample limits.

That does not make spreadsheets safe. It tells us to assess consequence, not merely count defects. A typo in an exploratory scenario and a wrong formula in a price sent to customers are not the same risk.

The same researchers surveyed nearly 1,600 spreadsheet users and found differences related to user expertise, practices, and organizational policies. Their results point to a management problem as well as a tool problem. Replacing Excel without changing ownership, review, and access can preserve the conditions that made errors likely.

Official GOV.UK guidance on shared spreadsheets is refreshingly practical: design for other users, explain the data, make structure and access clear, and handle sensitive information deliberately. Those controls are sensible whether the sheet will live for two weeks or two years.

Size is a weak replacement signal

A large spreadsheet is not automatically a software requirement. A small one can be dangerous if it controls high-impact work.

The stronger replacement signals are about state and coordination:

Several people change the same record. The system needs concurrency rules, not a prettier grid.

Different roles should see or change different information. File-level access is too coarse.

History must survive. You need to know who changed a value, when, why, and what it was before.

One change should reliably cause another action. An event needs to update inventory, create a task, call an API, or notify the right owner without somebody watching a cell.

The work has meaningful exceptions. A row is not simply open or done. It can be waiting for documents, under review, approved with conditions, or returned to a previous owner.

Customers or partners participate. External users need a controlled view and a deliberate experience, not a shared internal file.

Recovery matters. A partial update, failed integration, or repeated action must be detected and handled without reconstructing events from chat messages.

When several are present, a database and application workflow are usually a better fit. The first release should complete one path end to end rather than reproduce every tab and formula on day one.

Sometimes the answer is to keep the sheet

Keep it when the work is low-risk, owned, changing quickly, and easy to inspect. Keep it when the team is still learning what should become standard. Keep it when the annual cost of the workaround is lower than the cost of building and owning a system.

An integration can also extend the useful life of a sheet. A controlled import, validation step, or scheduled export may remove the expensive handoff while preserving a model people understand.

There is no prize for graduating from spreadsheets. Take one row from the file people complain about and follow it until the work is complete. If the delay comes from a missing owner or rule, moving the same fields into a custom interface will preserve the delay. Replace the sheet when its grid cannot represent the permissions, history, events, or states the work now requires.

Once those limits are visible, the decision becomes whether to configure, connect, build, or leave the process alone—not whether spreadsheets are modern enough.