When to replace a spreadsheet with software

I've seen an uptick in the number of searches and enquiries about replacing spreadsheets. We've just done it ourselves, replacing the Google Sheet that had served as Si Novi's CRM since the business started with a web application we built this summer. So why now, when businesses have been outgrowing spreadsheets for about as long as spreadsheets have existed? I think there are a few factors at play, and one of them is agentic AI.

Most of what makes a spreadsheet worth replacing hasn't changed at all, and those reasons are worth going through first. What has changed is what the data is worth once it's out of the matrix and somewhere a machine can reach it.

The signals it's time

These are the ones I'd go looking for:

• Only one person really understands it. The formulas encode business rules that are written down nowhere else, and when that person is on holiday nobody else can safely change so much as a column width.
• Somebody is retyping its output somewhere else. Figures going from the sheet into the accounting system, or into a customer record, by hand. That retyping is both an ongoing cost and a reliable source of mistakes.
• The permissions are all or nothing. Anyone who can see the sheet can edit all of it, including the columns they have no business touching, and a stray sort can quietly scramble the lot.
• There are hand-edits nobody can explain. Cells overridden by hand, exceptions applied outside the formulas, and workarounds that made perfect sense to whoever applied them at the time. These are the rules of the business too, they just never got written down.
• It needs to talk to something it can't reach. A supplier's system, a partner's pipeline, an AI workflow that needs the data structured and available rather than sitting in a grid.

One of these on its own is rarely enough to justify a build. Three or four together usually means the business is already carrying the cost of the spreadsheet, in admin time and in the occasional expensive mistake, and just isn't counting it anywhere.

Opening up spreadsheet data to agentic AI

This is the part that has genuinely changed, and it's why some of these projects are worth doing now that weren't a couple of years ago. Years of quotes, jobs, prices, customers and decisions are exactly the context a model needs to be any use, and a business that has kept a spreadsheet running for a decade is sitting on a record of how it actually works, whether it meant to or not. Getting that record somewhere structured and reachable is the prerequisite, and it's precisely what replacing the spreadsheet gives you.

Answering questions from the data is the obvious first use and the least interesting one. What I'd be weighing up is the work an agent can take on once it can both read and write: the document handling that turns invoices and delivery notes into records, the reconciliation that flags the handful of rows that don't line up, and the multi-step chase-ups where a person only approves the things that touch a customer or a payment. Si Novi's bookkeeping already runs this way, and it was the same reasoning that pushed our CRM off Sheets. There's more on where these tools earn their keep in AI automation for business.

The fair question this raises is where the data ends up, and whose model reads it. These systems can be built so the models run under your own accounts with nothing retained or used to train anyone else's product, and I'd treat that as a requirement rather than something to find out about afterwards.

The signals it isn't

Plenty of spreadsheets are getting on with their jobs perfectly happily and should be left exactly where they are, and it's worth knowing which. If the volume is low and not growing, if one person owns it and nobody else depends on it, and if nothing else in the business needs the data, then a workbook is the right tool and replacing it buys nothing.

The other case for leaving well alone is a process whose shape is still changing month to month. Restructuring a spreadsheet takes minutes and restructuring an application takes rather longer, so while the process is still being worked out, that flexibility is genuinely valuable. Wait until it settles. And before any of this, it's worth checking whether an off-the-shelf product already does the job, because low-code tools and the small subscription products that now exist for most common processes cover a lot of ground for a fraction of the cost of building.

Why we replaced our own CRM spreadsheet

We ran Si Novi's enquiries and new business on a Google Sheet from the day the business started in 2018, and iterated on it for eight years. It was shared, it had a version history, everyone who needed it was in it, and for a small consultancy tracking a manageable number of conversations it did the job perfectly well for the best part of a decade.

What changed in 2026 was our agentic AI operations work, where we wanted the enquiry and new business data available to the same kind of workflows we'd already built for our bookkeeping, and the AWS Partner Network, where we wanted our opportunities going into the APN pipeline properly rather than being maintained in two places.

Those two pulled in different directions on the decision. We could have reached the first with a Google Drive hookup and left the sheet where it was, which would have been considerably less work. The APN integration was the one that settled it, because that needed a bespoke build regardless of where the data lived. Given that building web-based CRM, sales and quoting systems is a lot of what we do for clients, investing the internal time and building our own platform was a natural call.

What you actually gain

The gains worth counting are the ones you can point at afterwards. Structured, validated fields stop a whole category of mistake from happening at all, rather than catching it in a review later. An API connection to the accounting or CRM system removes the retyping, which is usually the largest single block of admin time in any of these processes. Proper user accounts mean different people get different levels of access, and every change carries a record of who made it and when, so the question of why a figure looks wrong stops being an archaeology exercise.

What it costs, and how long

What it costs to run one of these is no longer the interesting number, because serverless and managed cloud services mean a small internal application needs no server of its own and nobody to patch it, and it can cost pennies a month to operate, which I've written about at more length in digital transformation in the AI era. The build is the investment, and it should be sized honestly against what the process is actually worth: the hours going into it now, the cost of the mistakes it produces, and whatever it's currently preventing the business from doing.

For a single process, a first useful version is usually a few weeks of work rather than months, because the specification already exists. The timescales stretch when the scope quietly grows from one process to all of them.

Where to start

Start with the spreadsheet itself, because it's the specification. Its columns are the data model, its formulas are the business rules, and the business has already proved it needs the thing by running on it for years. The hand-edited cells, the overrides and the workarounds are where the careful work is, because those are the rules nobody wrote down, and an application that doesn't accommodate them gets abandoned in favour of a brand new spreadsheet within a month.

There's more on what these projects look like once the decision has been made, and on how AI has changed what the data in these spreadsheets is worth, in replacing Excel spreadsheets with web applications.