The system nobody dares touch? We touch it.
Recovering control of systems whose authors are gone: characterise, stabilise, document — then re-engineer with evidence instead of folklore.
- Triage
- Pin behaviour
- Stabilise
- Re-engineer
Respect the running system.
Every legacy system is risky for the same reason: nobody fully knows what it does any more. The people who wrote it have left, the documentation describes a version that was replaced twice, and the tribal knowledge that remains lives in two heads and a folder of scripts. So the organisation looks away. Changes are batched into a release weekend, the weekend gets longer every year, and eventually a system that still runs the business becomes a system the business is afraid of.
We go the other way. Instrument it, pin its behaviour with tests captured from real traffic, and turn folklore into documentation before changing anything. That order matters: stabilisation is worth more than architecture in the early stages, because a system that crashes twice a week cannot be re-engineered by anyone. Once the estate is quiet and its behaviour is recorded, the evidence tells you which parts are stable assets worth keeping and which are genuine hazards — and the re-engineering that follows usually runs as a strangler-pattern modernisation rather than a rewrite.
It encodes years of decisions, and many of the “bugs” you will find are load-bearing — a rounding rule that matches the regulator’s, a retry that covers for a partner’s flaky endpoint, a field reused for a purpose nobody documented. Deleting them is how re-engineering projects get their reputation.
Four moves, in this order.
The sequence is the method. Skipping straight to re-engineering is what turns a difficult system into an incident report.
System archaeology
Static analysis, runtime tracing and interviews — reconstructing what the system does and, just as important, which parts the business actually uses. Dead code, unused batch jobs and reports nobody has opened in years are found and marked, because scope that can be deleted is scope you never have to migrate. The output is a dependency map and a risk register the business can read.
Golden-master testing
We capture real inputs and outputs at scale from production traffic and recorded batches, then replay them against the system to establish what “correct” currently means. Every future change is judged against that recorded truth rather than against someone’s memory. Where the flows are financial or regulated, the golden master becomes the acceptance evidence for the whole programme.
Stabilise before change
Crash loops, resource leaks, silent job failures and fragile deploys are fixed first — you cannot re-engineer a system that is on fire. Deploys become repeatable and rehearsed, monitoring and alerting are added where there were none, and the top recurring incident causes are engineered out. This phase alone usually returns the team’s evenings, which is what buys the programme its credibility.
Knowledge capture
Architecture documents, decision records and runbooks are written as we learn, not at the end as a deliverable nobody reads. Each one names what the system does, why it does it that way, and what depends on it. The point is that the risk never re-concentrates in one head — including ours, which is why it is written down as we go.
How the work runs, day to day.
A risk register beats an architecture diagram.
The first artefact we produce is not a target architecture. It is an ordered register of what actually goes wrong: which subsystems cause incidents, how often, what each costs in downtime or manual correction, and how many people in the organisation understand them. Some entries turn out to be cheap to fix and expensive to keep — a nightly job with no alerting, a certificate renewed by hand. Others are structural and go into the re-engineering plan. Either way the business gets an order of work it can fund, rather than a picture it has to take on faith.
- Incident history, change history and runtime traces read together, not separately
- Bus factor recorded per subsystem, because a single expert is a risk like any other
- Every entry carries a cost and a proposed move, so the register can be prioritised by finance
Golden masters make the system testable without understanding it first.
You do not need to understand a system to record what it does. We capture representative production inputs — requests, message payloads, batch files — together with the outputs and side effects they produce, and store them as a suite that can be replayed on demand. From that point the system has a safety net: any change that alters a recorded output shows up in the build rather than at month-end. Coverage grows by business value, not by line count, and the flows that carry money, regulatory reporting or customer commitments are covered first.
- Recorded inputs and outputs at production scale, with personal data masked before storage
- Replay in CI, so a change that alters behaviour fails the build rather than the month-end
- Coverage tracked by business flow, with the critical set complete before re-engineering starts
Stabilisation is the part that pays for the rest.
A system that pages someone twice a week consumes the attention the programme needs. So the first engineering work is unglamorous and immediate: make the build reproducible, make the deploy a command rather than a ritual, add monitoring where failures are currently silent, and fix the handful of causes behind most of the incidents. A deploy that no longer needs a release weekend changes what the organisation believes is possible with the system, and the incident-rate trend becomes the number the programme is judged on.
- Reproducible build and deploy pipeline, usually on containers, with a rollback that has been rehearsed
- Monitoring, alerting and log aggregation added where failures were silent — see DevOps & Cloud
- Top incident causes engineered out and the trend published regularly, so the improvement is visible
What each side of the table gets.
A net first, then the refactor.
Your engineers keep ownership of the system throughout. We pair on the archaeology so the map is shared, hand over the golden-master suite as a working tool rather than a report, and do the first stabilisation fixes together. Nothing about the programme depends on us staying.
- Golden-master and characterisation suites running in your CI, in your repositories
- Reproducible builds, containerised where the runtime allows, with Docker and a rehearsed rollback
- Tracing and structured logging added to the flows that matter most
Fewer pages, and a runbook for the ones that remain.
Silent failures become alerts, alerts become runbooks, and runbooks get rehearsed with the people who will be woken by them. The aim is not a dashboard; it is that the next incident is handled by whoever is on call rather than by the one person who knows the system.
- Alerting on the failures that used to be discovered the next morning
- Runbooks written from real incidents, rehearsed with your on-call rota
- Incident-rate baseline and trend published, so improvement is measurable
A verdict in writing, and the evidence under it.
Triage is a separately priced piece of work and ends with a document: what the system does, what it costs to keep running as it is, which parts are assets and which are hazards, and what each option would take. If the honest answer is that a subsystem should be replaced, that is what the document says, with the evidence attached.
- Risk register with cost and proposed move per entry
- Written recommendation — keep, refactor in place, or replace by seam
- Knowledge captured in your documentation, so the dependency on any single person ends
Re-engineering against the instinct to start again.
Four phases, evidence at each gate.
Triage
What breaks, how often, and what it costs — the risk register that orders everything else. We read the code, the incident history and the change log, trace the running system, and interview whoever is left. Triage is a separately priced piece of work and ends with a written verdict, so you are not buying an open-ended archaeology dig.
Pin behaviour
Golden-master and characterisation tests over the flows that matter, captured from real traffic and replayed in CI. Personal data is masked at capture. This is the safety net that makes every later change reversible, and the artefact that tells you what the system actually promises today.
Stabilise
Deploys made repeatable, monitoring added where failures were silent, and the top incident causes engineered out. The aim is that deploys no longer need a release weekend, and the incident trend becomes the programme’s public score. Nothing structural is changed until the estate is quiet.
Re-engineer
With tests as the guardrail: refactor in place where the code is a stable asset, or extract seams where it is a hazard — whichever the evidence supports. Extraction runs to the same discipline as Software Modernisation, with shadow running and rehearsed rollbacks.
What stays in your hands.
- Risk register and dependency map of the estate
- Golden-master test suite over critical flows
- Reproducible build & deploy pipeline
- Architecture documentation and decision records
- Stabilised system with incident-rate baseline and trend
When this is the right call.
Choose legacy re-engineering when the system still runs a meaningful part of the business, when the people who built it are gone, and when the organisation has started routing around it — batching changes, avoiding a module, keeping a manual correction step because nobody trusts the automatic one. It fits estates where the risk is concentrated in one or two heads, where deploys have become events, and where a regulator, an auditor or an acquirer is about to ask questions the current documentation cannot answer. It is also the right first step before any migration: nobody should move a system to the cloud before knowing what it does.
It is the wrong service when the system is small and well understood and the team simply wants to modernise the stack — that is ordinary engineering work. It is wrong when the business capability itself is obsolete and the real question is what should replace it, which belongs in Product Discovery. And it will struggle where the organisation will not release anyone who remembers the system and will not accept a written verdict it disagrees with: the method depends on evidence being allowed to settle arguments.
Frequently asked questions
Where this service usually sits.
Tell us what you’re building.
Describe what exists today and what you need. An engineer reads it and replies in writing with how we would approach it, and the model that fits.