HOME/MODERNISATION

Modernisation

Replace the system underneath you without stopping the business

We modernise software that cannot be switched off — moving capability out of an ageing system one slice at a time, with the old and new running side by side until the new one has earned the traffic. No big-bang cutover weekend, and no rewrite that discovers your business rules the hard way.

Book a free consultation See our work

A senior engineer replies within 24 hours — not a sales rep.

Why the old system is still running

The specification is the source code

Twelve years of decisions are encoded in conditionals nobody documented — the tax edge case for one region, the discount a former director approved, the retry that exists because a supplier's API used to time out. A rewrite from requirements will miss them, and you will find out at month end when a customer is invoiced wrongly.

It is the thing that takes the money

Whatever else is true, orders flow through it, payroll depends on it, or the warehouse cannot dispatch without it. That makes every change a continuity question first and an engineering question second. Most modernisation stalls here: the risk of touching it is obvious and immediate, while the cost of not touching it is spread thinly across years.

Nobody left can safely change it

The engineer who knew the codebase retired or moved on, and the framework version stopped receiving security patches some time before that. Hiring for it is slow and expensive. So changes get made cautiously by people reading unfamiliar code, which is exactly the condition under which regressions appear.

Everything talks to it, badly

A nightly CSV over SFTP. A screen-scraping script somebody wrote as a stopgap years ago. Two systems writing to the same table directly because there was never an API. Each of these is a hidden dependency that a migration will break, and none of them appear in any architecture diagram you currently have.

How we approach modernisation

The goal is not a new system. It is a business that keeps operating while the system underneath it changes, with a way to stop or reverse at every step. That constraint shapes every technical decision we make.

Strangler fig, not a rewrite

We put a routing layer in front of the existing system, then move capability behind it one slice at a time. Each slice goes to production on its own, gets used by real traffic, and can be routed back to the old path in minutes if it misbehaves. The legacy system shrinks gradually until what remains is small enough to retire without ceremony.

Recover the business rules before touching them

Old code is read carefully and, where behaviour matters, pinned down with characterisation tests that capture what the system currently does — including the parts that are arguably wrong. Those rules are written into a catalogue your own people review, which is often the first time the business has seen its logic stated plainly. Only then do we decide what to keep, fix or drop.

Dual-run and compare before you commit

For anything with money or compliance attached, the new implementation runs alongside the old on the same inputs and we compare outputs until the differences are all explained. Discrepancies usually reveal an undocumented rule rather than a bug. Cutover then becomes a routing change you already have evidence for, not an act of faith on a Saturday night.

Do not modernise what you can retire

Before rebuilding a screen, we check whether anyone has opened it in the last year. Legacy systems accumulate features that survived because deleting them was never anyone's job, and carrying them forward multiplies the work for no return. Instrumenting real usage first routinely cuts the scope, and a smaller migration is a safer one.

What this covers

Pick the piece you need, or bring us the problem and we'll tell you which applies.

Legacy System Modernisation

Ageing applications moved onto a supported, maintainable stack without a rewrite that puts the business at risk. We start by recovering what the current system actually does — the documented behaviour and the accidental behaviour people now depend on — then migrate capability incrementally behind a routing layer, with the old path available as a rollback until the new one has proved itself on real traffic. Where a re-platform is enough, we do that instead of rebuilding; where the data model is the real constraint, we say so early rather than gold-plating the surface.

Codebase and usage analysis that identifies what is genuinely in use and what can be retired
Business rules extracted into a reviewable catalogue and pinned with characterisation tests
Incremental migration behind a facade, with per-slice feature flags and a rollback path
Database modernisation with change-data-capture so old and new can run in parallel
Decommissioning done properly: archived data, released licences, documented runbooks

Enterprise Integrations

Connecting the systems you are keeping — ERP, CRM, warehouse, billing, e-commerce, payroll — so a record entered once stops being re-keyed twice more. Most integration pain is not the connection itself but what happens when it fails: a partial sync at 3am, a duplicate created by a retry, two systems each convinced they hold the current version. We design for those cases first, with idempotent handling, explicit conflict rules and alerting that tells a named person something needs attention.

API and event-driven integration using REST, webhooks and message queues such as Kafka or RabbitMQ
Legacy interfaces handled as they are: SOAP, IDocs, EDI, flat files and scheduled SFTP drops
Idempotency, retries and dead-letter handling so a failed message is visible rather than lost
Reconciliation jobs and dashboards that prove two systems still agree, instead of assuming it
Middleware or point-to-point chosen on the number of endpoints, not on architectural fashion

The stack we build on

Chosen to fit the problem — not because it's what we used last time.

Legacy stacks we work with

Java EE
.NET Framework
ASP.NET Web Forms
PHP
VB.NET
Oracle Database
SQL Server

Target stack

Spring Boot
.NET
Node.js
TypeScript
Python
React
PostgreSQL

Integration & messaging

