Excel to web app: when to rebuild vs when to patch

A spreadsheet that runs part of the business can be the cheapest, fastest, most reliable system in the building. The question is when patching it stops paying off. The signal is usually one of three things: the formulas fail an audit you cannot avoid, two people have started keeping their own copy, or the person who built it is no longer there. When one of those happens, patching stops paying off and the maths shifts toward a rebuild.

Why most spreadsheets do not need replacing

An accounting firm runs quotes through a nine-tab Excel file. A wealth practice tracks referrer commissions in a shared Google Sheet. Both work fine. Replacing them with a custom web app is sometimes the wrong call.

Most spreadsheets do four things well. They put the data and the calculation in one place. They give the operator full visibility into how a number was produced. They survive the disappearance of the original author longer than most code does. And they cost almost nothing to run.

Software vendors will tell you to replace them anyway. Their incentive is not your incentive. We have walked into firms where someone just replaced a stable Excel quoting tool with a SaaS quoting tool and watched the team lose six weeks of throughput rebuilding the formulas inside the new system’s “custom field” sandbox.

Patching a spreadsheet is the right answer most of the time.

The three signals that change the maths

There are three signals that the patching path has stopped being economical. We see them in roughly this order, and the order matters because each one compounds the others.

The formulas fail an audit you cannot avoid. A bookkeeper at an accounting firm runs the year-end audit and finds the depreciation schedule has been wrong for three quarters because two cells reference an outdated tax rate. A law firm’s practice manager runs the trust account three-way reconciliation and the workbook drops a matter because a SUMIF range was hard-coded to last year’s row count. The audit is the forcing function. After the second audit failure, “we’ll be more careful next time” stops being credible.

Two people have started keeping their own copy. This one creeps up. The original spreadsheet lives on a shared drive. A second version appears, named “[NAME]‘s working copy.” Then a third, named “[NAME] - DO NOT EDIT.” Then a fourth, with two underscores and the year. The naming is the symptom. The cost is that nobody can tell you which copy the firm is operating from. The people creating private copies are not being difficult. They have a workflow that the shared file no longer supports. They are routing around the bottleneck. When the team is large enough that two people independently make this call, the spreadsheet has hit its limit.

The person who built it is no longer there. The most expensive of the three. A spreadsheet that ran the business for nine years suddenly cannot be modified because the only person who understood the macro layer left in November. We have inherited workbooks where the original creator’s name is still on the sharing list eighteen months after they retired, because no one is willing to remove it in case some script breaks.

When two of these signals fire at once, the maths have shifted. Patching gets more expensive every quarter. Rebuilding starts to look cheaper inside three years.

What “patch the spreadsheet” actually means

If patching is still the right answer, the work has a shape. It is not “be more careful with the formulas.” It is closer to applied governance.

Three things make a spreadsheet patchable for another two or three years. First, the formulas get a single source of truth. If the same calculation lives in seventeen cells, it gets refactored into one named range or one helper column, and the seventeen cells reference the one. Second, the tabs get a hierarchy. Inputs separate from calculations separate from outputs. Hidden tabs are documented. Macros get a comment block at the top. Third, ownership is named on the file. One person owns the calculation layer. Another owns the data load. A third owns the report generation. The owners are written into the file.

This is boring work. It does not feel like progress. It is cheaper than rebuilding, which is the entire point.

We have done this with firms that came in expecting a six-figure custom build and left with a one-week refactor and a written change log. Six months later the spreadsheet is still working and the firm has saved a year of disruption. We are happy to send those clients home. The honest answer is the cheapest answer that holds.

What “rebuild as a web app” looks like at three sizes

When patching has run out, the rebuild has three sizes. The right size depends on how many of the three signals fired and how big the firm is.

Small (around 80 to 150 hours). The spreadsheet’s logic survives. We extract the calculation engine into a database, put a thin web interface on top, and wire one or two integrations to the systems the spreadsheet was already exporting to. The team’s daily workflow does not change much. The audit trail does. This is the right size when the spreadsheet is doing one well-understood thing (quoting, time tracking, commission allocation) and the firm is twenty to forty people.

Medium (around 300 to 500 hours). The spreadsheet was actually three or four spreadsheets stitched together by manual copy-paste. The rebuild collapses them into one model with role-based access, an approval workflow, and reporting that previously required a Friday afternoon of stitching. This is the right size when the spreadsheet has become the system of record for more than one team, and when its limits are now blocking new hires.

Full rebuild (1,000 hours or more). The spreadsheet was a stand-in for a custom CRM, a custom LMS, or a custom operations dashboard. At this point the work is not a spreadsheet replacement. It is a new product. We are honest about this with prospects. If the underlying problem is “we never built the CRM” or “we never built the practice management system,” calling the project a spreadsheet rebuild is misleading. We rename the project so the budget conversation matches the actual scope.

The migration that we ran for a thirty to fifty person manufacturer is published as a manufacturer quote-rebuild case study. Six competing copies of a quoting spreadsheet became one database-backed quoting system. The detail in the case study explains why we always start with the data model rather than the interface.

The migration sequence that keeps the firm running

The single most expensive way to rebuild a spreadsheet is to send the team home for two months while the new system is built. The single cheapest way is to keep the spreadsheet running until the new system has been used for one full reporting cycle in parallel.

The sequence we run looks like this.

Week one is the data audit. We map every input, every calculation, every output, and every place the spreadsheet hands data to another system. The deliverable is a written model of the spreadsheet, in plain language, with the named owner of each layer. Most firms have never seen this written down. The audit alone catches three or four formulas that nobody knew were broken.

Week two through four is the database build. The data model gets translated into tables with constraints. Test data goes through every calculation path. The output of the database has to match the output of the spreadsheet to the cent before we move to the interface.

Week four through eight is the interface. Read-only first. The team can see the new system but cannot edit it. The spreadsheet is still the source of truth. They look at both, side by side, and tell us where the new system’s numbers do not match their expectation.

Week eight through twelve is parallel running. The team starts using the new system for new transactions. The spreadsheet is still updated for the same transactions. The two run side by side for one full reporting cycle, usually a calendar month or a quarter end. Mismatches are investigated. Almost always the spreadsheet was the one that was wrong.

Week twelve onwards, the spreadsheet becomes the historical archive. The team has stopped opening it. Read-only export to the new system has been verified. The macros are documented in case anyone has to look up something pre-cutover.

This sequence costs more in elapsed time than a hard cutover. It costs less in disruption, retraining, and recovered errors. We have not seen a hard cutover work cleanly on a spreadsheet that was running anything important. The parallel-run sequence is one of the patterns we have settled on across enough engagements that we recommend it by default.

The diagnostic call is worth having before the rebuild decision is made. If the spreadsheet is patchable, we will tell you so. If the rebuild is the right call, we will be specific about which size. The Excel to web app page describes the engagement model. If the spreadsheet turns out to have been a client or adviser CRM in disguise, that conversation has its own shape.