Modernise legacy systems without stopping the business that runs on them

The strangler pattern replaces a legacy system gradually by placing a routing or API layer in front of it and moving one capability at a time to new services. Requests for migrated features go to the new code, while everything else still reaches the old system. Over time the legacy application handles less and less until it can be switched off, without one risky cut-over.

In most cases, modernise in phases. A full rewrite has to reproduce years of undocumented behaviour before it delivers any value, and the business keeps changing while it is built. A phased approach delivers improvements early, limits the impact of mistakes and lets you pause or change direction between phases. A rewrite can make sense for small systems whose rules are well understood.

Yes, and a phased approach is what makes that possible. Because the legacy system stays live, urgent changes can still be made there. For each phase we agree a simple rule: features that touch a capability being migrated are built in the new service, while everything else continues as before. One shared backlog shows both streams, so the business can see the trade-off when a feature request would delay a migration slice.

We make one system the writer for each type of record at any moment and copy its changes to the other through change data capture or events. Because the new schema is usually redesigned, every change passes through a translation step that maps old codes and structures to the new model. When a capability moves, write ownership moves with it. Reconciliation reports compare key values in both databases, and differences are resolved before the next slice moves.

The legacy system stays in service until each replacement has proven itself. New components run alongside it, often in shadow mode where both produce results and we compare them, before real traffic moves across. Cut-overs are scheduled around your business calendar, controlled by feature flags or routing rules that can be reversed quickly, and backed by a rehearsed rollback plan.

We reconstruct the documentation from the system itself. That means reading the code and database schema, tracing integrations, analysing logs to see which features are actually used, and interviewing the people who operate and support it. We then write characterisation tests that capture current behaviour, quirks included, so any change in output during modernisation is detected rather than assumed.

Duration depends on the size of the system, the state of its data, the number of integrations and how much change the business can absorb at once. Rather than one long project, we plan a series of phases, each delivering working software and retiring part of the legacy estate. The first phase is usually the assessment and safety net, followed by one low-risk capability that proves the approach.

Cost depends on the route chosen for each component, the volume and quality of data, integration complexity and testing needs. Re-hosting is usually far less expensive than replacing a system outright. We start with a scoped assessment, then give a fixed quote for the first phase and an estimate for the wider roadmap, so you can fund modernisation in steps tied to visible results.

No. Modernisation is about making software maintainable and changeable, and that can happen on your existing servers. Many organisations do choose AWS, Microsoft Azure or Google Cloud along the way, because managed databases, containers and automated scaling reduce operational work. We recommend a hosting target based on data residency, existing contracts, in-house skills and running cost, not by default.

Usually, yes. Modernisation depends less on the original language than on whether we can run the system in a test environment, read its data and observe its behaviour. Older PHP and MySQL applications are familiar territory for our team. For Java, .NET or desktop applications, we assess the code during discovery and say plainly where specialist knowledge of the original platform is needed and how the plan accounts for it.

Usually only for the parts that change visibly. We keep familiar workflows where they work, involve key users in reviewing each phase every one to two weeks, and introduce new screens department by department rather than all at once. Each release comes with short guides and a support window, and feedback from early users shapes the next phase before wider rollout.

Your team can, and we plan the handover from the first phase. If you have in-house developers, they pair with ours on migrated components. The business rules recovered from the legacy code are kept as a written catalogue, and the characterisation tests become the regression suite for the new system. Architecture decisions, runbooks and infrastructure code live in your repositories and cloud accounts. If you prefer, we continue retiring the remaining legacy components in later phases.