What If This Were Your Application’s Last Migration?

Modernize or build from scratch? I stopped seeing them as two separate disciplines a long time ago.

My first information systems reengineering project was in 1997, at the former Portugal Telecom. Even then, the aim was for reengineering to follow, as closely as possible, the same process as software engineering.

Today, we call information systems reengineering application modernization. For many, modernization is purely technological. For me, it is also functional — not only because a significant part of legacy applications is no longer used, but also because if legacy systems fail to evolve functionally, business needs lead to the creation of new applications, increasing the complexity of the application portfolio.

As we know, until now, it has often been easier to build something new than to evolve legacy systems.

Almost thirty years later, I still hold the same view: modernizing a legacy application and building a new one are the same engineering process. They differ at only two points. Everything else follows a common path.

The main difference is where the requirements come from

Every application starts with requirements. The question is where those requirements come from.

In traditional development, requirements are gathered through different approaches: workshops with the business, process design, among others.

In modernization, requirements are “recovered”.

I believe the approach that enables the greatest degree of functional modernization is to record the application’s user journeys. When processed through process-mining techniques, these journeys reveal not only individual interactions but also how, collectively, those interactions fulfil the business purpose.

Combining this with source-code analysis and any existing outdated documentation — used mainly to capture the business vocabulary — makes it possible to recover both the requirements and the purpose of the application.

And this is where the clean-up happens that no code-to-code conversion can achieve: between dead code, functionality that nobody has used for years and features duplicated across applications, 40 to 50% of legacy code does not need to be migrated.

Recovering requirements also means deciding, together with the business, what should actually be migrated.

Ultimately, requirements gathering and requirements recovery are different techniques for answering the same question:

What should this application do?

But once that answer exists, the two paths converge.

Both techniques are extensively supported by agents, although requirements recovery is practically impossible to perform manually.

The common path

From this point onwards, the process neither knows nor needs to know whether a requirement originated in a workshop or was extracted from a twenty-year-old system. Requirements have the same form and are measured against the same quality criteria.

Functional and technical design comes next.

Today, all functional and technical design is carried out by agents under human supervision, with a reference architecture guiding each stage. The agents do not invent. They follow clearly defined standards and rules.

Tests are derived from the specification, with full regression testing from day one and every line of code traceable to the requirement that justifies it.

Anyone who, like me, comes from the traditional engineering disciplines will recognise this entire process.

The major difference is that, although the design artefacts are the same as they have always been, they are no longer passive. They have become actionable.

In the past, a design artefact existed for someone to read it and produce the next artefact. Today, it can generate the next artefact itself. This is the essence of functional and technical design automation and the foundation of agent-based spec-driven development.

It is engineering as we have always known it, but now it can be automated from beginning to end and applied equally to applications developed from scratch and to those being “modernized”.

Generating code from specs using agents is already a trivial task.

The second point of difference: the final proof

Before an application goes into production, its correct operation must be assured.

For a new application, the source of truth is the validated set of requirements, and the ultimate proof lies in the tests derived from them.

Requirements-based testing also applies to modernized applications. But for functionality that has not changed during modernization, we can go one step further and validate it by comparing the results of running the new and legacy applications in parallel.

This technique is usually quite complex. However, because we generate the code, we can build in from the outset all the mechanisms required to facilitate parallel execution, making this approach viable in many situations where it would otherwise not be possible.

The major advantage is that the client does not need to carry out acceptance testing.

The legacy application is only switched off once the new one has consistently demonstrated equivalent behaviour.

After go-live, the two paths become indistinguishable

And this is where the cycle closes.

An application modernized through this approach is maintained exactly like an application developed from scratch: changing the application means changing a requirement and regenerating the code and tests, with documentation always kept up to date as a by-product.

There is no second, more expensive and more fragile maintenance regime for migrated applications — the usual outcome of code-to-code conversions, which leave behind new code that is completely unfamiliar and typically follows patterns and principles that are not those of the organization.

There is one consequence that I consider more important than all the others:

This will be the last migration.

We know that both code and requirements become obsolete, but requirements are far easier to modernize than code.

Once the requirements have been updated, all we need to do is generate the code again — something that is becoming increasingly trivial.

Requirements, until now often left neglected, are becoming the true strategic asset of the application portfolio.

Pedro Sousa Application Modernization Link Consulting