Services
We replace ageing business-critical systems incrementally: VB6 and Delphi desktop applications, classic ASP and WebForms sites, unsupported .NET Framework services, and the on-premise SQL Server databases with fifteen years of stored procedures behind them.
The system keeps running throughout. Each capability moves behind a routing layer, and each move can be reversed on its own without unwinding the programme.
When you need this
What we build
Our approach
The first question is not how to rebuild a screen but whether anyone still uses it. We instrument the legacy application and its database to establish real usage over several weeks. In most estates, a meaningful share of screens, reports and batch jobs turn out to be unused, and retiring them is the cheapest modernisation available.
A routing layer sits in front of the old application. One capability at a time is implemented in the new system and its traffic redirected, starting with an area that is low risk but genuinely used, so the mechanism is proven before it carries anything critical. There is no single cutover weekend, and no point at which the whole business depends on one deployment succeeding.
Legacy behaviour is captured as executable tests first — including behaviour that is technically wrong but that downstream processes depend on. Each such case is documented and put to the business as a decision: preserve it, or fix it and change the downstream process deliberately. Discovering these during parallel running is far more expensive.
For every table in scope we state which system owns it at each stage of the programme, how the other side is kept consistent, and how divergence is detected. The synchronisation layer is built as disposable code with a removal date, because a transitional integration left in place for years becomes the next legacy problem.
A module is not finished when the replacement goes live. It is finished when the old code paths are removed, the licences are cancelled, the server is shut down and the archived data is verified as readable. We plan and schedule that work rather than leaving both systems running indefinitely.
Technology
Legacy estates we work in
Target stacks
Data
Platform
Applied by industry
Replacing locally installed practice tooling and Access databases with supported web systems, while keeping EMIS Web, SystmOne and Dentally integrations live and documenting clinical risk under DCB0160.
Modernising settlement and billing engines where Elexon data flow handling sits in decades of stored procedures, using parallel running to prove figures match before switching.
Moving on-premise site servers and overnight polling to centrally hosted services, with EPOS integrations rebuilt as APIs rather than file drops.
Replacing desktop lettings and property management applications while retaining Rightmove, Zoopla and Reapit feeds, and migrating tenancy history without losing audit trail.
Retiring bespoke matter and time systems built on unsupported frameworks, preserving billing history and regulatory records with a verified archive.
Typical engagement
Questions
In parts, in almost every case. We put a routing layer in front of the legacy application and move one capability at a time behind it, so the old and new systems run together and each move is individually reversible. Full rewrites are only reasonable for small systems with a stable, well-understood scope.
No, it is the normal starting condition. We recover behaviour from the artefacts that survive: database schema and stored procedures, the compiled application's observable behaviour, batch job schedules, and production logs. Where behaviour cannot be recovered, we characterise it with tests against the live system before touching it.
Yes, and you should. A programme that freezes the business for eighteen months loses the business's support. We agree a change protocol at the start: which areas are frozen because they are actively being moved, and which remain open, with the legacy team and our pod working from one backlog.
It moves in stages alongside the capabilities that use it. During transition, a synchronisation layer keeps the legacy and new stores consistent with one defined owner per table, and reconciliation runs on a schedule with alerting on divergence. The synchronisation layer is deliberately temporary and is removed as each capability completes.
Parallel running with output comparison. For calculation-heavy areas — billing, settlement, pricing, entitlement — we run both systems against the same inputs and compare results record by record until the difference is either zero or an explained, signed-off legacy defect.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us