A guide to triaging a whole spreadsheet stack, not one file: how to inventory the spreadsheets a business runs on, decide which to keep as-is, which to automate, and which to rebuild as real software, and sequence the changeover so nothing breaks.
Growing businesses where a pile of shared spreadsheets has quietly become the operating system, and it is starting to hurt.
- A clear inventory of the spreadsheets your business actually runs on
- A keep / automate / rebuild decision for each one
- A sequenced changeover that never bets the whole business
Somewhere along the way, a business stops running on software and starts running on a pile of spreadsheets, one for leads, one for projects, one for inventory, three for finance, that nobody planned and everybody depends on. Replacing them is not one migration; it is a portfolio decision. Some of those sheets are perfectly fine, some just need to stop being copied by hand, and a few have quietly become the risky core of the business. This guide is about telling which is which, and changing them over without a disaster.
Because a business does not run on one spreadsheet; it runs on a stack of them, and they are not all the same. Some hold nothing critical and are fine forever. Some are fine except for the manual copying between them. A few have become the unaudited core the business actually depends on, where a wrong number costs real money. Treating them as one big "replace all spreadsheets" project is how these efforts stall; the right move is to triage the stack and act on each sheet according to what it actually is.
The reason the all-at-once approach fails is that it is enormous, risky, and mostly unnecessary. Most of the spreadsheets in any business are harmless, and rebuilding them buys nothing. The value is concentrated in a few sheets, the ones that are load-bearing, error-prone, and copied between by hand, and finding those is the entire job. A triage tells you where to spend effort and, just as importantly, where not to.
So the first move is not to build anything. It is to look at the whole stack and sort it, because you cannot sensibly replace what you have not inventoried.
Spend a short while listing the spreadsheets the business actually depends on and, for each, capturing the few facts that decide its fate. This is a paper exercise, and it is the highest-leverage hour in the whole effort.
A logistics firm assumed it needed to "replace all the spreadsheets" and braced for a huge project. The inventory showed fourteen sheets, of which eleven were harmless and fine, two just needed the weekly copy-paste between them automated, and exactly one, the dispatch tracker everyone depended on and that broke monthly, was the real risk. The project shrank from "rebuild everything" to "rebuild one sheet, automate two seams, leave eleven alone", which is why it actually got done.
With the inventory in hand, each spreadsheet falls into one of three buckets, and the facts you captured point clearly at which.
The instinct once you decide to "get off spreadsheets" is to replace all of them, but that is almost always wrong. A spreadsheet is genuinely the best tool for a simple, low-risk, single-owner job, and rebuilding those as software adds cost and rigidity for no benefit. The win comes from rebuilding the few load-bearing sheets and automating the few manual seams, then deliberately leaving the rest alone. Restraint is part of the strategy.
Once you know which sheets to rebuild and which seams to automate, the order and the method protect you from betting the business on a big-bang cutover.
What makes this practical now is that rebuilding the few sheets that need it no longer means a developer, a budget, and a queue. You can describe the workflow behind a load-bearing spreadsheet, its records, its rules, who touches it, and get a working application the same day, then run it alongside the sheet and retire the sheet once it has earned trust. The stack that grew by accident gets replaced on purpose, one deliberate decision at a time, and you keep ownership of the software and data you build. Describe the sheets worth rebuilding and get software shaped to them, so the accidental operating system becomes one you actually chose.
Almost never all of them. A business runs on a stack of spreadsheets that are not the same: most are harmless and fine, some just need the manual copying between them automated, and a few load-bearing, error-prone ones are worth rebuilding as software. Triage the stack and act on each sheet according to what it is; restraint is part of the strategy.
Inventory each one and ask what it holds, what breaks if it is wrong tomorrow, how it connects to other sheets, and how often it already fails. Rebuild the load-bearing, error-prone, multi-person sheets where validation and permissions pay off; automate the seams where sheets are copied by hand; and keep the simple, low-risk, single-owner sheets as they are.
Riskiest first, not easiest. Rebuild the single load-bearing, error-prone sheet before the simple ones, import the real data, and run the new software alongside the sheet for a week or two as a safety net. Then automate its manual seams and move to the next. Sequential working pieces beat a big-bang cutover that breaks several processes at once.
Not anymore for most cases. You can describe the workflow behind a load-bearing spreadsheet, its records, rules, and who uses it, and get a working application the same day, run it in parallel with the sheet, and retire the sheet once it has earned trust. That is what makes triaging and replacing only the sheets that matter practical rather than a large project.