The shadow spreadsheet problem
The hard part of migrating off Excel isn’t the database. It’s admitting which bits of the spreadsheet were doing real work that nobody had written down anywhere else.
Most failed Excel-to-software migrations fail in the same way: the new system replicates the visible columns, ignores the institutional knowledge baked into the formulas, and the team quietly reverts to the spreadsheet within six months. Here’s how to avoid that.
The one rule that prevents most failures
Run both systems in parallel for at least one full cycle of whatever the spreadsheet was tracking. Quarterly reporting? Run both for a quarter. Annual renewals? Run both for a year. Daily bookings? Two weeks minimum.
This costs more than a hard cutover. It is also the single biggest predictor of whether the new system survives. Every "we’re going live on Monday and binning the spreadsheet on Friday" story we’ve heard ends with the spreadsheet still being used in some shadow capacity 18 months later.
The sequence we use
Phase 1: Read the spreadsheet, properly
Sit with the person who actually maintains it. Ask them to walk through every tab, every formula, every conditional-format colour. Take notes. You’ll find:
- Columns that look the same but mean different things in different rows
- Formulas that depend on the order of rows ("never sort this sheet by name, it breaks the lookup")
- Cells that are typed-over with manual values when the formula gives the wrong answer for a special case
- Hidden tabs nobody knew about
- One column that’s actually three different concepts depending on the row type
Every one of these is real business logic that has to land in the new system in some form. Skip this step and you’ll rebuild the visible columns and miss the actual rules.
Phase 2: Model the data, then negotiate
Draw the entity-relationship diagram on a whiteboard with the team. They won’t use the words "entity" or "relationship", but they’ll spot mistakes faster than any database designer.
This is where the negotiation happens. The spreadsheet had one row per tenancy with seven repair-history columns; the new system needs a separate repairs table. Walk the team through why — "this means we can store more than seven repairs without redesigning the screen" — and get their buy-in. Without it the new system will feel alien.
Phase 3: Migrate the data, twice
Once for the dry-run, once for real. The dry-run finds:
- The fifteen rows where a date is stored as text
- The eleven rows with leading or trailing spaces in the name column
- The three rows where someone typed "n/a" in a numeric field
- The duplicate primary-key candidates that suggest your model is slightly wrong
You don’t want to be discovering these on cutover day. The cleanup that happens between dry-run and real-run is half the value of the migration.
Phase 4: Run both systems
The team enters every change in both places for one cycle. Painful but invaluable. You’ll find:
- The screens you missed (the side-tab nobody mentioned but everyone uses)
- The reports the old system generated by accident that the new one doesn’t
- The print-out someone takes home every Friday that you didn’t know existed
- The minor friction points that make people prefer the old system — which compound until the new system loses
Fix these in flight. Then turn off the spreadsheet, with a small ceremony. Mark the day in the calendar. Do not delete the spreadsheet for at least six months.
Phase 5: Six-month review
Schedule a check-in. Ask: what’s slower in the new system than the old? What’s now harder to do? What did we get wrong? Fix the top three things from that list, regardless of cost. The cost of not fixing them is the team quietly losing trust in the new system.
The four ways teams get this wrong
1. Cutting over without parallel running
Already covered. It’s the biggest one.
2. Letting the migration team design the screens
The new system needs to look familiar enough that people use it without resistance. Engineers default to "clean" interfaces; users default to "the same shape as the spreadsheet they know". Compromise toward the user. The clean redesign can come later when trust is established.
3. Throwing away the historical data
"We’ll start fresh from cutover" is tempting and almost always wrong. The historical data is what makes the new system more useful than the old one — it’s the basis of every trend report, every "have we seen this before" lookup, every audit. Migrate the lot, even if the structure is messy. Clean it up later.
4. Replacing the spreadsheet with one big enterprise system
The Excel they were using did one job. If you replace it with an enterprise platform that does forty jobs (most of which they don’t want), the team will pine for the spreadsheet within a month. Replace like with like first; expand later.
The boring takeaway
Excel migrations are 80% understanding what the spreadsheet was actually doing, and 20% writing the new software. Teams that get this ratio right end up with a system that the team prefers within a quarter. Teams that get it wrong end up with two systems running in parallel forever.
If you’ve got a spreadsheet that’s holding up something important, we’ve done this twenty-odd times. The conversation usually starts with us asking to see the file and you sending us "well, it’s a bit of a mess, but…" — which is exactly the right starting point.