Use case
Replacing the spreadsheet the business runs on
The spreadsheet works, nobody dares restructure it, and one person understands it. Here is how that gets replaced without losing what made it useful.
The situation
Almost every established business has one. A spreadsheet that started as somebody’s personal tracker and became the system of record for scheduling, pricing, stock or project delivery. It has grown macros, colour conventions and a tab nobody understands, and the business genuinely depends on it.
It is easy to treat this as a failure of discipline. It is usually the opposite: someone solved a real problem with the tool available, and the spreadsheet survived because it was flexible enough to keep matching the process as the process changed. That flexibility is the thing most replacement projects destroy.
The risk is concentration. One person understands it, one corrupted file loses it, and there is no audit trail of who changed what. The question is not whether to replace it but how to do so without producing something more rigid than what it replaced.
How it shows up
- One person is the only one who can safely edit it.
- It has been copied rather than versioned, and several copies are in circulation.
- Nobody can say who changed a figure or when.
- New staff take weeks to learn its conventions.
- It breaks when two people open it at once.
- Reporting means manually copying values into another sheet.
Symptom, cause and change
The most expensive mistake in this situation is treating a symptom as a diagnosis. These are the three columns kept apart.
Why it happens
- It solved a real problem quickly
- The spreadsheet existed because the alternative was waiting six months for a system. That was frequently the right call at the time.
- Off-the-shelf products did not fit
- The process is specific enough that configuring a product meant fighting it, so nobody did.
- It grew rather than being designed
- Each addition was reasonable in isolation. The accumulation is what became unmanageable.
- Nobody owned the decision to replace it
- Replacing it is nobody’s job, and it keeps working just well enough that it never becomes urgent.
- Previous attempts produced something worse
- A rigid system that could not accommodate exceptions got abandoned, and the spreadsheet came back.
How we approach it
Understand what it actually does
We work through the spreadsheet with the person who maintains it, including the parts that look like mistakes. Unusual handling in a spreadsheet is almost always encoding a real exception, and a replacement that does not handle it will be worked around.
Separate the process from the accretion
Some of what the spreadsheet does is essential and some is habit. Distinguishing them is the difference between replacing a process and rebuilding a mess in a more expensive tool.
Decide honestly whether to build
Frequently a configured product plus some integration covers it, and we will say so. Custom build is justified when the process is genuinely specific or licensing at your headcount exceeds build cost.
Model the data properly
Entities, relationships and lifecycle states designed for change. Spreadsheets are infinitely flexible; a replacement has to be deliberately flexible in the right places or it becomes the rigid system that gets abandoned.
Build a thin slice and run in parallel
One complete path through the system, used alongside the spreadsheet for a period. Parallel running is the only reliable way to find the cases nobody mentioned.
Migrate and retire deliberately
Data migrated with verified counts, the spreadsheet made read-only rather than deleted, and a defined date after which it is gone.
What changes
- More than one person can operate it
- The concentration risk that made this urgent is removed.
- Changes are attributable
- An audit trail of who changed what and when, which spreadsheets fundamentally cannot provide.
- Several people can work simultaneously
- Without file locking, copies in circulation or overwritten changes.
- Reporting stops being manual
- Values read directly rather than copied between sheets each month.
- Exceptions still work
- The unusual cases the spreadsheet handled are handled, which is what makes the replacement stick.
- It can evolve
- A data model designed for change rather than for the requirement as it stood on launch day.
Where it goes wrong
The most common failure is building something more rigid than the spreadsheet. Spreadsheets accommodate exceptions effortlessly, and a replacement that forces every case through one path will be abandoned in favour of a side spreadsheet within months — which leaves you with both systems.
The second is not talking to the person who maintains it. They know the exceptions, and they frequently feel the project is a judgement on their work. Bringing them in as the domain expert rather than treating the spreadsheet as a problem to be solved around them changes both the outcome and the adoption.
The third is migrating everything. Spreadsheets accumulate years of dead rows, and migrating them wholesale carries the mess forward. Deciding what is worth bringing is a business decision that should happen before the technical migration.
A fourth is skipping parallel running. There is always a case nobody mentioned, and it surfaces in the first month of live use. Running both for a period costs a little duplicated effort and prevents the failure that discredits the whole project.
A fifth is over-building. The replacement should do what the spreadsheet does, well, with room to grow. Projects that use the opportunity to add every deferred wish overrun and deliver something nobody asked for.
Finally, retiring the spreadsheet properly. If it stays editable, it stays in use, and the business ends up maintaining two systems. Read-only with a firm end date is the only version of this that works.
What else you could do instead
Replacing it is not automatically the right answer, and these are the options we would compare it against before recommending a build.
- Leave it and manage the risk
- Version control, scheduled backups, a documented handover and a second trained person address most of the concentration risk at almost no cost. If the spreadsheet genuinely works, this is frequently the correct answer.
- Move the data, keep the interface
- Put the data in a proper database with an audit trail while retaining a spreadsheet-like front end. This removes concurrency and traceability problems at a fraction of the cost of a full replacement.
- Configure an off-the-shelf product
- Where the process is less unusual than it feels, a product plus some integration covers it. Cheaper, faster and someone else maintains it — and this is the answer more often than clients expect.
- Automate around it
- Leave the spreadsheet in place and automate the manual work feeding into and out of it. A partial fix that sometimes captures most of the available benefit.
How we would know it worked
The measures worth capturing before anything changes are the ones this situation is really about: how many people can safely operate the process, how long it takes to complete a typical cycle, and how often errors are found downstream. All three are recordable in an afternoon and none of them usually is.
After replacement we compare against those baselines directly. Where no baseline was captured we say the improvement is unmeasured rather than estimating one, because a retrospective estimate of how long something used to take is not evidence.
The measure that matters most is whether a side spreadsheet appears. If people start keeping a parallel sheet for the cases the new system handles badly, the replacement has failed regardless of what any other number says, and we check for it deliberately at ninety days.
How long it takes and what it costs
A focused replacement for a single process typically runs eight to sixteen weeks from first session to parallel running, with the variation driven almost entirely by how many exceptions the spreadsheet encodes rather than by build complexity.
Where a configured product fits, it can be considerably shorter — four to eight weeks including data migration and training. We establish which situation you are in during the first phase, and we would rather reach the cheaper conclusion.
Cost is quoted per phase after we have seen the spreadsheet. We do not quote before that, because the difference between a straightforward process and one with fifteen encoded exceptions is an order of magnitude and no honest estimate spans it.
Estimates are labelled as estimates. Timelines here are planning ranges from comparable work, not commitments, and not measured client outcomes. We quote against a defined scope after a discovery call.
Services involved
Custom Software & Platforms
Building the system when nothing off the shelf fits — and telling you honestly when something off the shelf does.
Read more →Business Process Automation
Removing the manual steps between systems — the copying, re-typing, chasing and exporting that consumes hours nobody counts.
Read more →Systems Integration
Making the systems you already pay for talk to each other, reliably, without a person in the middle re-typing things.
Read more →Data Engineering & BI
Getting numbers out of the systems that hold them, into one place, in a state somebody can actually make a decision from.
Read more →CRM & Sales Systems
The system of record for revenue: where leads land, how they are routed, what happens next, and whether anyone can see the truth of the pipeline.
Read more →Digital Transformation Consulting
Working out what to do, in what order, before anyone spends money building it.
Read more →Questions
Is our spreadsheet really a problem?
Not necessarily. If it works, one person is not a single point of failure, and it is versioned and backed up, it may be entirely adequate. The problems are concentration risk, lack of audit trail and the inability to work concurrently. If none apply, keep it.
Will we lose the flexibility?
That is the main risk and the thing we design against. A replacement that cannot handle the exceptions the spreadsheet handled will be abandoned. It is why we spend the first phase on the unusual cases rather than the obvious ones.
Should we buy a product or build?
Buy, usually. Off-the-shelf covers most processes, and a custom build means owning maintenance forever. Building is justified when the process is genuinely unusual or licensing at your headcount exceeds build cost — and we will tell you which you are in.
What does it cost?
Quoted per phase after we have seen the spreadsheet. Estimating before that is guessing, because the number of encoded exceptions moves the figure by an order of magnitude.
How long does it take?
Typically eight to sixteen weeks for a custom replacement, four to eight where a configured product fits. Exception handling drives the variation, not build complexity.
What about the data already in it?
Migrated with verified counts, after a business decision about what is worth carrying. Spreadsheets accumulate years of dead rows and migrating them wholesale carries the mess forward.
What if the person who maintains it leaves during the project?
It is a genuine risk and a reason to start sooner. We document the process as we go specifically so the knowledge stops living in one head at the earliest possible point.
Do we have to stop using the spreadsheet immediately?
No, and you should not. Parallel running for a period is how the unmentioned cases surface. What matters is a firm end date, because a spreadsheet that stays editable stays in use.
Could we just move it to a database and keep the interface?
Sometimes, and it is worth considering. Where the spreadsheet interface genuinely suits the work, moving the data underneath it into a proper store with an audit trail can solve most of the risk at a fraction of the cost.
Other situations
Recognise this?
Tell us what it looks like in your business. We will tell you what we would do about it, and whether it is worth doing.
Get in touch