Inside CTT’s AMA Proof of Concept: What Legacy Modernization Looks Like in Practice

Inside CTT’s AMA Proof of Concept: What Legacy Modernization Looks Like in Practice

A conversation with Felipe Rodrigues, Head of Architecture and Development at CTT, and Pedro Sousa, Application Modernization at Link Consulting.

What happens when a legacy application is too old to have reliable documentation, its business rules are scattered across the system, and simply converting the code would preserve the same complexity?

CTT and Link put that question to the test through an Application Modernization Approach (AMA) proof of concept built around a legacy Oracle Forms application.

The goal was not simply to prove that AI could generate new code. It was to test whether application behaviour, legacy code, business requirements and CTT’s target architecture could be brought together into a structured modernization process — while also identifying what should not be carried into the future.

This interview has been edited for clarity and translated from Portuguese.

Why was this application chosen for the proof of concept?

Felipe Rodrigues:

CTT has a very long history and, over time, we have naturally accumulated applications built in different periods and with very different technologies.

Some of those applications still support critical business processes. In some cases, however, the technology is now obsolete, documentation is limited and much of the original knowledge has disappeared as people have left the organization.

This application represented that reality very well. It was based on legacy technology, had limited documentation, and its business rules were distributed across screens, procedures and different parts of the system.

Modernizing Java to a newer version of Java is relatively straightforward. The real challenge comes when you have a very old application, little documentation and no clear view of where the business rules actually sit.

“When you are dealing with very old applications, no documentation and rules scattered across different components, agents alone cannot do all the work. You need a framework to guide the process.”

How do you recover requirements from an application with little or no documentation?

Pedro Sousa:

We started with the way the application was actually used.

A business user who knew the application very well recorded the main usage journeys. That gave us direct evidence of how the system supported the business process.

Agents processed those journeys and created an initial functional structure of the application. We then analysed the source code to enrich and validate the requirements identified through actual usage.

That combination is important because the code can contain functionality that is no longer relevant, functionality nobody uses anymore, or responsibilities that should now sit somewhere else in the architecture.

From that process, we initially identified 28 macro-requirements.

CTT reviewed them and selected 21. Seven were intentionally excluded.

The objective was not to reproduce everything that existed. It was to understand what the application really needed to do.

What did that requirements recovery reveal about what should — and should not — be modernized?

Felipe Rodrigues:

For me, this was one of the main differentiators of the project.

AI is something everyone is experimenting with at the moment, including us. But what stood out here was the ability to work not only from the code and whatever documentation existed, but also from the actual behaviour of the application.

We started with information that was highly distributed and not particularly structured, and the framework allowed us to turn that into a much clearer definition of how the application should work.

But it also helped us identify things that should no longer be part of that application.

Reference data is a good example. Today, CTT has a dedicated platform for reference data. It would make no sense to reproduce that capability independently inside every application.

That is part of modernization too.

“Modernization is not just about modernizing the application exactly as it is. You have to stop and redefine, based on your current architecture, what still makes sense in today’s context.”

The goal is not to rebuild the past with new technology. It is to decide what still belongs in the future architecture.

How did you ensure the new application fitted CTT’s target architecture?

Pedro Sousa:

Once the requirements had been selected and detailed, we moved into the implementation process.

From there, we generated test cases and began generating the new application. But this was not simply a case of translating an old application into a new language.

The architecture of the new solution was completely different.

The original application was fundamentally based on Oracle Forms and a database-centric model. In the new architecture, business data would instead be accessed and persisted through REST APIs defined by CTT.

The target architecture therefore became part of the context given to the agents.

Instead of saying only “build this requirement”, we could also specify which APIs should be used, which architectural constraints had to be respected and which development standards the application needed to follow.

Felipe Rodrigues:

From the CTT perspective, that was extremely important.

Over the previous year, we had defined a software engineering framework. We want developers to focus on business requirements and value creation while operating within a common engineering foundation.

The POC therefore had to prove that a legacy application completely misaligned with our current technology standards could be rebuilt according to our defined tech stack, both in the front end and the back end.

