The system nobody can see into
Every organisation past a certain age has one: business-critical, poorly understood, and quietly setting the ceiling on how fast anything else can move. Rewriting it from scratch usually fails. The better way through starts by making it understood, then changes it one piece at a time.
You might be here because
Situations we are brought in for
- A critical system runs on a framework or runtime that is past end of life.
- The people who wrote it have left, and the documentation left with them.
- Every estimate gets padded because nobody knows what a change will break.
- A previous rewrite attempt stalled, and the replacement now runs alongside the original.
What you get
Concrete deliverables, not a retainer with a hope attached
System map
A written map of what the system does, what depends on it, and which behaviours are load-bearing versus accidental.
Characterisation tests
Tests that pin down current behaviour — including the bugs downstream systems now rely on — so change becomes safe to attempt.
Incremental replacement
Strangler-fig migration: new code takes over one seam at a time behind a stable interface, with traffic shifted gradually.
Decommission plan
A concrete sequence for retiring the old system, including data retention and the rollback path at every stage.
How it works
Four phases, each with an exit you control
- 01
Map
We read the code, trace the data and interview the people who still hold context. The output is a document your team can use with or without us.
- 02
Stabilise
Tests, monitoring and a repeatable build around the existing system first. You cannot safely change what you cannot observe.
- 03
Replace
Seam by seam, new implementations take over behind feature flags, with the old path kept live until the new one has proven itself.
- 04
Retire
The old system is switched off deliberately, on a planned date, with its data migrated or archived.
Tools we reach for
Chosen per problem, not per fashion
This is what we use most for legacy modernisation. If your team is already productive in something else, we work in that instead — familiarity in your team beats preference in ours.
- TypeScript
- Java
- C#/.NET
- PHP
- Python
- PostgreSQL
- MySQL
- Kafka
Where this usually starts
Technical Audit
Technical Audit
Understanding a system you have inherited, acquired or lost track of
An independent read of a codebase and its infrastructure: what is actually there, what is at risk, and what it will take to fix. Useful before an investment, an acquisition or a rebuild decision.
- Typical duration
- 1–3 weeks
- Commitment
- Fixed scope, fixed fee
Includes
- Codebase, architecture and dependency review
- Infrastructure, deployment and security posture
- Test coverage and release-process assessment
- Key-person and knowledge-concentration risk
- Findings ranked by risk against remediation effort
You keep
- Written audit report
- Risk register with severity ratings
- Remediation roadmap
- Readout session with your team or board
Fee agreed after scoping. No commitment to that conversation.
Common questions
Is a full rewrite ever the right answer?
Occasionally — usually when the system is small, well understood, and the platform underneath it is genuinely unsupportable. It is far rarer than it feels from the inside. We will say so if we think a rewrite is right for you.
We have almost no tests. Is that a blocker?
No. It is the normal starting condition. Characterisation tests are written against observed behaviour rather than intent, so they can be added to a system nobody fully understands yet.
How do you work with the team who maintain it now?
As collaborators, carefully. The engineers keeping a legacy system alive usually hold knowledge that exists nowhere else, and they have often been asking for this work for years. We treat them as the primary source, not as an obstacle.
Related reading
A technical due diligence checklist you can run yourself
The questions we ask when assessing an unfamiliar codebase, in the order we ask them, with what each answer actually tells you.
Other services
Product engineering
Ship the product your roadmap keeps promising — designed, built and maintained.
Platform & infrastructure
Make deploys boring, incidents rare, and cloud spend explainable.
AI & applied ML
Put language models into production without betting the product on a demo.
Custom software
For the process no product on the market actually fits — built once, properly.
SaaS development
Multi-tenancy, billing and onboarding — the unglamorous parts that decide whether it scales.
Web applications
Serious applications in the browser — dashboards, editors, real-time tools that stay fast with real data.
API development
Interfaces other engineers have to live with — versioned, documented and hard to misuse.
Mobile apps
Apps that work on a bad connection, clear store review, and can be shipped weekly.
Next step
Think this is your problem?
Send us the shape of it. We will tell you whether it is a fit, what we would do first, and roughly what that takes.