How We Turn Spreadsheets Into a System

Your spreadsheet is a specification

The sheet that runs your business contains years of accumulated rules: the discount that applies to one customer, the rounding a particular supplier requires, the column that is only filled in when something unusual happened.

None of it is documented anywhere else. So the first thing we do is read the workbook properly — every formula, every conditional format, every named range — and write out the rules in English. That document is frequently the first time anyone has seen the business's actual logic in one place.

We once found a pricing rule embedded in a nested IF eleven levels deep. Nobody in the company could state it out loud, and everyone had been relying on it for six years.

What to keep as a spreadsheet

Not everything should become software. Spreadsheets are genuinely excellent at some things, and replacing those makes the business worse.

• One-off analysis — nobody wants a build for a question asked once
• Modelling and scenario work, where flexibility is the point
• Anything a single person uses and changes weekly
• Exports for accountants and auditors, who want spreadsheets

The ones to replace are shared, repeated and load-bearing: multiple people, the same process every week, and something breaks if it is wrong.

The parallel run, not the big bang

We never switch a business off a spreadsheet on a Monday morning. The new system runs alongside the sheet for two to four weeks, both fed with the same data, and we compare the outputs daily.

Every discrepancy is a finding. Roughly nine in ten turn out to be an undocumented rule in the sheet, and the tenth is a genuine bug in the new system. Either way you learn it while the safety net is still in place.

1. Week 1: system live, sheet still authoritative, differences investigated daily
2. Week 2: system authoritative for new work, sheet kept as a check
3. Week 3: sheet read-only
4. Week 4: sheet archived, with a copy kept indefinitely

Migrating the history

The question is not how to move the data but how much of it to move. Twelve years of history in a workbook is rarely twelve years of usable data — the columns changed in 2019, someone reused a field for a different purpose in 2021, and the first three years are in a different file entirely.

We usually migrate two to three years cleanly and archive the rest as a read-only export. Perfect historical fidelity is expensive and, in our experience, almost never used after the first month.

Keeping the flexibility people actually valued

The most common complaint after a spreadsheet-to-software move is that people can no longer do the odd thing they used to. They cannot add a column for a one-off, cannot leave a field blank, cannot type a note in the margin.

So we build those affordances in deliberately: a free-text note on every record, a way to flag an exception rather than being blocked by validation, and an export to spreadsheet for anyone who wants to do their own analysis. A system that forbids what the sheet allowed will be routed around within a month.

What changes for the people doing the work

Less than they fear, if it is done properly. The first version should look recognisably like the process they know, not like a different job. Ambitious redesign belongs in phase two, once the system is trusted.

The change that matters is the one they notice within a week: they stop re-typing, the numbers stop disagreeing, and nobody has to ask whether they are looking at the latest version of the file.

Frequently asked questions