Legacy systems: when to modernize and when to replace — a guide for decision-makers

Every organization that has reached a certain level of maturity carries, somewhere in its stack, a system that no one wants to touch anymore. It might be 10, 20, or even 30 years old. It runs on obsolete infrastructure, was written in a language most young developers never learned, and its documentation — when it exists — has been outdated for years. But it works. And that is precisely what makes the decision so difficult.

The question that CEOs, CTOs, and founders ask me frequently is: do we modernize or replace? It sounds like a technical question. It is not. It is a strategic decision with financial, operational, and competitive implications that can define the next five to ten years of a company. In this article, I will share the framework I use with my clients to make this decision with clarity — without technological romanticism and without the alarmism that often comes from those who have an interest in selling a large project.

The real problem with legacy systems

Before talking about modernization or replacement, it is necessary to understand what truly makes a system legacy. It is not age. It is not the programming language. A legacy system is one that accumulates technical debt at a faster rate than the organization's capacity to pay it down. It starts to cost more to maintain than it would deliver if rewritten. And, more importantly: it starts to limit the business.

In over 20 years working on architecture and modernization projects — including time at IBM and AWS, and serving clients such as B3, BTG Pactual, Safra, and XP — I have identified a consistent pattern: the problem is rarely the code. The problem is the organizational inertia surrounding that code. Entire business processes were modeled to work around the system's limitations. Entire teams were formed to compensate for what it does not do automatically. And no one knows exactly what happens if it stops.

This creates a paradox: the most critical system in the company is frequently the least understood. And that is precisely the starting point for any modernization decision.

The four signs that the decision can no longer wait

There is a natural tendency to postpone this conversation. The arguments are always reasonable: the system works, the team knows it, the risk of change is high, the timing is not right. But there are four signs that, when they appear together, indicate that delaying has a higher cost than acting.

• Maintenance cost above 60% of the IT budget: When most of the budget goes toward maintaining what already exists, little is left for innovation. Companies that reach this threshold lose competitiveness in a silent and progressive manner.
• Time-to-market above 3 months for simple changes: If a business rule change takes quarters to go live, the system is blocking growth. More agile competitors fill that space without making noise.
• Dependency on specific individuals: When two or three people hold critical knowledge about how the system works, the company is held hostage. The retirement, dismissal, or illness of one of these professionals can be catastrophic.
• Inability to meet regulatory requirements: In the Brazilian financial sector, for example, the Central Bank's requirements evolve at a pace that systems with rigid, monolithic architecture simply cannot keep up with.

If two or more of these signs are present, the decision is urgent. The question then becomes: which path to follow?

The decision framework: six questions that define the path

There is no universal answer to modernize or replace. What exists is a set of questions that, answered honestly, point in the right direction. I use this framework with clients from different sectors and sizes, and it consistently delivers clarity where there was paralysis.

1. Does the system still reflect the current business logic? If the business rules embedded in the code are still valid, modernizing the infrastructure and architecture may be sufficient. If the business model has changed and the system carries obsolete logic that must be constantly worked around, replacement tends to be more efficient.

2. Is there sufficient documentation for a safe migration? Modernizing requires understanding what the system does. So does replacing it. The difference is that, without documentation, a complete replacement turns into a reverse engineering project in disguise — with all the risks and costs that implies.

3. What is the real cost of a failure during the transition? For mission-critical systems — payment processing, risk management, real-time inventory control — an outage has a measurable cost per hour. This number must factor into the risk calculation of any chosen approach.

4. Does the current team have the capacity to execute? Modernization projects fail more often due to execution capacity than wrong technical choices. A complete replacement with a team inexperienced in distributed systems can be riskier than an incremental modernization with the existing team.

5. Does the system vendor still offer support? Systems running on unsupported versions from vendors such as Oracle, SAP, or IBM carry a growing security risk that must be considered regardless of other factors.

6. How quickly does the investment need to return? Complete replacements typically have a longer return horizon. Incremental modernizations allow value to be captured sooner. The return horizon expected by the business should calibrate the choice of approach.

Incremental modernization: when it makes sense and how to execute it

Incremental modernization — often called the strangler fig approach, in reference to the architectural pattern described by Martin Fowler — consists of progressively wrapping the legacy system with new components, transferring functionalities one by one until the old core can be safely shut down.

This approach makes sense when: the system still reflects valid business rules; the team has deep knowledge of the system's behavior; the business cannot tolerate interruptions; and there is budget for a medium-term project (18 to 36 months for large-scale systems).

Execution requires architectural discipline. The most common mistakes I see are: starting with the modernization of the simplest parts rather than the most critical ones, creating a false sense of progress; failing to establish clear boundaries between the legacy system and the new components, generating coupling that negates the benefits; and underestimating the regression testing effort, which in legacy systems without automated test coverage can consume more time than development itself.

A practical reference: in a project I led for a mid-sized financial institution, the modernization of a legacy banking core was structured into seven functional modules, with deliveries every four months. The project took three years, but the business captured value from the third month onward, when the first module — settlement processing — was migrated to the new AWS cloud architecture. The reduction in operational cost for that single module alone justified the first year's investment.

Complete replacement: when it is the right choice and how not to get it wrong

Complete replacement — rewriting or deploying a new system from scratch — is the riskiest option and, at the same time, sometimes the only viable one. It makes sense when: the system carries obsolete business logic that creates more friction than value; the architecture is so rigid that any change requires disproportionate effort; the cost of maintaining the legacy system is so high that it would finance the new system within a few years; or when a mature market solution exists that meets 80% or more of the requirements.

The classic mistake in complete replacement projects is what the industry calls a big bang rewrite: stop everything, rewrite from scratch, and switch on the new system on a set date. The history of enterprise technology is full of projects that died this way — some after years of development and investments in the range of R$ 50 million to R$ 200 million with nothing delivered to production.

The correct approach, even in complete replacements, is execution in parallel phases. The legacy system continues operating while the new one is developed and validated. Data and user migration happens in controlled waves, with the possibility of rollback at each stage. And the success criteria for each phase must be defined before the start — not during execution, when the pressure to push forward tends to cloud judgment.

The human factor no one wants to discuss

Every decision about legacy systems has a political dimension that technical frameworks deliberately ignore. The legacy system has owners. There are people who built their careers around it, who hold critical knowledge about how it works, and who have reasons — some conscious, others not — to resist change.

This is not a criticism. It is organizational reality. And ignoring it is one of the main causes of failure in modernization projects.

In successful projects I have accompanied, the consistent pattern was as follows: the professionals who know the legacy system best were placed at the center of the modernization project, not on the periphery. They became the guardians of business knowledge — documenting rules, validating behaviors, defining test cases. This repositioning transforms potential resisters into protagonists, and captures an asset that would be lost in a purely technical approach.

Decision as competitive advantage

Companies that treat systems modernization as an IT project lose. Companies that treat it as a strategic business decision win — not only in efficiency, but in the ability to move faster, to experiment at lower cost, and to respond to market changes that their competitors are still trying to understand.

The question is not modernize or replace. The real question is: what competitive position do you want to occupy over the next five years, and which decision about your legacy systems brings you closer to or further from that?

That question deserves a serious conversation — with data, with clear criteria, and without pressure from those who want to sell a project. If you are facing this decision now, or anticipate that you will be in the coming months, it is worth structuring this analysis before urgency forces a choice that could have been better with more time and clarity.