REST APIs
GraphQL
gRPC
Apache Kafka
RabbitMQ
Debezium
SFTP & EDI

Migration & operations

Docker
Kubernetes
AWS
Azure
Terraform
OpenTelemetry
Grafana

How we'll work together

Every stage ends with something in your hands — not a status update.

01
Read the system as it actually is
We trace the code, the database and the traffic rather than relying on documentation that stopped being true years ago. Instrumentation shows which features are genuinely used, and interviews with the people who operate it surface the rules that never made it into a ticket.
You get: A dependency and integration map including the undocumented ones, a catalogue of recovered business rules, and a ranked list of what to migrate, rewrite or retire.
02
Put a seam in front of it
Before anything moves, we introduce a facade the callers talk to instead of the legacy system directly, and build a safety net of characterisation tests around the behaviour we intend to preserve. This step ships on its own and changes nothing the business can feel.
You get: A routing layer live in production, a characterisation test suite pinning current behaviour, and a first migration slice scoped with its rollback plan.
03
Move capability slice by slice
Each slice is built against the recovered rules, dual-run where correctness is critical, and released behind a flag to a fraction of traffic first. We reconcile outputs, resolve every difference, then shift the rest of the traffic across and delete the legacy path for that slice.
You get: Each slice live in production with its flag and rollback, comparison reports for dual-run periods, and updated architecture notes as the seam moves.
04
Retire the old system deliberately
Decommissioning is planned work, not something that happens by neglect. We archive the historical data in a readable, queryable form, confirm nothing still calls the old endpoints, then shut it down and release the licences and infrastructure it was consuming.
You get: A decommission checklist signed off per dependency, an archived read-only data set with a retention plan, and operational runbooks handed to your team.

Where we've applied this

Financial services

Core ledger, statement and settlement logic moved off ageing platforms with dual-run reconciliation, because a rounding difference here is a regulatory conversation.

Logistics

Dispatch, tracking and carrier interfaces replaced while vehicles are on the road, with the old integrations kept alive until each partner has moved to the new API.

Healthcare

Patient administration and clinical record systems migrated under strict access control, with audit trails preserved intact across the boundary between old and new.

Manufacturing

Shop-floor and MES-adjacent applications re-platformed without pausing production, including interfaces to machine controllers that only speak file drops.

Retail

Ordering, pricing and fulfilment logic pulled out of a monolith into services that can be released independently, so peak trading is no longer a change freeze.

Public sector & education

Long-lived administrative systems modernised in stages that fit annual cycles, with historical records kept accessible for the retention periods you answer to.

Clients we've built for

Real products, in production, with real users on them.

Sagor

Lush

OrbiSim

Jim's Group

Questions buyers ask us

Why not just rewrite it from scratch?

Because a rewrite has to be finished before it is worth anything, and the requirements it is built from are usually incomplete in ways nobody discovers until go-live. Incremental migration puts value in production early, keeps the old system available as a fallback, and lets you stop between slices if priorities change. We will consider a full rewrite when the system is small, well understood, or so far past repair that the seam costs more than the rebuild.

What if nobody here understands the old code any more?

That is the normal starting position and it is workable. We read the code, trace live traffic, and reconstruct behaviour as characterisation tests that capture what it currently does without needing to know why. Your operations staff then review the recovered rules — they usually recognise the behaviour even when they have never seen the logic. It is slower than being handed a specification, but it is far safer than guessing.

How do you avoid breaking things during the migration?

Nothing moves without a way back. Slices go live behind flags with a fraction of traffic first, anything financial or regulated runs in parallel with the old implementation until every output difference is explained, and hidden dependencies are found in discovery rather than at cutover. We also insist on decent observability before the first slice, because you cannot migrate safely into a system you cannot see.

How long does modernisation take and what drives the cost?

The main drivers are how tangled the data model is, how many undocumented rules have to be recovered, and how many other systems depend on the one you are changing. Test coverage on the existing code helps enormously when it exists. First slices typically reach production within a few months; a full programme runs longer by design, and you get value from each stage rather than only at the end.

Can you work with our in-house team rather than replacing them?

Yes, and on modernisation work it is usually the better arrangement — your people hold context we would otherwise spend months rebuilding. We can embed engineers into your team and your process, take a workstream end to end, or pair deliberately so the knowledge stays with you. Either way the intent is that your team can maintain what we leave behind.

What happens to the old system and its data?

It gets decommissioned on purpose rather than left running because nobody is sure. Once we have confirmed no remaining caller depends on it, historical data is archived in a queryable form that meets your retention obligations, licences and infrastructure are released, and your team receives the runbooks and documentation. You own the new code, the pipelines and the archive in full.

Tell us which system you are afraid to touch

Describe what it does, roughly how old it is, and what would break if it stopped for a day. A senior engineer replies within one business day, and the first call is about sequencing and risk — not a pitch for a rewrite.

Book a free consultation Browse all services