“Legacy” is a word that summarizes a diagnosis a little too easily. It is used to describe an old system, hard to evolve, whose operating costs rise as the skills to maintain it become scarce. The diagnosis is not wrong. But it is often confused with the solution.
A majority of modernization programs fail or get stuck not because the target is poorly designed, but because the chosen trajectory did not match the real constraints of the system and the organization that operates it. Before choosing how to modernize, you need to understand what you are modernizing. And why this particular system, in this particular context, resists change.
What makes a system “legacy”
A system does not become legacy because of its age. It becomes legacy because its adherence to operations, its dependence on external constraints, and the tacit knowledge held by a team make every evolution costly and risky.
A twelve-year-old Java monolith serving a few thousand requests per day, whose database is documented, whose flows are understandable and whose team has known how to modernize progressively, is not a legacy in the problematic sense of the term. A system written three years ago, but whose business rules are no longer mastered by any current member of the team, whose deployments require tribal manual operations and whose smallest change demands weeks of validation, is.
The real signals of a legacy that is hard to transform are more operational than architectural. A dependency on a historical vendor that imposes a frozen format. A nightly batch that only one operator knows how to restart manually after an incident. A business parameter that lives in a stored procedure no one has reviewed in five years. A partner integration whose contractual constraints allow no modification of the protocol.
These factors determine both what makes the transformation difficult and what should drive the choice of trajectory. Modernization and system readability are inseparable: a system you only half understand does not get modernized, it gets rewritten blind.
Modernization trajectories
Several trajectories exist. None is universally superior. The choice depends on the operational coupling of the system, the time available, the team’s maturity, and the business value that remains to be extracted from the existing system.
Encapsulation. A layer of abstraction is placed in front of the existing system (an API gateway, an anti-corruption layer) that decouples consumers from the legacy. The legacy is not modified, but its external environment stops adhering to it. Useful when the system is stable but its raw interfaces prevent the rest of the IS from evolving. Limit: you don’t address the legacy’s own debt, you isolate it.
Progressive rewrite. The Strangler Fig pattern formalizes this approach: progressive routing redirects flows to new components, and the old system shrinks until it disappears. Useful on systems where modules can be extracted with their functional boundaries. The mechanics of coexistence must be deliberately designed: it is not a transitional phase you endure, it is a state to be designed.
Replatforming. The system is migrated onto a modern infrastructure or platform without rewriting its business logic. Containerizing a Java application, migrating an Oracle database to PostgreSQL, moving to a managed PaaS. Useful to reduce operating costs and unblock a critical dependency (end of support, outbound contract), without reopening the question of application debt.
Complete rewrite. Less common than it claims to be, but sometimes rational. When the system is of modest size, when its business rules are well documented (or can be re-derived from an external source of truth), when a parallel operations effort can be funded, and when no continuity constraint forces coexistence, rebuilding from scratch can be faster and safer than a progressive rewrite. A practical rule: if the progressive trajectory would require more than eighteen months for a perimeter you can isolate and re-divide with confidence, the complete rewrite option deserves serious consideration. This is not a dogma against the option, it is a reality test.
Replacement by a commercial solution. When an internal component no longer carries business differentiation (document management, signature, payroll, auxiliary accounting), its replacement by a SaaS or commercial solution is often the lowest-risk option. The complexity shifts toward data migration and integration, which remain significant work, but the continuous operations burden drops.
Decommissioning. Not every system is meant to be modernized. Some processes can simply be turned off because their use has disappeared, their business value has eroded, or their function has been absorbed by another component. Identifying these zones and shutting them down cleanly frees up bandwidth for what truly matters. It is often the most powerful decision of a modernization program, and the least taken.
These trajectories combine. On a real program, one module is encapsulated, a second is rewritten progressively, a third is decommissioned, a fourth is replaced by SaaS. The initial scoping work consists of identifying the right trajectory for each component, not applying a single method to the entire system.
What separates viable trajectories from dangerous ones
A trajectory chosen on paper can collapse in execution if several structural factors have not been read correctly.
Operational coupling. The more a system is embedded in ongoing operations (financial transactions, real-time regulatory reporting, external partners connected synchronously), the narrower the window for transforming it. Some systems do not tolerate the slightest unavailability; others can absorb cutovers of a few minutes. This tolerance determines the palette of realistic trajectories more reliably than any architectural consideration.
The depth of business knowledge embedded in the code. A system that materializes twenty years of scattered business rules, without up-to-date documentation and without a reference test suite, does not get rewritten. Not in one go. The rules first need to be externalized into a source of truth usable by both systems (legacy and new), and this is a project in itself, sometimes longer than the transformation itself.
The team’s maturity on the target. A team that perfectly masters the legacy but is discovering the target stack is exposed to a risk that is systematically underestimated. The ability to operate a new architecture, to diagnose an incident in an unfamiliar environment, to understand the failure modes specific to the target paradigm, takes months to build. A trajectory that ignores this learning curve produces a system that is more modern but harder to operate, which is not a success.
Non-negotiable business constraints. Regulators, contractual partners, deployment windows imposed by other actors: what appears to be administrative friction is often the most rigid constraint of a program. A viable trajectory must work with these constraints from the scoping phase. Ignoring them means discovering, late in the program, that none of the planned steps is executable on the real calendar.
When a trajectory fails, it is rarely because it was technically bad. It is usually because one of these factors had been read with optimism.
What successful programs have in common
Modernization programs that succeed share a few observable traits. Not a method, not a standard framework: dispositions you tend to find, and whose absence rarely leaves a healthy trajectory.
Successful programs make an explicit decision about what will not be modernized. It is less obvious than it seems: a large part of a program’s energy ends up in components that did not really need to evolve. Identifying, at scoping time, the zones that can stay as they are (because they work, they block nothing, and their debt threatens nothing in the short term) frees budget for what really needs to move.
Progress is not measured in percentage of completion. A modernization program is not a project with a Gantt chart. It is a continuous flow where what matters is the ratio between delivered value and remaining debt. Solid programs watch operational indicators: incidents that touched the already-transformed zones, ability to deploy to production without manual coordination, mean time to repair. These indicators tell you what is actually improving, where a completion percentage mostly tells you what reassures management.
The cutover mechanism is designed at scoping time, not at the end of the program. The moment a flow is switched from an old system to a new one is rarely the moment when that mechanism gets invented. On programs that succeed, the routing strategy, the rollback mechanisms, the parallel comparison protocol are defined early, tested early, and rehearsed well before the first real cutover. On programs that drift, these questions arrive in the final days, and that is usually when everything breaks.
And the legacy system is maintained seriously during the transformation. A team that considers the legacy “already dead” accumulates debt throughout the program: incidents not properly fixed, parameters tweaked on the fly, documentation left to decay. These residues then migrate to the new system, or prevent its stabilization. Trust-condition maintenance of the legacy during the transition is a parallel expense that looks like a cost, but that avoids several others.
These traits are not a checklist. They are dispositions that appear when a program is scoped by people who have already conducted this kind of transformation. When they are absent at the start, the risk is rarely compensated for later.
An example: COBOL banking system
A program conducted for a banking actor illustrates these principles. The system in question handled current accounts for three million customers, written in COBOL, in production for fifteen years.
The initial diagnosis identified twelve critical modules with interlocking behaviors. None could have been rewritten in isolation without destabilizing the others. The decision was made not to transform the entire system: the “Transfers” module, with the highest business value and manageable complexity, was chosen as the first candidate. The trajectory chosen was a progressive rewrite with a router placed in front of the COBOL monolith, a variant of Strangler Fig adapted to the transactional constraints of banking.
Cutover was done by customer segments. The first one percent of the flow was routed to the new component in parallel comparison mode: each operation executed on both sides, the results compared continuously. No divergence over three weeks of real production. The segment was raised to ten percent, then fifty, then one hundred, over six months. Full cutover never happened in a single moment, it was spread over that entire period. No major business incident in eighteen months of the program.
What made the difference was not the technological choice of the target. It was the decision not to attack the twelve modules at once, the routing and parallel comparison mechanism designed from the start, and the active maintenance of the COBOL during the entire program, including bug fixes and minor evolutions, to avoid letting the old system drift during the transition.
Conclusion
A legacy system is not a technical problem to be solved by applying a method. It is a state of the system and of the organization that demands to be read before being treated. Several trajectories exist, and the initial scoping work consists less of choosing a model than of arbitrating between constraints (operational, organizational, contractual) that make a given trajectory viable or dangerous.
The operational mechanics of the transformation, once the trajectory has been chosen, are addressed elsewhere: what happens during coexistence between old and new, and how it is designed as a system in its own right, is the subject of a dedicated article.
Mapping the existing system, isolating the critical zones, transforming without interrupting operations: this is what we do alongside technical teams. Modernization and managed services for trust-critical systems.