When the spreadsheet is the system
Somewhere in your company there's a file that runs a process that matters, and one person who understands it. Don't delete it. Read it.
Every operation past a certain age has one. A spreadsheet, owned by one person, that quietly runs something important: the forecast, the queue assignments, the billing reconciliation, the compliance tracker. It has tabs nobody else opens. It has formulas with hardcoded exceptions. When its owner goes on vacation, the process goes on vacation.
The standard reaction, from consultants and software vendors alike, is contempt. The spreadsheet is "shadow IT," a risk, an embarrassment to be replaced with a real system as fast as possible. The owner gets treated as a problem too: a hoarder of process, a single point of failure.
This gets the situation exactly backwards.
In defense of the spreadsheet's owner
That spreadsheet exists because somebody had a real operational problem and the official tools couldn't solve it. Its owner did what good operators do: they built the thing that worked. Every weird hardcoded exception in that file is a fact about your business that some system of record failed to capture. The VLOOKUP chain that makes everyone wince encodes a decision rule that took years of mistakes to learn.
The spreadsheet isn't the problem. The spreadsheet is the spec.
This is the single most useful reframe I know for these situations. Companies pay enormous money for requirements-gathering, for workshops, for process documentation that's out of date before the binder closes. Meanwhile the spreadsheet is a live, executable, battle-tested description of how the process actually works, including all the exceptions the official documentation doesn't know about. It's the best spec you will ever get. It's just written in a language, one person's Excel dialect, that nothing else can read.
Why the rewrite from hell happens
The classic failure is to commission a real system from scratch and design it from the official process documentation instead of from the file. The new system launches, it can't handle the cases the spreadsheet handled, the owner quietly keeps the spreadsheet going in parallel because the work still has to get done, and eighteen months later the company is running both. Now there are two systems, the expensive one that's wrong and the embarrassing one that's right.
The failure wasn't in building. It was in skipping the translation step. Nobody ever read the spec.
How to actually extract it
The path that works is slower at the start and much faster overall.
First, read the file like a forensic accountant. Every formula, every hidden tab, every manual step the owner performs that isn't even in the file. This is where LLMs have quietly changed the economics: explaining what a gnarly formula does, tracing dependencies across tabs, and turning a sheet's implicit logic into explicit written rules used to be weeks of tedium. It's now days. The judgment calls still need a human, but the excavation doesn't.
Second, write down what you found and have the owner correct it. This step does two things at once. It produces the real spec, and it converts the owner from the person being replaced into the chief authority on the new system, which is both fair and tactically necessary. They know where the bodies are buried. You want them naming the edge cases before launch, not after.
Third, replace by absorption rather than decree. The new system takes over one function while the spreadsheet keeps doing the rest, then the next function, with outputs reconciled against the file at every step. The spreadsheet is the test suite. When the new system has matched it long enough, retire it. Nobody has to take a leap of faith, because nothing launches until it provably does what the old file did.
The payoff
Done this way, the process stops living in one person's head, which protects the company. The owner stops being a hostage to their own creation, which usually comes as a relief once it's clear they're being promoted to authority rather than replaced. And the new system inherits years of encoded judgment instead of relearning it through production failures.
The spreadsheet was never the embarrassment. Ignoring what it knew was.