When the honest answer is the full overhaul.

Most shops should climb the ladder one rung at a time. Sometimes the floor underneath is failing. What a full rebuild actually looks like from the inside — the data archaeology, the replay of 268,861 historical builds, and a go-live that has to be earned — told from one in progress.

This series has argued, rung by rung, that most shops shouldn't rebuild anything: measure first, patch the office, get the floor telling the truth, automate the handoffs one at a time. That's still the argument. This post is about the exception, because the exception is real and because "we rarely recommend it" lands better when you've seen what one looks like.

We've written separately about choosing between stabilizing a failing system, moving to a package, and rebuilding. This is what the third path actually involves for one manufacturer. Details are anonymized; the numbers are real.

The starting point

A decades-old make-to-order manufacturer. The business ran on a SQL Server from 2012 — past end of life — with a Microsoft Access front end installed machine by machine on each workstation. That system was the shop: quoting, pricing, order entry, production, all of it.

A previous rewrite had stalled at "ninety percent" and never shipped. The original developer was gone. There was no documentation of any kind. The first database backup we located was corrupt — every byte zero. And the system had started failing in production, which is usually what makes a shop call someone like us about a system like this.

This is what "the floor underneath is failing" means. You can't measure a station, patch the PO flow, or add floor scanning onto a database that might not come back up tomorrow. Every step in this series assumes a system that will still be there tomorrow.

Step one: data archaeology, not design

The instinct in a rebuild is to start designing the new thing. We didn't write a line of the new system until the old one was understood. The first job was to recover the truth about the old one, because the old one — undocumented, unloved, failing — was still the only complete specification of how the business worked. It was a spec written in data.

So we excavated:

  • Restored a years-old database backup in an isolated sandbox (Docker), where it couldn't hurt anything, and read it like an archaeologist reads a dig.
  • Took apart (decompiled) the stalled rewrite — not to use it, but to recover the logic its author had understood and never shipped.
  • Reconstructed the complete pricing model as an explicit, versioned rules engine: every upcharge, every exception, every "if it's this material and that size, add this" that had lived inside forms and formulas for years.

Then the step that made the rest trustworthy: we replayed 268,861 historical product builds through the new rules engine and compared the results against the shop's own historical numbers. Every disagreement was a question. Most were our mistakes. One was not — the replay caught a real formula discrepancy that the owner's own corrected worksheet had wrong, and it was settled by the evidence of more than 400,000 real records rather than by anyone's memory.

The rule we worked under, and still do: where the legacy code and the accepted business numbers disagree, the numbers your customers actually paid win.

Step two: the rebuild, in slices

With the rules recovered, the new system was built the way everything in this series is built — one working slice at a time, in the order that paid fastest, each one deployed to a web address the shop could click. Order entry shaped like their product, not a generic form. The reconstructed pricing engine, editable by the shop rather than hardcoded. A real-time 3D product designer inside the order. Production boards with barcode tracking across eleven departments — Part 4's floor truth, built in from the start. Customer analytics. QuickBooks integration. Passkey login (sign-in without passwords). An audit trail on every single write, enforced by automated tests.

Roughly 64,000 lines of code, 51 database tables, 95 automated test files. The legacy system had none of the last one.

That list looks like a big bang. It wasn't. It was a sequence of two-week sprints, each with its number, each deployed, each reviewed against dated before/after evidence. The full system is what the ladder looks like when you climb every rung in one engagement because there was no choice — but you still climb it one rung at a time.

Step three: earning the go-live

The new system is in parallel testing against the live one: both run side by side, and the shop compares them. Into it went 43,679 historical orders and roughly 2,600 customers. It is not in production yet: the shop still runs on its existing Access system, and no customer-facing email goes out from the new one until go-live. Go-live is targeted for November 2026.

The legacy system stays up while the new one runs alongside it, while the shop compares, while the replay results are reconciled, until the new system has earned the switch rather than been declared ready. The first rule of a rescue is that the factory never stops shipping, and the way to keep that rule is to not switch until the evidence says so.

When this is the right answer

Rarely, and for recognizable reasons:

  • The old system is the business — it encodes years of how the shop actually prices, routes, and ships — and no package comes close.
  • Nobody can fix it. The developer is gone, the documentation never existed, and it's failing.
  • The alternative is a forced migration to a generic system that would throw those years away.

If one of those isn't true, the ladder is the better fit, and we'll say so on the first call. Two of the three paths out of a failing system don't involve hiring anyone like us, and that's still the case here.

What it costs, in shape

Discovery first — $5,000 and about a week to take the old system apart and come back with a written plan, which the shop keeps whether they continue or not. Then the work splits two ways.

A rescue — replacing the piece that hurts — is the small engagement: two-week sprints, each priced before it starts; a typical rescue is $20–40k in total. A full rebuild like this one is the larger engagement: $20k a month, six-month minimum. Either way, at the end the shop owns something shaped like itself instead of renting something shaped like everyone.

The honest limit is the one custom software always carries: you own it. That means a retainer to keep it evolving with the shop (ours starts at $3,500 a month), or any competent engineer you choose — it's a modern web stack, the code and data and deployment are yours, and if we disappeared tomorrow it would keep running and someone else could pick it up. That's a feature. It's also a responsibility, and we'd rather name it here than have it surprise you in year two.

Client details redacted. Products, prices, and customers stay confidential; references available on request.

Next: the top of the ladder — the work order that has to leave the building.

Dan Gray · Rivlet — custom manufacturing software. Questions about your own shop? Start with a free call.

← Journal