What replacing a spreadsheet-run operation actually costs

Every operation that runs on spreadsheets has had the same conversation internally at least twice. Someone points out that the workbook has become load-bearing. Someone else asks what it would cost to replace. A number gets quoted, everyone winces, and the workbook survives another year.

The wince is usually a response to the wrong number. The quote for building the system is rarely the part that sinks these projects. What sinks them is everything the quote does not mention, and the fact that nobody costed it because nobody named it.

Here is the rest of the bill.

The data is worse than you think

Every replacement project has a moment, usually in week two, when someone opens the historical data and discovers that a field which was supposed to be a date contains eleven different formats, three of them prose. This is not a sign of a badly run operation. It is what happens to any column that a hundred people have typed into for six years with nothing stopping them.

The cost is real and it is rarely on the quote. Somebody has to decide what "approx. mid-March" becomes. That is not a developer's decision. It is an operational one, and it needs the person who wrote it.

Budget for this explicitly. On the claims platform we build and operate, data mapping and migration was a named workstream with its own owner, not a task inside "build". The alternative is a migration that quietly rewrites your history to whatever the import script found convenient.

Parallel running is not optional, and it is expensive

For some period, your team will do the work twice: once in the new system and once in the thing that still definitively works. Everyone knows this. Almost nobody costs it.

Parallel running is the most expensive phase of the project, because it is the only one that consumes your operational team's time rather than ours. Two weeks of a 40-person team running two systems is a real number, and it belongs in the business case from the start, not as a surprise in month four.

It is also non-negotiable. The alternative is a hard cutover where the first month of live data is also the first real test, and the first real test fails in front of your customers.

The system you replace was never just the spreadsheet

This is the one that catches people.

The workbook is visible, so the workbook gets replaced. What was running the operation was the workbook plus an email folder structure, plus a naming convention on a shared drive, plus twelve slightly different Word templates, plus one person who knows which of the twelve is current.

Replace the workbook alone and you have not consolidated anything. You have added a system. The operation now runs on the new platform and the email folders and the shared drive, and the person who knew which template was current is now also the person who knows which system is authoritative.

The scope that works is the whole path a unit of work travels, end to end. That is a bigger project than replacing the spreadsheet, and it is the only version that pays.

Adoption is a design problem, not a training problem

If the new system takes eleven clicks to do what the spreadsheet did in two, your team will keep a shadow spreadsheet. They are not being difficult. They have a job to do and you have made it slower.

Training does not fix this. The only thing that fixes it is putting working software in front of the people who will use it early enough that their objections still change the design. Not a demo, but the actual thing, with their actual data, while there is still time to act on what they say.

The corollary is uncomfortable: if you cannot get your operational team's attention for a few hours a month during the build, the project is already in trouble, and no amount of budget fixes it.

The six weeks after go-live

Go-live is not the end of the project. It is the beginning of the only part that determines whether it worked.

In those six weeks you will find the workflows nobody mentioned because they were too obvious to mention, the annual process that nobody thought about because it happens in November, and the one report that a regulator requires in a format nobody documented. All of that is normal. What is not normal, and what kills a surprising number of otherwise good projects, is discovering it after the delivery team has moved on.

This is why we operate what we build rather than handing it over. Not as a service line, but because software that nobody owns degrades, and the handover is the single most reliable place for one of these projects to die.

So what does it cost?

More than the quote, and less than doing nothing for another three years, which is the comparison that matters and the one almost nobody makes.

The cost of the current system is paid daily, in small amounts, by people who have stopped noticing. Data typed twice. A report assembled by hand the night before it is due. A question that should take a second and takes a week.

Those are line items too. They are just harder to see, because nobody sends you an invoice for them.