Service · Software development

Replacing legacy software.

Old business software that still runs but nobody dares touch any more. A 1998 FoxPro database, a Delphi application whose builder left years ago, a Lotus Notes system that only works on one laptop. We replace or modernise legacy software without your operations grinding to a halt: phased, with data preserved, and on a timeline that matches the complexity of your existing landscape.

Arrange an introductory call See our work

↻

Legacy is not a technical problem, it is a business risk.

Most organisations we speak to have not postponed out of laziness. They postponed because the old system still runs, because the original supplier is gone, because nobody quite knows anymore what the system does, and because the thought of replacing it creates tension nobody wants to take on. Until the day that keeping that last server alive, or losing the one developer who still understands the code, suddenly threatens the business.

We are used to coming in at exactly that point. An outdated Access file driving the financial administration. An ASP.NET WebForms application still running on Windows Server 2008. An Exact Globe installation that needs to move towards Exact Online migration. Our approach starts with understanding what is there, before we decide how it will be replaced, and which parts can quite happily remain for a few more years.

The most common mistake in legacy replacement is the idea that you can swap the old system for a new one in one go. On any non-trivial project you run into undocumented flows, forgotten integrations and unspoken business rules. That is why we almost always choose a pattern where the old and new systems coexist for a period, and the old one is gradually phased out. That sounds more awkward than a big bang, but in practice it is almost always faster and safer.

How we approach legacy projects.

Strangler-first

Old and new run in parallel, the old is gradually switched off

Discovery phase

We document what is there before we replace it

Data ownership

Full migration with audit trail and rollback path

Build or buy

Assessed module by module, custom build where it truly makes a difference

Five ways to replace legacy software.

Every situation calls for a different approach. Which route suits you depends on the scope, the age of the stack, the availability of documentation and the number of external systems it communicates with. The three clusters below together cover the vast majority of the projects we get involved in.

Approach 01

Strangler pattern: gradual phase-out

The most widely used route for larger systems

The new system grows module by module alongside the old one. We put a routing layer in front of the legacy application, so that each individual part, starting with the simpler modules and moving on to the complex ones, can be redirected to the new codebase once it is ready. The old system keeps running for as long as it holds components that have not yet been replaced, and is switched off once the last flow has been taken over. This approach, described by Martin Fowler as the strangler fig pattern, works particularly well for large applications where a rewrite in one go is either unfeasible or too risky.

In practice, this means your end users may work with two screens for months (or, better still, with a single screen that gradually switches over behind the scenes) while the old system is taken apart step by step. That gives your organisation time to learn the new way of working, without ever having a moment when everything changes at once. No big bang, no weekend when operations grind to a halt, no all-or-nothing risk.

Routing layerModule-by-moduleParallel runningAnti-corruption layerFeature flagsPhased rollout

Approach 02

Rewrite or rebuild with data migration

For compact systems with a clear scope

A full rebuild is only advisable for relatively self-contained systems where the scope is well documented and the number of external integrations remains limited. We build the new application on a modern stack, transfer the data via a validated migration and plan a single cut-over moment at which the old system is switched off. Beforehand, both systems usually run in parallel so that we can carry out comparative tests on real data.

The biggest pitfall with this route is feature creep: during the rebuild, new requests keep coming in because "we're starting over anyway". We keep a tight grip on this by first building a version zero that is functionally equivalent to the existing system, and only then adding improvements in a follow-up project. That avoids scope debates and keeps the cut-over achievable. For situations that resemble this route but call for heavier stack choices, our enterprise software development service may also be relevant.

Full rebuildData migrationCut-over planFeature parity firstValidation suiteRollback scenario

Approach 03

Lift-and-shift, integration layer, or buy-plus-custom

When the old system can partly remain

Not every legacy system needs to be replaced straight away. Sometimes a lift and shift is sufficient: the old application keeps running but is moved to modern infrastructure, wrapped in a new API layer so that other systems can communicate with it through a clean interface. At other times we opt for a SaaS package for the standard part, such as a new accounting or CRM package, and only build the part unique to your organisation as custom software on top. Our digital transformation consultancy often starts with that trade-off.

We make the build-versus-buy decision per module, not for the system as a whole. For your accounting there is usually no reason to build custom software; a good SaaS product is available. For the part that sets your way of working apart, the part that was once built as custom software in the old system and why you never moved to a standard package, we do build custom software. The result is a hybrid landscape in which the standard part requires little maintenance and the custom part genuinely fits your processes.

