Digital Transformation · Technology Strategy
Moving from spreadsheets to a platform without losing the business
Spreadsheets encode real operational knowledge. A sequence for replacing them that keeps the knowledge and avoids a failed migration.
- Author
- Jordan Dias
- Published
- Last updated
- Reading time
- 6 minutes
The question this answers
A core process runs on spreadsheets and every attempt to replace them has ended in parallel running.
Key takeaways
- A spreadsheet running a core process is the most accurate specification of that process that exists — read it before designing.
- Migrations fail because the new system covers the standard path and not the exceptions.
- Sequence matters: map the process, agree the data model, replace the highest-cost step, then encode exceptions.
- Retire the spreadsheet explicitly, with a date and an owner.
The spreadsheet is documentation
A spreadsheet that runs a core process is the most accurate specification of that process in existence. Its columns, conditional formatting and manual overrides record decisions nobody wrote down. Treating it as a mess to be replaced discards that record.
Read it before designing anything. The exceptions handled by hand are usually the parts of the process that matter most and are least represented in any off-the-shelf product.
Why replacements fail
Failed migrations tend to share one cause: the new system covers the standard path and not the exceptions, so the team runs both in parallel.
Parallel running is not a transition state. It is the permanent outcome, and it costs more than the original process.
A workable sequence
Order matters more than speed here, because each step depends on the one before it.
- 01Map the process with the people who run it, including undocumented checks and manual overrides.
- 02Agree the data model, roles and permissions before any interface work.
- 03Replace the single highest-cost step and put it into real daily use.
- 04Encode the exception paths next, not last.
- 05Retire the spreadsheet explicitly, with a stated date and an owner.
Process mapping -> undocumented checks surfaced Data model + roles -> permissions decided before UI Highest-cost step -> in real daily use Exception paths -> encoded, not deferred Spreadsheet retired -> stated date, named owner
Build only what is genuinely yours
Custom software is justified when the process is a differentiator, or when no product fits without workarounds heavy enough to reintroduce the original problem. Otherwise a configured off-the-shelf tool is the better answer, and saying so early is part of the job.
Where a build is right, conventional and well-documented technology choices matter. The measure of a successful platform is that a team other than the one that built it can run and extend it.
Common questions
How long does a spreadsheet-to-platform transition usually take?
The first replaced step is normally in daily use within weeks. Full retirement of the spreadsheet depends on how many exception paths exist, and that number is only known after the process mapping.
Is off-the-shelf software always cheaper?
Not always. A configured product is cheaper when the process is conventional. Once the workarounds needed to fit the product reintroduce the manual effort you were removing, a build is the lower-cost option over the life of the system.