Give the spreadsheet its due first
Somewhere in most companies between twenty and five hundred people there is a workbook that runs something real. Pricing. Commission. Inventory allocation. Project margin. Route planning. It has forty tabs, it was built by one person who is now doing a different job, and it is the actual system of record for a process the business depends on. When a technology firm is brought in, the first instinct is to be appalled. That instinct is wrong, and the projects that begin with it are the ones that fail.
The workbook exists because it beat every alternative on the things the business needed most. A person could change it in ninety seconds without a ticket. The logic was visible in the cells rather than hidden in a codebase. It fit a process that nobody had fully described, and it kept fitting while the process changed weekly. No software you buy or build gives you all of that. If your replacement takes those properties away and gives back only structure, the team will keep the spreadsheet running quietly beside it, and you will have paid for two systems and gained a reconciliation problem.
So the question is not whether spreadsheets are bad. The question is which specific pain you are trying to remove, and whether the removal is worth what you give up.
You are probably here because
- One person can maintain the workbook and they are going on leave, or leaving
- Someone overwrote a formula and a customer found the error before you did
- Two people need to edit it at once and the file keeps forking into copies
- An auditor, a lender or an acquirer asked how the number is produced and the answer took three days
Each of those has a different smallest fix. Two of them do not require custom software at all, and the sections below say which.
Signals it is time, and signals it is not
Concurrency. The moment more than one person needs to edit at the same time, a file-based tool starts losing work. Copies appear on desktops with names like final_v3_JS. Whichever copy gets sent to the customer becomes the truth by accident. This is the most common trigger and it is a real one.
Single-person risk. One person understands the macro. If they are unavailable during month-end close, the process stops. This is not a technology problem in itself, and it is worth noting that documentation plus a second trained person removes the risk for a fraction of the cost of a rewrite. But if the logic is genuinely too tangled to hand over, that tangle is the finding.
You cannot answer what it said before. A workbook that is edited in place has no history. When someone asks what the price list said on 1 June, or which version of the allocation rule produced the March report, there is no answer. For regulated processes, deals under diligence, or anything a customer could dispute, this is usually the argument that settles it.
Errors reach customers. A pasted column, a formula dragged one row short, a hard-coded number that stopped being true in 2024. Studies of operational spreadsheets have repeatedly found error rates high enough that any workbook of real size should be assumed to contain at least one, and the ones that matter are the silent ones that produce plausible output.
Now the signals it is not time. If one person uses the workbook and the output is checked by someone else, leave it alone. If the process itself is still being invented and changes every week, a spreadsheet is the correct tool, and freezing it into software will make you slower at exactly the wrong moment. If the workbook is slow but correct, buy a faster laptop. If the pain is that leadership dislikes how it looks in a board meeting, that is a presentation problem and costs almost nothing to solve.
How strongly each signal argues for replacing the workbook — our weighting
Our weighting, not a survey. Single-person risk scores lower than people expect because training a second person is far cheaper than a rewrite.
The rewrite that eats a year
The failure pattern is consistent enough to describe in advance. A team is assigned. They ask for requirements. Nobody has any, because the requirements are the formulas, and the formulas encode about four years of accumulated decisions nobody remembers making. So the team reads the workbook, builds what they understand, and ships in month five. On day one of the new system, operations discovers that eleven edge cases are missing. Those edge cases are not exotic, they are the actual business: the customer with the renegotiated rate, the product that ships from a different warehouse in Q4, the discount that only applies to renewals signed before a date.
Operations does the rational thing. They keep using the spreadsheet for the awkward cases and the new system for the clean ones. Now the two disagree, the reconciliation falls on the ops lead, and the project that was meant to reduce manual work has added some. Six months later somebody proposes replacing the new system.
The hard part is not the data. It is the rules with no owner.
Open any workbook of real age and you find lines like this: if the customer name is one of these seven, use rate B. If the ship date is in the last week of the quarter, apply the alternate margin. If the region field is blank, treat it as West. None of those are bugs. Each one was a decision, made once, for a reason, by someone who may or may not still work there.
When you move to software, each of those has to be either encoded as a rule or removed. And encoding it forces a question the business has been comfortably avoiding: is this still policy? Who decides? Is it seven customers or is it a category? On every migration of this type we have been part of, the schedule risk is concentrated here, not in the engineering. The build is predictable. Waiting three weeks for a decision on whether a legacy discount still applies is what moves the date.
The practical response is to inventory the exceptions before you write any code, publish them as a list of questions with names attached, and treat unanswered ones as blocking. An exception with no owner gets one of two dispositions: carried forward exactly as written and marked as inherited, or deleted with the sign-off of someone senior enough to absorb the consequence. What you must not do is let an engineer quietly guess, which is what happens when the list stays inside the estimate instead of on the wall.
The sequence that does not stop the business
The method is old and it is not clever. You replace one piece at a time, running both systems in parallel, and you never ask the business to hold still.
Replacement sequence for a business-critical workbook
Step three is the one people skip and it is the one that de-risks everything. Getting the data out of cells and into a database, while leaving the way people work untouched, is unglamorous and it delivers history, backups, concurrency and an audit trail before you have changed a single habit. If the project were cancelled after step three, you would still be materially better off, and that is a good test of whether a phase was worth doing.
Step four is where the truth comes out. Run the new calculation and the old one over the same period and compare every row, not the totals. Totals hide compensating errors. Expect differences, and expect a decent share of them to be the spreadsheet being wrong, because a workbook of any age contains at least one formula that stopped covering its range three years ago. That discovery is uncomfortable and it is the main reason parallel running gets cut for schedule. Do not cut it.
What to build, concretely
For most of these, the first version is smaller than people imagine. A table structure that matches the entities in the workbook. A screen to view and edit records with validation on the fields that matter. A record of who changed what and when. The calculation, implemented once, with tests over historical cases. A report or two. And an export to Excel.
That export is not a concession. It is a requirement. People need a spreadsheet for the last mile, for the one-off analysis, for the thing nobody anticipated, and a system that forbids it will be routed around. Give them a clean export using the same definitions the system uses, and the workbook that survives on someone's laptop is a scratch pad rather than a rival system of record. That distinction is the whole game.
| What the workbook is doing | Usually the right replacement | Rough duration |
|---|---|---|
| Tracking a list with a workflow (deals, orders, cases) | An off-the-shelf tool configured properly, not custom software | 2–6 weeks |
| Reporting and analysis over other systems | A small warehouse plus a reporting layer | 4–10 weeks |
| A calculation with company-specific rules (pricing, commission, allocation) | Custom: a database, a rules implementation, a review screen | 6–16 weeks |
| Acting as the ledger | The accounting system, properly configured. Not software you build | Varies, and involves your accountant |
| Planning and scenario modelling | Keep the spreadsheet. Feed it clean data automatically | 1–3 weeks |
| Manual bridge between two systems | An integration, plus an exception queue for what does not match | 3–8 weeks |
Sometimes the answer is a subscription, not an engineering project
If the workbook is a list with a workflow on top, there is very likely a mature product that does it for a per-seat fee, and configuring it will cost a fraction of a build and come with a vendor who maintains it. We would rather tell a company that in week one than build them something they could have rented. The case for custom work is narrow and specific: the logic is genuinely particular to your business, it is a source of advantage, and no product fits it without contortion. That case is real, it is just less common than the number of custom builds in the world suggests.
What it costs, honestly
Ranges, with the caveat that the variance is driven by the number of exceptions and the number of decision-makers, not by data volume. A single workbook with one clear owner, straightforward rules and one downstream consumer is commonly a six to ten week engagement, which at typical mid-market rates lands in the mid five figures to low six figures. A workbook that touches billing or payroll, has several stakeholders and feeds the accounting system, is a three to six month project and prices accordingly. Anything where a regulator or an auditor has an opinion adds time for evidence and testing, not for code.
Two costs get left out of nearly every budget. The first is the business time: the ops lead who knows the exceptions will spend real hours on this, and if that time is not protected the project stalls or ships wrong. Budget one to two days a week of a knowledgeable person for the duration, and say so up front. The second is the second year. Software has an ongoing cost even when nothing new is requested, because source systems change, rules change, and somebody has to be responsible. Plan on fifteen to twenty-five percent of the build cost annually, and know who owns it before you start.
Mistakes we are called in after
- A big-bang cutover at month-end, with no parallel run and no way back
- Requirements gathered from a meeting instead of from reading the formulas
- Removing the Excel export, which guarantees a shadow workbook within a month
- Rebuilding the workbook's layout screen for screen, inheriting forty tabs of accumulated habit
- Deferring the exception decisions until the build is done, when they are the build
- Migrating the history without validating it, so old errors become the new system's opening balance
- No named owner after go-live, so the first change request sits for two months and trust drains
Before you cut over
- One full business cycle has run in parallel with differences explained at the row level
- Every exception in the old workbook is either implemented or deliberately retired, in writing
- Two people have been trained, and one of them has run a cycle unaided
- The clean Excel export exists and uses the same definitions as the system
- Historic records are loaded and a sample has been checked against the old file
- There is a written rollback: what happens if week one goes badly
- A named person owns change requests, with a stated response time
- The old workbook is archived read-only, not deleted, with the date it was frozen
Bottom line
Replacing a spreadsheet is rarely a technical challenge and almost always an organizational one. The data moves easily. The rules move only as fast as someone will decide about them, and the change sticks only if the replacement gives people back the speed and the visibility they had. Read the workbook first, publish the exceptions with names on them, move the data before you move the habits, and run both side by side for a full cycle before anyone declares victory. Done that way the business never has a bad week. Done as a rewrite with a launch date, the bad week is the plan.
Frequently asked questions
Describe the process to two vendors of an established product in your category. If they can demonstrate it in a configured trial without custom development, buy. Build when the rules are genuinely specific to your business and a product would need heavy customization, which becomes an ongoing cost of its own. The mistake in both directions is expensive, so it is worth two weeks of evaluation before committing.
One complete business cycle with no unexplained differences. For most processes that is a month; for quarterly ones it is a quarter. Compare at row level rather than totals, because two errors of opposite sign will net out in a total and look like agreement.
Then reading the file is the project's first deliverable and it will take longer. Budget two to three weeks to trace the formulas, and expect to find rules whose purpose nobody can explain. Each of those needs a decision from someone senior: carry it forward as inherited, or retire it and accept the consequence. Guessing is the one option that is not available.
Usually, in small ways. Any workbook of age tends to contain at least one formula whose range stopped covering the data. Plan for the finding, decide in advance who is told and how, and restate plainly rather than quietly. It is a much smaller problem when handled openly during a migration than when discovered by a customer or an auditor afterwards.
Engineering, yes. Your operations team, no. The person who knows the exceptions will need one to two days a week for the duration, and that is the constraint that sets the schedule. Projects that assume otherwise slip, usually while waiting on answers only that person can give.