Lift-and-shiftAPI layer addedBuild-vs-buyHybrid landscapeSaaS integrationCustom add-on

What you have at the end.

A modern system in production, a decommissioned legacy server, and an organisation no longer dependent on a single person who understands the old code.

Production + staging

Two environments, hosted in your own cloud or with us — your choice.

Codebase + architecture documentation

Full source code, build instructions and an overview of all decisions made.

Migration report

Which data has been transferred, which validations have been run, and where discrepancies were found.

Decommissioning plan

How and when the legacy system will be switched off, and which read-only archive will remain.

Managed service (optional)

Monitoring, backups, security patches and ongoing development under a maintenance contract.

When a legacy project becomes unavoidable.

Four situations in which postponing is no longer an option, and in which we are usually first invited to an audit conversation before anything concrete is planned.

Stack

The underlying technology is no longer supported

A FoxPro database, Delphi 7, Visual Basic 6, an outdated version of Lotus Notes, or a COBOL mainframe for which no patches are being released. Microsoft has already ended support for the operating system or runtime years ago. The system still works, but every security incident becomes an acute crisis because there is no vendor left who can help.

Skills

The original developer has gone

The application was once built by a single in-house developer or a small agency that has since closed. No one in your organisation knows the codebase well anymore. Changes take days of investigation before a single line is altered. Onboarding a second developer on the old stack is harder and more expensive than rebuilding on a modern stack.

Vendor

The vendor no longer supports the product

A software package whose vendor is moving towards end-of-life, for example an ERP vendor phasing out its classic on-premise product in favour of a cloud product. Or a niche tool whose manufacturer has been acquired and the product scaled down. You are being pressured to migrate and want to take control of what happens.

Integration

Hidden integrations are strangling the system

Ten other systems communicate with the legacy system through a motley collection of file exports, shared databases, scripts and manual imports. No one has the full picture. A change in the old system quietly breaks three other processes. At this point, the legacy system has effectively become a single point of failure for your entire landscape.

Risks we address explicitly.

Replacing a legacy system is not a purely technical project; it is a change that affects your operations. Four risk categories that we place at the top of every project.

Data

Data loss during migration

Old databases are often full of invalid characters, duplicate records and missing references that never surfaced in production because the old system tolerated them. We carry out a data audit upfront, build a validation suite that compares every migration run against the original, and keep a rollback path open until after the cut-over.

Functionality

Erosion of functionality and forgotten workflows

The old system still did three things that no one was aware of anymore: a nightly export, a specific report for the management team, a one-off correction button. We conduct stakeholder interviews with every user group, run shadow tests in which old and new systems process the same inputs in parallel, and maintain a list of "small buttons" that would otherwise disappear at cut-over.

Continuity

Business disruption during cut-over

A cut-over that goes wrong costs days of productivity and weeks of trust within your team. We phase each transition so that one sub-process moves over at a time, schedule cut-overs for quieter periods in your operations, and keep a rollback script ready. Only once a sub-process has run stably for several days do we take the next step.

Adoption

Resistance from users and key people

People who have worked with the old software for years initially experience a new system as a step backwards, even when it is objectively better. We involve key users from sprint one, build workflows that respect the old shortcuts, and organise training so that the transition does not feel like a loss. No change-management theatre, just practical guidance.

How a legacy project runs.

01Introduction→ 02Discovery→ 03Build & migration→ 04Cut-over & support

Step 01

Introduction

Which system is in place, how old it is, who still knows it, which pain is most urgent. A no-obligation conversation with IT and operations.

Step 02

Discovery and architecture

We document the old system, interview key users, carry out a data audit and choose per module between rewrite, lift-and-shift, build or buy.

Step 03

Build & data migration

Working modules delivered in sprints, running in parallel with the old system, a validation suite for data migration and regular shadow tests.

Step 04

Cut-over & decommissioning

A phased transition per business process, a rollback path on standby, the old system emptied and eventually switched off, with a read-only archive remaining available.

Stacks we move away from and build towards.

We encounter many legacy stacks. Sometimes the existing stack is still sound and we place a modern layer over it; sometimes full replacement is the only route. Alongside this page, our custom software service and the broader overview under software development may also be useful starting points.

Legacy stacks we encounter

