When Do Spreadsheets Mean Your Software Needs Modernizing?

There's a good chance someone on your operations team has a spreadsheet they couldn't do their job without. It might track customer payment terms, orders waiting for approval, or exceptions your software was never designed to handle.

Over time, these workarounds become part of how the business runs. Employees enter information twice, check spreadsheets before making decisions, and rely on certain people to keep everything straight. It's frustrating, time-consuming, and easy for something to get missed.

Eventually, someone asks whether it's time to replace the software. And that's a fair question. But before committing to an expensive rebuild, it's worth understanding exactly what the current system can't do and how much of the daily work has moved outside of it.

You may find that a few targeted improvements could solve problems your team has been dealing with for years.

‍

What does a spreadsheet next to your system actually tell you?

A spreadsheet next to your system is a list of things the software doesn't do, written by the people who needed it to.

These files get built because something had to get done and the software couldn't do it. By the time one has a version number in the filename, the rules inside it have been through months of real work, which is more than most requirements documents ever get.

If you ask your team what the system should do, you'll get a wish list. Their spreadsheets show what they needed badly enough to build on their own. That list is usually more useful, and it's why workarounds are a good place to start.

The catch is that a pile of files doesn't tell you much on its own. Forty spreadsheets in a shared drive might mean your system is failing, or it might mean four people prefer working in Excel. You have to sort them before they tell you anything.

‍

How do you categorize the spreadsheets your team keeps?

Sort each file by what it holds. There are really only three kinds: a calculation, a status, or a handoff.

• Calculation. The file does math your software can't. Commission splits, blended pricing, a forecast built from exports. The answer gets typed back into the system and the reasoning stays in the file.
• Status. The file tracks something the system has no field for. Which accounts have a special arrangement, which claims are waiting on a document, which orders are approved but shouldn't go out yet.
• Handoff. The file carries work between people or between systems. An export from one platform, cleaned up and loaded into the next. A list emailed to a team so they know what to work on.

Most files land in one category. The ones doing all three are worth looking at first, because a file that calculates a number, tracks what's pending, and then gets emailed to another department is carrying a whole process on its own.

Sort yours with the people who maintain them. They'll know the category right away. Write it next to each filename and count what you have.

‍

How many spreadsheets mean you need to modernize?

The number of files matters less than what kind they are, because the mix tells you what sort of work you're actually looking at.

1. Mostly calculations. Your data is fine. The reporting around it is the gap. This is usually the smallest fix, and sometimes a report builder covers it.
2. Mostly statuses. The system is missing fields and states your business actually uses. That's a data model and workflow change, and in the systems we look at it's the most common finding by a wide margin.
3. Mostly handoffs. Your systems aren't talking to each other. The work is integration, and it rarely requires touching either platform's core.
4. All three inside one process. That process has outgrown the software. Rebuild the process. The platform underneath it may be fine.

Birmingham City Council estimated £19 million for its Oracle rollout and is now forecasting £144.4 million through 2027/28. The system went live incomplete in April 2022, the custom banking reconciliation never worked properly, and the council has spent more than £5 million on manual workaround labor while the fix gets reimplemented from scratch.

That £5 million is manual work, and manual work is something you can measure before anyone quotes you a replacement. Your own files will mostly tell you whether you need a rebuild, a refactor, or something smaller.

‍

Which spreadsheets should you leave alone?

Leave the ones where a spreadsheet is the right tool, and that's more of them than you might expect.

Modeling, scenario work, and anything an analyst builds to answer one question this week belongs in Excel. Build that into an application and it gets slower to change and harder to use, and you end up paying to maintain flexibility you already had for free.

The ones worth moving share three traits: the same file gets rebuilt on a schedule, more than one person depends on it, and a mistake in it reaches a customer or a regulator. A forecast an analyst rebuilds each quarter is fine. A pricing file that three salespeople copy from, where an old number turns into a quote you have to honor, belongs in the system.

In 2025 Klarna said it was shutting down Salesforce and moving that work onto its own stack, after deciding it had bent its processes around software long enough. That's a much bigger company making the same call you're making about one pricing file.

‍

How does Big Pixel turn spreadsheets into a modernization scope?

We ask for the spreadsheets before we ask for requirements, because the files already show what the business does.

We sit with the people who maintain them, sort each one by category, and trace it back to the gap in the system that created it. It all goes into one document your team can read: what each file does, which rule it's carrying, what it would take to move that rule into the software, and what it costs you to keep it where it is.

Then we come back with a recommendation to stabilize, extend or rebuild. A room full of handoff files usually means integration work rather than a new platform, and we'll say so even when the bigger project was already in your budget.

BeaconMedaes was launching a new division and needed inventory management, asset tracking, maintenance scheduling and training in one place. No off-the-shelf product could integrate with their existing software stack or scale to fit the plan, so we built MyMedGas as a platform layered on the infrastructure they already had.

We believe that business is built on transparency and trust, and that good software is built the same way, which here means you see the file-by-file list and decide for yourself which rules are worth moving.

‍

What should you do before scoping a rebuild around spreadsheets?

Before you scope a rebuild, get a complete list of the files your business depends on and what each one is doing.

• Every file named, with its owner and how often it gets rebuilt
• A category for each one: calculation, status or handoff
• The rule each file is carrying, in a sentence
• What breaks, and for whom, if the file is wrong
• An hours estimate for the manual work, per month

That last line moves a budget conversation, and teams almost never have it ready. Ask the people maintaining the files how long they spend, and the number is usually higher than leadership expects.

Start with the single file your team would panic about losing. Sit with the person who maintains it for an hour, write down every rule inside it, and ask what the system would need to make that file unnecessary. You'll have a scoped piece of work by the end of the hour, and a fair idea of whether the rest of the list looks the same.