Photo: Google Gemini · AI-generated
AWS recently published From Migration to Continuous Modernization, a deep dive into their Transform service for application modernisation. The article is, predictably, heavy on AWS tooling — Bedrock migrations, mainframe COBOL analysis, CodeCatalyst pipelines. But buried inside the product marketing is a message that deserves attention on its own merits:
“Is your organisation still treating modernisation as a one-time project?”
That question is worth more than the rest of the article combined.
The one-time migration fallacy
Most companies approach application modernisation as a bounded project. There is a legacy system, it needs to be modernised, a budget is allocated, and a team spends 6–18 months rebuilding it. Project complete. Move on.
The problem: the modernised application starts aging the moment it ships. Frameworks advance, security requirements tighten, user expectations shift, business processes evolve, and the underlying platform releases breaking changes. Within two to three years, the “modernised” application is itself a legacy system.
This is not a failure of the modernisation effort. It is a failure of the modernisation model. Treating modernisation as a project — with a start date and an end date — guarantees that you will need another modernisation project in a few years.
Four generations and counting
We have lived this at exbisoft. Our Subcontractor Portal for a German construction company is now in its fourth generation. exbisoft has been responsible for generations two through four — inheriting an initial build and continuously evolving it across major technology transitions.
The application started as a .NET web portal. Over its lifecycle, it has been extended to native iOS, Android, and Windows apps, migrated from Xamarin to MAUI, adapted to evolving offline-sync requirements, and restructured to meet new compliance demands. Each generation was not a “project” — it was a response to real changes in the business, the technology, and the user base.
If we had treated the first modernisation as a one-time effort, the application would have been obsolete within three years. Instead, it is still in active use, still evolving, and still delivering value — because the client invested in a continuous partnership, not a one-off contract.
What continuous modernisation actually requires
AWS wraps this in cloud tooling, but the underlying discipline is platform-agnostic. Continuous modernisation requires:
An architecture that tolerates change. Monoliths resist evolution. Applications built with clean separation of concerns, well-defined APIs, and modular components can be upgraded incrementally — a module at a time, a layer at a time — without rebuilding everything.
A team that knows the system. Modernisation is not greenfield development. It requires understanding what exists, why it was built that way, and what will break if you change it. A team that has been with an application through multiple generations carries institutional knowledge that no amount of documentation replaces.
A partnership model, not a project model. One-time modernisation projects end with a handover. Continuous modernisation requires an ongoing relationship — a team that monitors the technology landscape, recommends when to upgrade, and executes the work without the overhead of re-onboarding every time.
Pragmatic technology choices. Not every upgrade needs to adopt the newest framework. Continuous modernisation means choosing the right moment for each change — migrating from Xamarin to MAUI when MAUI is stable enough, not when it first ships. Adopting AI tooling when it genuinely accelerates development, not because it is fashionable.
The AWS bias — and what still holds
The AWS article frames continuous modernisation as a reason to use AWS Transform, Bedrock, and CodeCatalyst. That is a sales pitch. Continuous modernisation does not require AWS — it works on Azure, on private cloud, on-premises, or on any combination.
What holds regardless of platform is the core insight: applications are living systems that need continuous investment. Companies that budget for a one-time modernisation and then expect five years of stability are planning for disappointment. Companies that budget for ongoing evolution — a partner, a team, a recurring commitment — are planning for reality.
The question is not whether to modernise. It is whether to modernise once and hope, or to build modernisation into how you operate.