FoxProDelphiVB6Lotus NotesAccessCobolPowerBuilderASP.NET WebFormsAS/400 RPGExact Globe

Target stack: frontend and backend

Next.jsAstroReactVueNode.jsPython.NET 8PostgreSQLRedis

Migration, infrastructure & integration

Strangler routingETL pipelinesAuth0Azure ADGCP/AWSTerraformDockerAnti-corruption layer

Frequently asked questions.

How great is the risk that operations grind to a halt during the replacement?

Manageable, provided you opt for a phased approach rather than a big bang. In almost every project we do, the old system runs alongside the new one for months and is only switched off once every business process has demonstrably been taken over and is stable. The main risk is not the technical side but overlooking an undocumented workflow. That is why we conduct stakeholder interviews per user group in advance and run shadow tests in which the old and new systems process the same input, so that discrepancies become visible before cut-over.

How long does a project like this take?

This depends heavily on the scope, the age of the stack, the number of external integrations and how much documentation and knowledge is still available. A compact system with well-documented workflows and few integrations can be replaced within a project of a few sprints. A large, interconnected landscape with multiple modules and dozens of integrations requires a project of several sprints, often phased over a longer period in which one business process at a time goes live. After the discovery phase we give you an honest estimate. Before that discovery, any figure is a guess that could land you in trouble.

Can we keep working with the old system in parallel?

Yes, and in almost every legacy project that is the chosen route. We place a strangler layer in front of the old system so that traffic can be redirected module by module to the new application once it is ready. Your end users may work with both systems for a while or, if we can solve it more cleverly, with a single screen that gradually switches over behind the scenes. That way there is never a moment when everything changes at once, and therefore never a risk that the entire operation depends on one successful cut-over.

How reliable is the data migration?

We start with a data audit of the old system: how many records it holds, which fields are incomplete, which references no longer match, and which data is mission-critical. Based on that, we build a migration pipeline with a validation suite that checks every run against the original, covering record counts, totals, key fields and referential integrity. Until after cut-over, we keep the old system available in read-only mode so that rollback always remains an option. For financial data and data subject to statutory retention obligations, we in any case keep an archive copy of the old system.

What if the original developer has left and nobody understands the code any more?

This is one of the most common starting situations in our legacy projects, and not a blocker. We reverse-engineer the existing system in a discovery phase: code analysis, interviews with end users about how they actually work, screen recordings of daily use, and database analysis to reconstruct the underlying business rules. We accept that we will never recover 100% of the old logic, which is why we also run shadow tests in which the old and new systems operate in parallel, so any discrepancies become visible before cut-over.

What determines the cost of a legacy replacement?

The scope of what is being replaced, the number of integrations with other systems, how well the existing system is documented, the number of user groups, and the complexity of the data migration. A lift-and-shift with an API layer on top is a different project from a full rebuild of a mission-critical ERP. We never give a price before the discovery phase: without visibility into what is there, any figure is a guess. After discovery, you receive an honest estimate with a phased scope, so you can decide which part is tackled first.

Do you replace everything at once or in modules?

Almost always in modules. A full rewrite in one go is only justifiable for compact, well-defined systems. In nearly all other cases we opt for the strangler pattern: the new system grows alongside the old, and the old is gradually phased out. This means that after a few sprints you already have a first sub-process in production, rather than seeing anything only at the end of a long project. It lowers the risk, gives your team time to adjust, and keeps the project manageable.

Do you work together with our internal IT department?

Almost always. Legacy projects almost certainly touch existing systems: ERP, accounting, AD/SSO, file shares, sometimes a legacy WMS or CRM. We work openly with your internal IT team and, where necessary, with external vendors who maintain the adjacent systems. Clear API contracts, documented integrations and an incident runbook are standard. At the end of the project, our code is handed over to your team or we take on maintenance under contract, depending on what you prefer.

Do we retain ownership of the new software?

Yes, entirely. The code, infrastructure, documentation and credentials are in your name. We work in a repository that you manage, or that we hand over at the end of the project. Even if you choose our management service after handover, all code and infrastructure remain yours: management is a service, not vendor lock-in. The same applies to data: you own all records at all times, with a documented export format for future migrations.

Talk to us about your legacy system.

A non-binding introductory conversation of half an hour. We listen to what is running now, where it is causing problems, and what has prompted you to look at it now, even if it turns out that a replacement is not the right route at this point.

Schedule an introductory call Email fabian.vandijk@appfront.nl