Moving off spreadsheets: how to do it without breaking everything
The decision to replace spreadsheets is usually easier than the execution. Most failed rollouts we hear about were not caused by bad software — they were caused by trying to replace everything at once, or by building around what the spreadsheet does rather than what the business needs.
Start by mapping what actually happens
Not what the process document says. What people actually do, including the workarounds nobody mentions in meetings — the sheet someone keeps privately, the WhatsApp group where scheduling really happens, the step that officially does not exist. Miss these and the new system will be rejected for not doing something nobody told you about.
Replace the worst one first
Not the biggest, and not the easiest. The one causing the most pain — usually the sheet with the most versions in circulation, or the one only one person understands. A visible win on a genuine problem buys goodwill for the rest of the project. A first phase that replaces something nobody minded costs you credibility.
Do not rebuild the spreadsheet
A common and expensive mistake: recreating the exact structure of the spreadsheet in software, including its compromises. Spreadsheets are shaped by what spreadsheets can do. Once you are not constrained by rows and columns, a lot of the design should change — proper relationships between records, real validation, status that means something. Ask what the process would look like if the spreadsheet had never existed.
Decide what happens to history
- Migrate everything: expensive, and old data is often messy enough to pollute the new system.
- Migrate the active records only: usually the right call.
- Keep the old sheets read-only as an archive: cheap, and covers the occasional lookback.
Most businesses need the last two together. Full historical migration is rarely worth what it costs.
Expect a parallel period
Run both for a few weeks. It is duplicated effort and everyone will grumble, but it is how you find the gap nobody spotted while there is still a safety net. Set a firm end date, though — parallel running that drifts becomes permanent, and then you have two systems and no single source of truth.
Train the sceptic first
Every team has someone who did not want this. Bring them in early rather than last. They will find the flaws faster than anyone, and if they end up endorsing it, adoption follows. If they are ambushed at rollout, they become the reason it fails.
Keep spreadsheets where they belong
This is not an argument for eliminating them entirely. Spreadsheets are excellent for one-off analysis, modelling and quick calculations. The problem is only when they become the system of record for an ongoing process. Move that part; keep the rest.