By Macrotest Informática
There are systems that nobody wants to touch. Not because they are bad. Quite the opposite: they work.
They process payments, settle transactions, manage policies, serve customers, and support processes that an organization relies on every day. Some have evolved over decades and, although they may look “legacy” from the outside, they remain a fundamental part of the operation.
However, when the business needs to change or update them, the problem appears.
A new digital channel needs real-time information. A product needs to integrate with other services. A business partner needs an API. A regulation requires a process to be modified. The business team wants to launch something within weeks and discovers that doing so requires touching an application that has been in production for years.
Then a much more difficult question arises: “What technology should we implement?”
How do we change something we cannot stop using?
That is, in our experience, the real conversation about modernization.
The system is not usually the problem
For years, the word legacy was used almost as a synonym for old technology. But in many projects, reality is different.
A system can have decades of history and still be extremely efficient at what it was built to do. The problem is not necessarily its ability to process a transaction. It lies in everything around it: how much it costs to modify, how much knowledge is required to do so, how easy it is to integrate it with other services, or how long it takes to test a change. And that changes the conversation.
Perhaps it is not necessary to replace the system, but rather to make it better able to participate in today’s ecosystem.
A fairly common situation
Imagine an organization with a critical application that has been running for many years.
The system processes operations correctly and the business trusts it. But now a new need arises: to introduce a digital channel that allows customers to view or perform an operation that, until then, was handled through other channels.
The first reaction may be to think about replacing the application.
But when the process is analyzed in more detail, another possibility emerges: perhaps the application does not need to change. Perhaps what is needed is to expose certain capabilities so that other systems can use them.
An API can then become much more than a technical component. It can be a way of giving new life to a capability that already exists.
The system continues processing as it has for years. The new channel can use that functionality. And the organization moves forward without having to rebuild from scratch something that already works. It may not look like a spectacular transformation. However, from a business perspective, it may be exactly the transformation that was needed.
Real modernization does not happen on a whiteboard
In modernization projects, there is an important difference between what is designed and what ultimately happens.
On a whiteboard, it is easy to draw:
Legacy → Cloud → New architecture
In production, reality involves users, maintenance windows, interfaces that nobody documented years ago, batch processes, dependencies between applications, regulations and, above all, people who understand how the business actually works.
That is why we prefer a different approach:
understand → test → measure → move forward.
Modernization can start with something much smaller:
- Expose an existing function through an API.
- Automate a manual task.
- Reduce the time required to modify an application.
- Improve process traceability.
- Separate a dependency.
- Make information visible that was previously locked inside an application.
And Then AI Emerged
Artificial intelligence is also changing the way we approach these projects.
There is a difference between using AI to generate code and using it to understand systems that often have decades of history.
One of the biggest challenges of modernization is not writing new code, but deciphering the code that already exists: what an application does, which programs it calls, which files it uses, what business rules are hidden in thousands of lines of COBOL, which processes depend on it, what can be changed and what cannot.
In an application that has been in production for many years, finding where a particular rule is implemented may require reviewing programs, copybooks, JCL, files, and relationships between components that have been built over decades.
In the past, much of this work depended on someone on the team knowing where to look. Today, however, we can use AI tools to accelerate this analysis: identify dependencies, explain code fragments, generate initial documentation, or find where specific logic is implemented. This does not mean that AI “understands the business” or can decide what should be changed. Rather, it can reduce the time required for a specialist to get to the right place. And that difference matters.
AI does not replace the expert who knows the system. It helps them reach the information they need to make a decision faster.
Not Everything Has to Move to the Cloud
Modernizing does not necessarily mean migrating everything. This is another idea that deserves to be reconsidered.
Not everything needs to become microservices, nor does everything have to run on a new platform. And not every problem can be solved by adding another tool. In some cases, the best decision may be to keep a significant part of the application where it is and modernize its interfaces, development processes, integration, or the way data is accessed. In others, it may make sense to migrate certain capabilities while keeping others in place.
The final architecture should respond to the business, not the other way around. This is especially important in organizations where operational continuity is non-negotiable. You cannot shut down a bank, an insurance company, or a large corporation for months to rebuild everything from scratch. Modernization has to coexist with ongoing operations.
The Real Measure of Modernization
Perhaps that is why we also do not believe modernization should be measured solely by how many applications were migrated, how many APIs were created, or how many lines of code were transformed.
There are simpler questions: Can we make changes faster? Can we integrate a new channel without modifying the entire system? Can we better understand a critical application? Can we test a change with greater confidence? Can we incorporate new knowledge without depending on a single person?
If the answer starts to become yes, something is changing. That is probably a much more useful way to talk about modernization.
You Don’t Have to Modernize Everything
This is probably the part that gets lost most often in conversations about technological transformation.
Not everything needs to be replaced. Not everything needs to move to the cloud. Not everything needs to become microservices. Nor does everything need artificial intelligence.
Every organization has a different technology history and, above all, a business that needs to keep operating while that history evolves. That is why we believe in progressive modernization: start where there is a concrete need, generate results, and use what has been learned to decide the next step.
It is not about choosing between legacy and new technology, but about making sure both can work together while the business continues to operate. Because ultimately, modernization is not about building a new system. It is about enabling an organization to continue evolving without having to stop what already works.
Macrotest Informática & G&L Group
Modernization · Mainframe · Integration · Cloud · Artificial Intelligence
Contact: Cintia Scoles — cintia.scoles@macrotest.es | Marcos Rivara — marivara@gylgroup.com