Most of our new applications run in containers in the cloud and use automated deployment processes.

We already had that foundation documented internally, which meant the agents could use it as context.

“It was very important to me that the POC could generate the new application on top of our software engineering framework.”

How did you validate that the new application still did what the business needed?

Felipe Rodrigues:

We asked the tech lead responsible for the application, who knows it very well, to carry out an initial technical and functional validation.

The main purpose of the POC was not to exhaustively validate every functional detail. What we really wanted to test was whether the modernization process itself worked.

We successfully deployed the application into the quality environment, made it available for testing and validated the main behaviours.

We decided not to move it into production because some functional aspects still required adjustment. But that is perfectly normal in software development.

The important thing is to identify those issues as early as possible.

That is also consistent with the shift-left approach: detect problems earlier in the development lifecycle, before they reach production.

Pedro Sousa:

The interface was another interesting part of that validation.

It obviously made no sense to recreate an interface that looked like the original Oracle Forms application. But some working patterns still mattered.

Users relied heavily on keyboards, shortcut keys and barcode readers because they needed to process operations quickly.

So modernization did not mean removing those behaviours simply because they came from an older application.

The new interface could be modern while preserving the interaction patterns that still supported user productivity.

Modernization should preserve what continues to create value.

What does this approach change at application portfolio level?

Pedro Sousa:

This is where the discussion becomes much broader than one application.

The decision about what should be migrated, decommissioned, consolidated or functionally enriched is a classic enterprise architecture problem.

If an organization has hundreds of applications and simply converts all of them from one technology to another, it can spend a great deal of money and still end up with exactly the same number of applications and integrations.

The technology changes.

The complexity does not.

“Code-to-code migration preserves the complexity of the application portfolio.”

A requirements-first approach creates a different possibility.

You can recover requirements from several legacy applications, identify overlap and, where it makes architectural sense, consolidate those requirements into fewer future applications.

A significant part of legacy code may not need to be migrated at all. Some functionality is no longer used. Some is duplicated. Some responsibilities should now sit in shared platforms or other systems.

And once you reduce the number of applications, you also reduce integrations, dependencies and the infrastructure and maintenance effort associated with them.

That is when modernization becomes an opportunity to simplify the application landscape itself, rather than simply replace its technology.

What comes next for CTT’s legacy landscape?

Felipe Rodrigues:

The next step is to look at the applications across our landscape that fit this type of context.

But our goal is not simply to have modern applications.

“Our objective is not simply to have modern applications. It is to have applications that make sense for the business.”

We started analysing our application landscape in 2022, and we are now reviewing that work because CTT itself has evolved significantly since then.

For every application, we first need to decide what its future should be.

Should we modernize it?

Should we switch it off?

Should its functionality move somewhere else?

Should it be consolidated with another application?

That decision has to come before the technology decision.

There are always new tools and new solutions appearing, and we continue to experiment both internally and with partners.

But I do not believe there is one single piece that solves every problem.

Once you know where you want the application landscape to go, you are in a much stronger position to decide which approach makes sense for each case.

What did this POC prove — and what did you learn from working together?

Felipe Rodrigues:

From the perspective of what we wanted to test, the result was what we expected.

For me, the concept was validated.

Even though this was a proof of concept, there was also a strong sense of delivery and very good collaboration between the teams.

It felt like a real project: we had a goal, we had blockers, and we had to resolve those blockers and deliver.

That is exactly the type of attitude we look for in the people and partners who work with CTT.

From modernization to simplification

The CTT x Link POC suggests that AI-supported application modernization is not simply about generating code faster.

Its value lies in connecting application behaviour, recovered requirements, architecture, testing and implementation within a structured engineering process.

More importantly, it creates an opportunity to question the legacy itself.

Instead of asking only:

“How do we migrate this application?”

The more useful question may be:

“What is actually worth carrying with us into the future?”

Felipe Rodrigues
Head of Architecture and Development
CTT

Pedro Sousa
Application Modernization
Link Consulting