Your Old Software May Not Need to Die. It Needs a Map.
Legacy modernization does not require choosing between permanent paralysis and a total rewrite. Recover the system’s hidden rules, create behavioral evidence, expose controlled seams, and replace bounded capabilities one at a time.
By Reynier RiveroSoftware engineer
“Then we rebuild the whole thing.”
The sentence lands cleanly on the architecture slide. The current order platform is expensive to change, two of its core components are no longer supported, and the team that originally built it has mostly left. A fresh system seems easier to explain to the board.
Then an operations manager points to a nightly job with an eight-character name. It waives a fee for one class of distributor, delays another charge until a reconciliation file arrives, and treats the final business day of the quarter differently. The rules are not in the requirements repository. Some are not documented anywhere.
This is a composite scene, built from a pattern common to long-lived business systems. It is not a report of one company. But the dilemma it exposes is real: the software may be obsolete in places while the behavior encoded inside it remains essential.
The code is old. The rules are alive.
A legacy system is rarely just old technology. It is accumulated negotiation.
A customer exception becomes an if statement. A temporary accounting workaround survives six audits. A warehouse cutoff moves from 4:00 p.m. to 4:15 p.m., and years later nobody remembers why the scheduler still checks both. The code becomes a record of decisions the organization stopped recording elsewhere.
That is why “leave it untouched” and “replace it all” are both seductive. One avoids immediate risk; the other promises a clean escape. Neither answers the first question: what does this system actually know?
The danger is not limited to mainframes. It appears in aging ERPs, desktop applications, integration services, database procedures, spreadsheet macros, and custom platforms that became critical gradually. Mainframes simply make the problem unusually visible.
As background, a July 17, 2025 GAO report on IRS modernization identified technical debt in two Treasury and IRS legacy systems, including hard-coded business rules. IRS officials described an intended iterative approach and a roadmap organized around releasable features. That is evidence of the problem and the plan, not proof that the plan delivered successfully.
The asset you need to preserve may not be the application. It may be the organization’s memory hiding inside it.
Modernization begins as knowledge recovery
Before choosing a target architecture, reconstruct the behavioral map.
Start with dependencies: which screens trigger which services, which jobs write to which tables, which exports feed customers or regulators, and which manual steps repair the process when automation fails. Interview the people who know what happens at quarter-end, during a partial shipment, or after a duplicate payment.
Recent vendors are building around this discovery problem. In an August 3, 2026 product article, Google said its Mainframe Assessment Tool maps dependencies, extracts business rules, and identifies domains, boundaries, and interfaces. That is Google’s description of its product, not independent evidence of accuracy or guaranteed equivalence.
Recovered rules should still be treated as hypotheses. A plausible explanation generated from code can be useful, but it becomes trusted knowledge only after experienced operators and behavioral tests confirm it.
This is where teams often discover that the legacy application is not one system. It is a cluster of capabilities with different risk levels, change rates, and owners. That discovery makes it possible to modernize around the business rules already embedded in the operation instead of forcing every capability through the same replacement program.
Build evidence before you move behavior
A rewrite asks, “Can we recreate this feature?”
An incremental modernization asks a harder question: “Can we demonstrate that the new path behaves correctly?”
That requires evidence around the old path first. Add characterization tests for inputs and outputs, even when the internal code is difficult to test. Capture representative transactions. Instrument latency, failures, queue depth, unusual branches, and manual interventions. Record which team owns the response when a boundary fails.
Observability is not decoration added after migration. It is what lets you compare old and new behavior without relying on confidence, memory, or a successful demo.
In a September 21, 2026 seller-sponsored post co-written with OpenAI, AWS said AWS Transform analyzes COBOL, PL/I, JCL, copybooks, and data stores, producing business rules and acceptance criteria with source-line traceability. The same post calls for expert review plus automated, integration, and user-acceptance testing before production. It does not establish independent accuracy, cost savings, or behavioral equivalence.
The useful principle survives the product pitch: traceability can accelerate review, but it cannot replace accountability.
An API seam is a boundary, not a disguise
Once the team understands a capability, it can place a controlled boundary around it.
That may mean exposing an existing calculation through an API, moving file exchange behind an integration service, or routing a new application through a façade that protects callers from the legacy system’s internal shape. The goal is not to make old code look fashionable. It is to create a seam that can be observed, secured, versioned, and eventually redirected.
An API boundary needs a named owner, explicit authentication, least-privilege access, input validation, timeouts, versioning, and useful logs. Otherwise, the organization has not reduced coupling; it has merely hidden it behind HTTP.
NIST’s March 13, 2026 API-protection guidance notes that enterprise systems depend on APIs for integration and business processes, and recommends incremental, risk-based controls across the API life cycle. It is guidance, not a law or automatic proof of compliance.
A good seam also changes who can move independently. A customer portal can evolve without querying a legacy database directly. A new fulfillment service can call one stable contract rather than reproduce old rules. Teams can design controlled API connections between old and new systems while the core platform remains in service.
This connective layer matters beyond modernization. The same ownership problem appears when companies accumulate dozens of SaaS products and still lack control over the workflows between them, as explored in our article about owning the connective layer between business tools.
Extract one function that can prove its case
The first extraction should be bounded enough to understand and important enough to teach you something.
Consider a document-validation function with known inputs, explicit outputs, a manageable exception set, and no authority to post transactions by itself. Run the new version beside the old one. Compare decisions. Investigate mismatches. Let the old path remain authoritative until the evidence supports switching.
The choice should account for business value, dependency count, reversibility, observability, and the cost of a wrong answer. A workflow does not become a good first candidate merely because executives complain about it most often. The prioritization logic in our tool-agnostic framework for deciding what to automate first applies here too: frequency and frustration matter, but so do stability and consequence.
After the first cutover, keep watching. Some rules reveal themselves only at month-end, during a retry, or when an upstream system sends an incomplete record. Maintain a rollback path until the new capability has survived the conditions that matter.
Then repeat with the next bounded function.
Inventory, tests and runtime visibility, controlled APIs, one extraction, behavioral validation, and repetition form a practical sequence—not a source-proven universal recipe. Some systems will require a different order. The value of the sequence is that each step produces knowledge before the next step enlarges the risk.
The real choice is how you learn
Incremental modernization can still fail. Teams can reproduce bugs as requirements, miss manual recovery paths, create two conflicting sources of truth, or leave temporary bridges in production for years.
The defense is not a perfect migration plan. It is a program that makes uncertainty visible.
Ask what must remain authoritative during each transition. Decide who can approve a behavioral difference. Track temporary interfaces as liabilities with owners and removal conditions. Give operations staff a role in acceptance, because they often know the exceptions that architecture diagrams omit.
At your next modernization meeting, replace “rewrite or retain?” with more revealing questions:
Which behaviors would customers notice if they disappeared tomorrow? Which rules can we trace to evidence? Where could we install a boundary without changing the outcome? What is the smallest extraction whose success or failure would teach us something useful?
If those questions expose more archaeology than architecture, that is not a reason to freeze. It is the beginning of a safer plan. Prontavel can help recover the rules, design the seams, and build the first bounded modernization step without pretending the rest of the system has to vanish at once.
The service this article is about: Bespoke software for what your organisation actually does