Replacing Spreadsheets: A Field Guide to Digital Transformation

Almost every digital-transformation project we're brought into starts the same way: a spreadsheet, or a chain of them, that has quietly become load-bearing infrastructure for a part of the business nobody designed it to run. It works, mostly, until someone leaves and takes the only working understanding of its formulas with them, or two versions of the same file start disagreeing with each other.

The instinct is to replace it with "proper software" as fast as possible. We've learned, sometimes the hard way, that the software is the easy 30% of that project.

The spreadsheet isn't the real cost

A spreadsheet is popular for a reason: it's flexible, it's visible, and everyone in the business already knows how to open one. The real cost isn't the tool — it's what grew up around it informally: a reconciliation someone does from memory every Friday, a column that means something different depending on who filled it in, an approval that happens over a phone call and is never recorded anywhere. Replace the spreadsheet without replacing that surrounding process, and you've just built a more rigid spreadsheet.

Map the workflow before you touch the software

Before we design anything, we spend time watching the actual workflow run — not the workflow as described in a kickoff meeting, but the one that happens on a busy Tuesday when something goes wrong. That usually surfaces the exceptions the eventual system has to handle gracefully: the booking that comes in after hours, the invoice that needs a manager's override, the report a regional office needs in a slightly different format than head office. A system designed only around the clean, happy-path version of the process is the one that gets abandoned first.

Nobody has ever gone back to their old spreadsheet because the new system was too capable. They go back because it didn't handle the one exception their job actually revolves around.

Migrate in phases, and keep the export button

We rarely recommend a hard cutover on a single date. Running the new system alongside the old process for a defined window — even manually double-entering data for a few weeks — costs time up front but builds the trust that makes the eventual switch stick. It's also how you catch a data-mapping mistake while the old system is still there as a safety net, instead of after it's gone.

• Start with the highest-friction, lowest-risk part of the workflow, not the whole thing at once.
• Give the team a way to export data out in a familiar format for as long as they need it — removing that safety net early is the fastest way to lose trust.
• Treat the first month of real usage as part of the build, not the "done" milestone — expect and budget for adjustments.

The most common failure mode: nobody gets trained

We've seen well-built systems fail purely on adoption, and it's almost always the same root cause: the software was handed over with a login and a one-page guide, and the team's actual working knowledge of the old process never got transferred into the new one. Training isn't a checkbox at the end of a project — it's where the real behaviour change happens, and it deserves the same planning as the technical build.