Your core system is slowing the business down. Someone has proposed a rewrite, someone else has a SaaS vendor's deck open, and your engineers are quietly patching the thing that's running. You've had this conversation before, and you may have watched one of these routes go badly.
There are three routes: rebuild the system yourself, buy a package or SaaS replacement, or renew the current system incrementally while it keeps running. Each has advocates who call theirs the obvious choice. It isn't. The right route depends on four properties of the system, and you can score them in an afternoon.
The takeaway: score the system before you pick a route. A system that holds a lot of value, changes often, lives in a few people's heads and can't be tested punishes both the big-bang rewrite and the off-the-shelf swap. That one you renew in place.
The three routes
Let's take them in turn, then compare them on cost, time, risk and what happens to the knowledge.
1. Rebuild it yourself
The classic big-bang rewrite. Your team writes a specification for "version 2" from memory, tickets and the old code, builds for 12 to 24 months, and cuts over on a weekend. The appeal is a clean slate.
The problem is that the specification is incomplete on day one, because nobody knows all the rules, and the current system keeps changing while you build. The McKinsey and Oxford study of more than 5,400 IT projects found that large ones ran 45 percent over budget and delivered 56 percent less value than predicted. It dates from 2012, and nothing we've seen since suggests the pattern has changed.
2. Buy a SaaS or package replacement
The appeal is real: someone else maintains the software and the cost is a subscription you can forecast. For a supporting function such as payroll or expense claims, this is often the right answer. For the system that encodes how you win, it hides a rebuild. More on that below; it is the most common surprise we see.
3. Renew incrementally
This is Martin Fowler's strangler fig, described in 2004: build the new system around the edges of the old, one workflow at a time, until the old one can be switched off. The current system keeps serving, cost is spread, the first result arrives early, and you can stop after any step.
It isn't free of risk. It needs a specification per workflow, proof that the new version behaves like the old one, a routing layer, a data plan, and an owner for the backlog so you don't run two systems forever. The Thoughtworks authors of Patterns of Legacy Displacement admit that finding the seams to split the work is hard at first, and still call it better than the alternatives, which "all too often result in Feature Parity and Big Bang releases."
How the routes compare
- Cost. Rebuild: large and lumpy, mostly spent before any value lands. Buy: license plus implementation plus the hidden costs below (Panorama's 2024 ERP Report puts the median enterprise software project at $450,000). Renew: spread across workflows, each priced and approved on its own.
- Time to first business result. Rebuild: at cutover, a year or two out. Buy: at go-live, a median of 15.5 months in the same Panorama sample. Renew: when the first workflow moves, in months rather than years.
- Risk. Rebuild: concentrated at cutover, and rollback means redeploying the old system. Buy: fit problems surface late, when the data is half migrated. Renew: spread across small steps, with rollback as a routing change. The risk is stalling, not failing.
- Knowledge retention. Rebuild: undocumented rules are rediscovered as production bugs. Buy: your rules become configuration in someone else's product, and the understanding sits with the implementation partner. Renew: each workflow is written down as it moves, and the record stays with you.
Why "buy" often hides a rebuild
A leadership team that chooses a package expects to avoid engineering. It usually gets engineering under a different name, paid for in three places.
- Customization. The package covers most of what you do. The rest, the rules that make your business yours, gets rebuilt in the vendor's scripting language or an integration layer. Panorama's 2026 ERP Report found that more than a quarter of organizations exceeded budget, with unexpected additional technology needs the leading cause. Panorama's Chris Devault: "organizations often discover fatal misfits late in the project, so they turn to additional technology, scope expansion, and custom builds."
- Data migration. Years of records, statuses and exceptions must be mapped onto the vendor's data model, and every historic report must still reconcile. That is a rebuild of your data model, and it is where cutover weekends go wrong.
- Process change. Panorama's 2024 report notes that in an ERP implementation "organizations typically improve their processes to fit the industry preconfigurations" of the new software, and almost half of respondents reworked most of their processes. The business is rebuilt around the product. Sometimes that's right. If the process is how you compete, you've paid to become average.
We saw this with a publisher's subscription system. The SaaS billing platform under evaluation handled standard plans well but could not express three rules the business depended on: grace periods that varied by region, bundled print and digital entitlements inherited from old contracts, and a renewal pricing ladder tied to tenure. Customizing the platform and migrating the subscriber base was estimated to cost more than renewing the billing workflow. They renewed, and kept the rules.
"But our rules are a mess, surely we should adopt the vendor's?" Maybe. Decide that on purpose, with the rules written down, not mid-migration.
Four questions to score any system
Score each from 1 to 3, then read the total.
- Value tied up. How much revenue or operations run through it? 1: a supporting function. 2: important, but recoverable. 3: the core revenue or operations path.
- Change frequency. How often does the business need it to change? 1: a few times a year. 2: quarterly, with some roadmap friction. 3: monthly or more, with roadmap items blocked by it.
- Knowledge concentration. How many people could explain its rules? 1: documented, with several engineers fluent in it. 2: partly documented, with a handful who know it. 3: two or three people, and the documentation is the code.
- Provability. Could you prove a replacement behaves the same before switching? Michael Feathers defines legacy code as code without tests, which is the point. 1: good tests and observable data. 2: partial tests, usable logs and reports. 3: no meaningful tests, and behavior known only by its outcomes.
- 4 to 6. Keep it or upgrade in place. If change frequency is low, buying is a sensible option.
- 7 to 9. Consider buying if the value is in standardizing the process. Otherwise renew the one or two workflows that scored 3 on change frequency.
- 10 to 12. Renew incrementally. Both the rewrite and the package depend on knowing the rules up front, and a score this high means you don't. Recovering them from the running system comes first, whichever route you take.
A worked example
A German fintech client ran partner onboarding on an eight-year-old Rails application. Value 3, because every new partner account passed through it. Change frequency 3, because regulatory updates and new partner products arrived monthly. Knowledge concentration 3, with two engineers who knew it and one about to leave. Provability 2, with thin tests but good event logs and reconcilable reports. Total 11.
A SaaS onboarding product was on the table, and the scoring made the decision plain: the partner-specific rules were the value, the knowledge was about to walk out of the door, and nobody could describe what the system did well enough to brief a vendor. The first step on any route was the same: observe the running system and write the rules down. With that in hand, renewing the workflow in place was cheaper than paying a vendor to rebuild the rules as configuration.
Decide per workflow, not per system
The mistake in most of these decisions is treating the system as one thing. A system can score 11 overall while five of its workflows score 5 and two score 12. Buy the commodity parts, renew the two that carry the value, and leave the rest until they block something. The score says where to start; the cost of waiting on the initiative behind that workflow says how urgent it is.
Whatever you choose, decide with a scored list and a written record of the rules in front of you, not a vendor's deck and an estimate from memory.
Where Fabrica stands
Fabrica's CLEAR method is built for the renew route. Capture records what the running system does, Lock turns that evidence into a System Specification your owners approve, Engineer rebuilds one workflow against it, Attest tests both implementations against the same specification, and Release moves a customer cohort with acceptance criteria and rollback. The assessment covers one workflow and ends in a recommendation, which may be not to rebuild. The steps are on how it works.
Questions to ask before you choose a route
- Which workflows score 3 on change frequency, and what are they holding back?
- If we buy, which of our rules does the package not express, and who will build them?
- If we rebuild, how do we prove the new version behaves like the old one before customers use it?
- Who holds the knowledge today, and what happens to it on each route?
- Can we stop after the first step and still have something useful?
