The workbook is called ORDERS_MASTER_FINAL_v7_ACTUAL_USE_THIS_ONE.xlsx. Carol in ops built it in 2019. It links to Dave's purchasing workbook, which links to something on the shared drive called pricing_new(2).xlsx, which links to a file nobody can find anymore. Every Monday Carol opens it, waits forty seconds, and whispers a small prayer.
It works. That's the uncomfortable part. The whole company runs through this thing, it has exactly one person of failover, and she's going on vacation in June.
This is a replace Excel spreadsheets case study in the gentle sense: how one operations manager retired 42 of 47 linked workbooks in eleven months without a single big-bang cutover. The method is boring — run the new thing next to the old thing until the old thing embarrasses itself. Boring is the point.
The empire nobody planned
No one decides to build a spreadsheet empire. It accretes. Every tab solved a real problem once: the freight surcharge tab, the tab that converts the supplier's weird date format, the tab Dave asked for in 2020 that only Dave understands. Each fix was rational. The sum is a nervous system made of cell references.
You'll know you have an empire when files carry version numbers in their names, two people can't open the same workbook at once, "the spreadsheet" means a specific one and everyone knows which, and at least one formula references a laptop belonging to someone who left in 2022.
The empire also has a finance department problem nobody budgets for: key-person risk with interest. Carol's knowledge isn't written anywhere, because the workbook is the documentation. When she takes a sick week, month-end close slips. When she took a two-week vacation last summer, the company discovered that "backup" meant Dave, and Dave's process was calling Carol's cell, which she answered from a beach, to her credit and to the company's shame.
Why big-bang rewrites die
Your first instinct is the fatal one: a nine-month project to replace everything at once. Month one is exciting. Month four, the steering committee asks why the team has nothing to show but a data model, while the spreadsheet people, who were never consulted, quietly keep the business running in the old files. Month six, the project is "paused." Month nine, it's a cautionary tale told at conferences.
What blocks it is never the technology. It's trust. The people who run the empire know where the bodies are buried: which tab double-counts freight, which report the CEO reads wrong. A system that doesn't know those things isn't an upgrade to them. It's a threat with a login page.
The shadow phase of a replace Excel spreadsheets case study
So you don't replace anything. You build the new thing next to the spreadsheet and run both. This is an illustrative composite, but a faithful one: a mid-size distributor, order tracking, one small app built in three weeks that did exactly one thing — show every open order, its status, and who touched it last.
For six weeks, Carol's workbook and the app ran side by side. The deal was explicit: the spreadsheet is the source of truth until it isn't. Twice in that window the app caught the workbook being wrong, an order edited in one tab but not the linked tab. Carol found the second one herself. That's the moment the migration actually started, because the person with the most to lose had caught the old system cheating.
The first target followed the same pattern as the invoice automation we built for a finance team drowning in PDFs: narrow, visible, and useful inside a month.
Strangling one sheet at a time
Programmers call this the strangler-fig pattern: grow the new system around the old one until the old one retires piece by piece. In plain English, pick the sheet with the most pain per user, not the most important one. Pain is the fuel.
The order in this story: first the order tracker, daily pain for ten users. Then delivery scheduling, daily pain for four. Then the freight surcharge calculator, which turned out to be twenty lines of code and one table. Eleven months later: 47 linked workbooks down to 5 survivors. No cutover weekend, no freeze, and nobody's Monday ever got worse.
Notice what didn't happen. Nobody was retrained in a conference room. Nobody got a migration email with a countdown timer. Each sheet died the same quiet way: its users drifted to the app because the app was faster, and one Monday Carol opened the workbook, saw nothing new to reconcile, and archived it herself. The best migrations are the ones the users perform on each other.
The rhythm looked a lot like the ninety-day logistics build we've written about before, small releases on the floor every week, just stretched over a year because the business couldn't absorb a harder pace.
What survives, and why that's fine
Five workbooks survived, and they deserved to. Ad-hoc analysis, the "what happens to margin if diesel hits five bucks" explorations Carol runs twice a quarter. A one-off import template used once a year. The goal was never zero Excel. That's a purity contest nobody wins.
The goal is zero single points of failure. When the answer to "what happens if Carol's laptop dies" becomes "nothing, it's all in the app," you've won, even if Excel is still open on her second monitor.
The payoff nobody pitched
Here's what nobody put in the business case. Once orders, customers, and payments lived in one place, Carol started asking questions the empire could never answer. Which customers always pay late, and do they also order the most rush freight? Which SKUs get edited after entry the most, and by whom? The spreadsheet era couldn't even see these questions.
The migration's real return wasn't the hours saved, though those were real. It was that the company got curious again. We've seen the same shift when a company's data becomes queryable for the first time: first the tools change, then the questions change, and the questions are worth more.