Business-critical applications that are too old to extend easily, but too important to simply replace. We guide the entire migration: from portfolio analysis and 6R classification to strangler-fig rollout and handover of operations.
Technical debt is incremental mess: a refactor here and there, adding test coverage, upgrading dependencies. A legacy modernisation is an order of magnitude bigger. It concerns systems where the technology stack itself is the problem: a Delphi application whose original developer has been gone for years, an AS/400 with RPG code nobody dares to touch any more, a Classic ASP portal that no longer works with modern single sign-on, or an Oracle Forms environment that only runs on a specific version of Java, which is itself end-of-life.
The pain is familiar: every change is expensive, every extension feels risky, and the people who still truly understand the system are becoming increasingly scarce. At the same time, years of carefully built business logic is often embedded in it. That mustn't be lost in a migration, but the stack it runs on deserves a second life elsewhere.
We have been doing this work since companies first started planning their cloud migrations. We take a pragmatic approach: not every legacy application needs to be rebuilt. Some should simply be retired, while others can comfortably run for years after a rehost. The art lies in making the right choice for each application and planning the migration so that the business experiences as little disruption as possible. For incremental clean-up work within a single codebase, we recommend our page on resolving technical debt; for the hosting side, we suggest our page on having your platform migration carried out.
A modernisation involves two things that are often only addressed afterwards, at greater cost: measuring what the old system actually does before you begin, and establishing what is really in it, because with older software this is rarely documented anywhere any more.
The scope of a project depends on the number of applications, the dependencies between them, and the degree to which you still have a grip on the original code. In the first conversation, we advise which level suits your situation.
A specific application that is holding the organisation back: a desktop Delphi tool, a Classic ASP portal, or an Access database that has outgrown itself. We rebuild it or replatform it, preserving the business logic that has accumulated over the years. For a single application, with clearly mapped dependencies.
You have a collection of older systems, often built up following an acquisition or years of organic growth. We inventory them, classify each system according to Gartner's 6 Rs (retire, retain, rehost, replatform, refactor, repurchase, rebuild, replace), and build a roadmap with priorities and sequencing. We then carry out the first tranches ourselves.
For organisations with multi-system legacy estates that are subject to compliance scrutiny: financial services under DORA, critical infrastructure under NIS2, and healthcare under NEN 7510. We act as orchestrator across multiple vendors, carry out the complex migrations ourselves, and ensure the audit trail and evidence grow alongside the programme from day one.
Not just new software. You also gain the insight and the operational foundation to continue the modernisation yourselves afterwards.
Below are some patterns we come across often. If you recognise one, this is probably worth a conversation.
A system from the mid-1990s or early 2000s whose builder left long ago. There is no documentation, the code is interwoven with conventions nobody remembers, and every change feels like a gamble.
Common with ICT vendors or after a series of acquisitions: five, six or seven different tech stacks side by side, each known by only a few developers. Maintenance becomes unmanageable and integrations are fragile.
DORA, NIS2, the AI Act or NEN 7510 impose requirements on logging, security or data minimisation that your legacy stack cannot, or barely can, deliver. Patching no longer works; modernisation is the only route.
The physical server running your AS/400 or Oracle Forms application is approaching end of life. Replacing it is costly, yet there is no on-premises successor any more. Migrating to the cloud is the logical step.
You have bought a company and with it an entire application portfolio built on a completely different stack. Two silos running side by side is expensive, and consolidation calls for a modernisation plan.
A monolith running on a single server that cannot grow horizontally, a database that can no longer handle transaction volumes, or a desktop app unsuited to remote work. Scale calls for a new architecture.
No two legacy stacks are alike. Modernising a mainframe requires something entirely different from replatforming a Delphi application. The categories below cover most of what we see in the market.
Banks and insurers in particular still run core systems on mainframes. Modernisation often combines a phased extraction (rebuild or replace) with temporary façades, so modern channels can be developed before the mainframe is retired.
Often ERP-like systems that have run stably for decades. Replatform to Linux or containers while preserving the data models, or rebuild gradually with the RPG application as the source of truth during the transition.
Construction firms, manufacturers and ICT vendors often rely on sector-specific tools. We replatform these to the web or a modern desktop (modern .NET, Electron or native web apps), preserving the workflows users are familiar with.
Surprisingly many B2B portals still run on these. We modernise to Node.js, .NET, PHP 8 or a modern front-end stack, often with an API layer between old and new so that migration can proceed incrementally.
Usually smaller applications that have quietly become critical to the organisation. Migration to a modern back end with an API layer, often combined with a new web front end.
Not old in years, but outdated in architecture: not horizontally scalable, no CI/CD, no observability. Replatform to containers, infrastructure as code and modern deployment pipelines.
Gartner's 6R strategy is the industry standard for modernisation decisions. We use an expanded version with eight options, because reality sometimes simply calls for more nuance.
Not every legacy system needs a successor. In a typical portfolio, a considerable share can simply be retired. That is not failure; it is clearing out. Whatever still needs to go, we archive in line with retention requirements.
The system is old but works well and sees little change. No action required. We do, however, monitor for risk (end-of-life of the stack, single-point-of-failure personnel) and schedule a review point in the roadmap.
Moving the application from a physical server or VM to a cloud VM, without changing the code. Quick and inexpensive, but the old architecture remains. Useful as an interim step to remove hardware risk.
The code remains largely intact but moves to a container, PaaS database or managed service. Greater operational gain than rehosting, with limited code impact. Often the sweet spot for desktop and web legacy.
Modernising the code internally — modularising it, making it testable, replacing dependencies — without changing its behaviour. Important before a rebuild if a lot of undocumented logic remains.
Sometimes the old system does something the market already offers as standard SaaS (CRM, helpdesk, expense management). Replacing it with a commercial product is then more rational than building it yourself. We guide the selection and data migration.
Building the application from scratch, with the same business functionality but a modern stack and architecture. For systems that are strategic and business-critical, and where refactoring is no longer cost-effective.
Not only replacing the technology but also revisiting the scope. Sometimes an inventory reveals that the old system does what was needed in 2005, but the working process has since changed. In that case, we build not the old version but the new one.
There are good automated translation tools for legacy systems: Modulus, Asysco AMT (COBOL to .NET), Heirloom for mainframes. We use them where they fit. However, in a number of scenarios pure automation falls short and bespoke development is the right route.
Automated translation transforms syntax: COBOL code into C# code. But the real value of a legacy system often lies in unspoken business rules that have crept into the code over the years. Those rarely survive a one-shot translation.
For applications where your competitive advantage lies, you want more than a one-to-one conversion. You want the modernisation to be an upgrade of what the application can do at the same time — and that calls for design, not translation.
In portfolio projects, several migrations run in parallel — each with its own tooling, its own supplier and its own risk. Someone has to orchestrate them. That is a role no tool can fill.
Healthcare with NEN 7510, finance with DORA, critical infrastructure with NIS2. An audit trail cannot be retrofitted afterwards — it must be built into the migration from the very first sprint.
An automated translation produces something. But when the original developer has left and the current administrator has no idea how the old system worked, nobody can objectively judge whether the result is correct. We arrange that reverse engineering.
Translator X can migrate application A, but application A talks to B, C and D. Those integrations must move along with it. Bespoke development and orchestration are then cheaper than six separate migration projects running side by side.
We map every application: tech stack, hosting, users, integrations, licences, and maintenance costs. At the same time, we identify which business processes run on them and who owns them. It often becomes clear at this stage that 10 to 20 per cent of the portfolio can simply be retired.
For each application, we weigh Total Cost of Ownership against business impact. High-impact, high-cost systems are prioritised; low-impact, low-cost systems can stay as they are. The outcome is a visual matrix that leadership can use to steer decisions.
For each application, we select the right strategy from the extended 6R set (retire, retain, rehost, replatform, refactor, repurchase, rebuild, replace). We then sequence the work: which dependencies dictate the order, where risk-reduction wins come first, and how we spread the workload across your IT organisation.
For systems we plan to refactor or rebuild, we first create a test safety net that captures how they currently behave. This includes automated end-to-end tests and, where necessary, screen recordings of existing user workflows. The aim is to prevent unwritten business rules from disappearing during migration.
No big bang. We place a façade in front of the old system and migrate functionality piece by piece to the new stack. Users notice little change, and the organisation keeps working. Only once the last piece of functionality has been migrated do we switch off the old system.
Where relevant, the new application moves to the cloud (AWS, Azure, GCP) or a container platform (Kubernetes, OpenShift). All infrastructure is defined in Terraform or Pulumi, deployments run through CI/CD, and monitoring uses OpenTelemetry. Staying on-premises is also an option; sometimes it is the right choice.
The final phase. We train your operations team, write runbooks for incidents and planned changes, and arrange knowledge transfer on the business logic we uncovered along the way. After that, you can choose: manage it yourselves, or we run it for a fixed monthly fee.
What clients typically want to know before starting a modernisation project.
A free, no-obligation 30-minute introductory call. Tell us which systems are holding you back, which legislation is coming your way and which part of your team still has a grip on the legacy stack. We'll come back with a first direction, and we'll be honest if it isn't the right fit for us. Would you like to look more broadly first? See also our page on platform modernisation consultancy or on building enterprise software.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
