An application has been running for twenty years. It has survived several generations of employees, changes in strategy and countless special cases added along the way. Nobody would build it the same way today. And yet, a significant part of the business still depends on it.

Eventually, someone says: “We really need to modernise this.”

But what does modernisation actually mean? Translating the code into another language? Redesigning the interface? Moving the application to the cloud? Or using the opportunity to reconsider how the company should work in the future?

The AISM programme presented a wide range of approaches to AI-supported modernisation: from COBOL-to-Java translation and agent-based C-to-Rust migration to understanding existing applications, reconstructing architectural decisions and combining AI with traditional program analysis.

The range of topics makes one thing clear: legacy modernisation cannot be reduced to a single technical task.

One contribution captured an important distinction directly in its title: “Passing Parity Is Not Preserving Behaviour.” Passing comparison tests does not necessarily mean that a migrated application has preserved the behaviour of the original system.

From a business perspective, we would take the question one step further: even if the new application does exactly what the old one did, does that mean it is still doing the right thing for the business?

This question lies at the heart of our approach with Legacy Revive.

The application needs to run on a modern platform.

From a business perspective, however, very different questions emerge. Why do certain quotations require three approvals? Which pricing rules are still relevant? Where are employees entering the same information more than once? Which special cases represent a genuine competitive advantage? And which ones exist simply because the old system did not allow for a better solution?

The example is fictional, but it highlights an important distinction: technically transferring an existing system is not the same as meaningfully improving the business process behind it.

If we confuse the two goals, we may end up with a modern application that forces users through exactly the same unnecessary steps as before. The technology is new. The problem remains.

With Legacy Revive, we deliberately start somewhere else. Our first question is not “How do we translate this code?”. It is “What should this application do for the business?”

That does not mean the existing code is irrelevant. Quite the opposite. An application that has been running for years can contain an enormous amount of valuable knowledge: business rules, exceptions, dependencies and decisions that may no longer be documented anywhere else.

But the code is a source of information. It should not automatically become the blueprint for the future. An existing implementation primarily tells us how something was implemented. It does not necessarily explain why it is needed, whether it is still needed, or whether there is now a better way to achieve the same goal.

Our Business-first approach therefore asks three questions before deciding on the technical solution:

1. What must be preserved?

Which business rules, capabilities, knowledge and obligations are essential?

2. What should change?

Which processes should become simpler, faster or more transparent?

3. What can disappear?

Which functions and special cases have lost the purpose they were originally created for?

For us, these questions are not an additional step in modernisation. They determine its direction.

Preserve, improve or remove

Saying that “the new application must do everything the old application does” can initially sound like the safest approach. But it may also hide important decisions.

Consider a special discount rule for a particular customer group. Perhaps it reflects a contractual obligation that is still valid. In that case, it must be reliably preserved.

There may also be a manual approval step that was introduced years ago because an integration was missing. Instead of replicating the workaround, it makes more sense to understand the underlying control requirement and decide how it should be addressed today.

And there may be a report that nobody has used for years. In that case, the relevant question is not how to rebuild it. It is whether it should still exist at all.

AI’s ability to analyse, generate and transform code creates enormous opportunities for legacy modernisation. At the same time, there is an obvious temptation: if AI can automate technical work, the goal can quickly become automating as much of that work as possible.

Our perspective is different: speed creates value when the direction is right.

Generating a new solution quickly is of little use if it is based on unclear or unvalidated requirements. Likewise, an AI-generated description of a process is not enough if nobody has checked whether it reflects business reality.

For us, AI should support a controlled, traceable and understandable modernisation process. The important question is not only how much AI can produce. It is whether its output helps uncover knowledge, understand dependencies, ask the right questions and support better decisions.

Business decisions remain business decisions. Which risks are acceptable? Which exceptions are business-critical? Which processes should change? What creates value for employees and customers? Those questions cannot be answered from a programming language alone.

A Business-first approach is not an alternative to IT. It is intended to improve collaboration between business and IT. Both sides need a shared view of what success should look like.

“The system needs to be more modern” is too vague. “We need a new architecture” describes a technical intention, but not yet a business outcome.

More useful objectives might be:

If modernisation starts with business objectives, success should also be measured against those objectives.

For our fictional wholesaler, useful measures might include the processing time from quotation to approval, the number of duplicate manual data entries, the time required to implement a new business rule or the proportion of decisions that can be clearly traced and documented.

These are not promised outcomes of Legacy Revive. They are examples of how a Business-first project can define meaningful success.

A successful go-live is an important milestone. Business impact is the real objective.

At insinno, we do not position Legacy Revive as technical renewal for its own sake. We see it as an approach to modernising existing applications based on a clear business rationale.

Our differentiator can be expressed simply: we move from the business to the system – not from the code to a new version of the same system.

We want to understand what makes an application valuable to the organisation. What knowledge must be preserved. What should improve. What no longer needs to exist. And how those decisions can become a solid foundation for technical implementation.

AISM 2026 demonstrated the wide range of technical possibilities available for analysing, understanding, validating and transforming legacy systems.

Our conclusion is that these capabilities need to be combined with something equally important: business clarity.

The key question is therefore not only “Can we rebuild this application?”. It is: “What application will our business need in the future – and what do we really need to preserve from the solution we have today?”

That is where Legacy Revive begins.

Planning to modernise a business-critical application? Let’s talk about your business first. We can talk about the code afterwards.

Learn more about Legacy Revive:
legacy-revive.insinno.eu