When to replace spreadsheets with software
Replace spreadsheets with software when the spreadsheet has stopped being a tool and become the system. Several people edit it, data moves between it and the inbox by hand, and only one person understands how it works. Nobody can say who changed what last month. If one person uses a spreadsheet for analysis, keep it; the trigger is shared, repeated work the business depends on.
This is for operations leads and owners at firms of 10 to 200 people in the UK and Europe. In your firm, a handful of spreadsheets, a shared inbox and one person's memory run the operation. You probably know it's fragile. You need to know whether it's fragile enough to replace, what to replace it with, and how to switch without a bad month.
We build internal software for firms like yours. Our service page promises to replace "four spreadsheets, a shared inbox, and the one person who remembers how it works". In our view, the costliest mistake comes after the decision to move: replacing the spreadsheet with a copy of itself.
Signs the work has outgrown the file
The first four signs cost time rather than headlines. Your team pays for them every week.
Nobody is sure which copy is right
"Orders_v3_final_JB.xlsx" sits in someone's inbox while the shared copy moves on without it. Two people update the same row, and the second save wins. If meetings start with agreeing which copy is current, the file has more editors than it can handle.
Co-editing in Microsoft 365 and Google Sheets fixes the attachment problem, but not the one underneath. By default, anyone who can edit one cell can edit them all.
Data is copied by hand between sheets and the inbox
An order arrives by email. Someone types it into the orders sheet, copies the total into the invoicing sheet, then pastes a line into the delivery sheet. Every copy is a chance to get it wrong, and nothing checks that the three still agree.
A risk model at JPMorgan Chase worked this way before the bank's 2012 "London Whale" trading losses. The bank's own management task force report found that the model ran on a chain of Excel spreadsheets, filled in by copying and pasting data from one to the next.
One formula divided by a sum where the modeller meant an average. The report says this likely halved the volatility the model measured, so the risk looked smaller than it was. The spreadsheet was one failure among several, but the bank's own review singled it out.
One person knows how it works
Every firm with this problem has the person. They know which tab feeds which report, why one customer has two account numbers, and which column must never be sorted. When they're on holiday, the work waits. When they leave, the knowledge leaves with them.
Owners tend to notice this sign last, because the person is usually good at their job. The trouble is where the process lives: in their head, not in anything the business owns.
Reports are rebuilt by hand
If month end takes days because someone pulls figures from four sheets, fixes the formats and pastes them into a summary, this is you. So is "give me an hour" as the answer to how many orders are late this week. When a routine question needs a pivot table, the data is in the wrong shape for the business you run now.
Signs the risk has outgrown the file
The next three are rarer and cost more. These are the ones that reach the news.
Nobody can say who changed what
A customer disputes a price: which price did you quote, who changed it, and when? Version history in Excel and Google Sheets can show that a cell changed. It can't tell you why, and it doesn't stop the change. An audit trail answers "what happened to this record" on one screen, mistakes and corrections included.
Errors turn up late, or never
Spreadsheets fail without an error message. A formula points at the wrong row, a paste overwrites a number, or the file hits a limit and drops what doesn't fit.
In October 2020, Public Health England reported that 15,841 positive Covid-19 cases from 25 September to 2 October had been left out of the daily figures. The BBC traced the cause to an old Excel file format, XLS, that holds about 65,000 rows. Each test result used several rows, so each file topped out at about 1,400 cases. Everyone who tested positive still got their result, but their cases reached the contact tracers late.
These errors are ordinary. Raymond Panko, who studied spreadsheet errors at the University of Hawaii, reviewed audits of real business spreadsheets. In the studies since 1995, auditors found errors in 94 percent of the 88 spreadsheets they checked. Two experienced UK auditors told him they had never seen a major spreadsheet without errors.
For more cases, the European Spreadsheet Risks Interest Group keeps a public archive of spreadsheet horror stories.
The wrong person can see everything
A spreadsheet controls who can open it, not who can see each row or column. Share the file and you share everything in it, including tabs you forgot were there.
In August 2023, the Police Service of Northern Ireland answered a freedom of information request about how many officers and staff it had at each rank. The spreadsheet it published still held a hidden worksheet with the surname, initials, rank and role of all 9,483 officers and staff. The Information Commissioner's Office later fined the force. When a sheet holds personal data, a sharing mistake is also a data protection breach under the UK and EU GDPR.
Software can ask two separate questions about each person: what may they change, and what may they see. A driver can record a delivery without ever seeing its invoice value. A spreadsheet can't split those two.
Count the signs that fit. One or two, and a tidier spreadsheet may be enough. Three or more, or any one of the last three, and the file is carrying more than it was built for.
When a spreadsheet is still the right tool
A spreadsheet is the best prototyping tool most firms already own. Keep it when:
- One person uses it, mostly for analysis, modelling or "what if" questions.
- The process still changes every few weeks, so you don't yet know what to build.
- It's a short-lived list, such as a one-off stock count or an event guest list.
- The data comes out of another system, and the sheet only reads it.
The second case matters most. Software holds a process in place. While you're still working out how orders should flow, a spreadsheet lets you change the process on Tuesday and try it on Wednesday. Build once the process stops moving.
Four ways out, compared
The four realistic moves differ in how well they fit your process, who can change them, and what you keep if you leave.
| Option | Good for | Watch out for | What you keep if you leave |
|---|---|---|---|
| Tidy the spreadsheet | One team, simple records, a few editors | Still one file, and the one-person risk stays | The file |
| No-code database or app builder, such as Airtable, Baserow or Microsoft Power Apps | A team that wants forms and proper records, built in-house | Per-user plans, limited permissions, logic spread across automations nobody documents | Your data as an export, not the logic |
| Off-the-shelf product, such as a CRM like HubSpot or an ERP like Odoo | Processes that work like everyone else's | You change your process to fit the product | Your data, if the export is complete |
| Custom internal tool | A process that is how you compete, or one nothing on the market fits | The longest build, and it needs an owner and upkeep after launch | Everything, if the code and accounts are in your name |
Tidying is underrated. Turn each list into an Excel table, add data validation so a date column only takes dates, and lock the formula cells. Put a Microsoft Forms or Google Forms form in front, so people add rows without touching the sheet, and keep one copy in SharePoint or Google Drive. None of this fixes the person who understands it, but it buys a small team time.
A no-code database sits in the middle. You get proper records, forms and views, and someone in your team can build it. The risk is quiet: the logic ends up spread across automations that one person set up, and you're back to the one-person problem with a nicer screen.
Off-the-shelf wins when your process is standard. If you sell the way most firms sell, a CRM such as HubSpot or Pipedrive already does the job, and other firms have found its bugs before you. Try one before you commission anything custom. We weigh the two in custom software vs off-the-shelf: when building your own pays off.
A custom tool fits when the process crosses several teams, when it's how you win work, or when every product needs heavy workarounds. If customers or suppliers need to log in too, it becomes a web application with a customer-facing side.
Rebuild the process, not the spreadsheet
The usual brief is "the same as the spreadsheet, but in a proper system". Build that and you get the same mess with a login screen. The columns become fields, the tabs become pages, and the workarounds become features.
A spreadsheet records how a process grew, one fix at a time. So don't ask what the sheet holds. Ask what the business needs to know and do each day, then build that.
The same goes for the screens. The easy version mirrors the database: stock movements, reconciliations, price reports. An owner who has run the business on paper will find those hard to read.
Build the main screens around the questions they ask every day instead: how did we do today, where is the money, and what do we have in stock. The data underneath is the same. The screens use their words instead of the developer's.
How to move without breaking the business
Five steps, in this order.
1. Map the process as it runs
Sit with the people who do the work and watch a normal week. Write down every step, including the ones that happen in the inbox, on the phone and in someone's head. We map the process end to end, then delete the steps nobody should be doing; the exceptions that remain are what the new tool must handle. It's the same rule we give for AI: don't automate a process nobody has mapped, or you automate the mess.
2. Pick one source of truth
For each kind of record, such as a customer, an order or a job, decide which system owns it. On switch-over day, the old spreadsheet becomes read-only, never a second place to edit. Two editable copies of one record are the problem you're paying to remove.
3. Migrate the data, then check it
Old spreadsheets hold the same customer spelled three ways, dates typed as text, and totals typed over formulas. Clean the data before you import it. Import into a test copy first, then reconcile row counts, totals and a sample of records with the person who knows them best.
Getting records from different sources into one shape is often the hard part. On Guidoo, a travel platform we built, the hard part wasn't the booking flow. It was making holiday packages from different agencies comparable. Guidoo is a customer-facing platform rather than an internal tool, but the lesson carries over: agree what a record is before you move a single row.
4. Keep an audit trail from day one
Store what happened, not only the result. When stock moves, record who moved it, from where, when and why, and let the count be the sum of those entries. A correction becomes a new entry that points at the mistake, so both stay on the record. Nobody can quietly edit a number away, and "why is this figure wrong?" has an answer.
5. Train the people who use it all day
The people who use the tool all day decide whether it works, so involve them from the first sketch. Build for the devices they have: a driver on a phone with a patchy signal needs a tool that works offline and syncs later. Train people on their own busiest tasks, with their own data.
Then watch for shadow spreadsheets. If someone keeps a sheet next to the new tool, the tool is missing something they need. Find out what, and fix it. Finish with handover documentation your own team can act on, so the new tool doesn't become the next thing only one person understands.
Start with a list of your spreadsheets
This week, list every spreadsheet that more than one person edits. For each one, note who keeps it, where its data gets copied to, and what happens when its keeper is on holiday. Score it against the seven signs.
Most firms find one or two files carrying far more weight than the rest. Start there. If the answer is a tidier spreadsheet, you've saved yourself a project. If it's software, you have the start of a brief: the process, the owner, and the questions the new tool has to answer.
Questions
Can we still use Excel for reports after we move?
Yes, and many teams should. What changes is the direction the data flows. The new system holds the records, and Excel reads from it through an export or a live connection, so nobody types figures back into the sheet. Analysis in Excel is fine. Editing the records in Excel is the habit you are moving away from.
What happens to our data if we stop working with the builder?
With us, you keep everything. The code, the database, the hosting and the documentation sit in your company's own accounts and are yours at handover. Ask any builder the same question before you sign, and get the answer in writing. For no-code and off-the-shelf tools, check that you can export every record in a standard format such as CSV.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.