Estate-aware
Modernisation starts with topology discovery, not per-repo refactor. Every other capability operates against what discovery surfaces.
Context-aware modernisation platform
Legacy digital transformation that rebuilds. Not patches.
Most enterprise transformation today is cosmetic — a new UI wrapped around forty-year-old behaviour, a green-screen terminal recreated inside a web browser without touching the system underneath. CodeDoctor is built for the other kind. The kind that maps the estate, recovers the intent that was never written down, and produces a customer-owned rulebook the next migration starts from.
The CodeDoctor pipeline
01
Topology discovery
→ Estate map
02
Pattern extraction
→ Pattern catalogue
03
Intent validation
→ Confirmed intent
04
Rulebook
→ Customer-owned asset
05
Parallel-run verification
→ Proven cutover
Estate → patterns → intent → rulebook → proven cutover. The asset compounds across every migration.
01 — The thesis
Modernisation in isolation creates new tech debt.
Most enterprise transformation today is cosmetic — a new UI wrapped around forty-year-old behaviour. But the deeper failure is what happens when teams actually do rebuild: they create new debt while paying off the old.
Every new microservice reimplements the same primitives the last one did. No shared libraries. No shared error handling. No shared observability. No shared validation. The modernised codebase looks new, but it has the same fragmentation as the legacy estate it replaced — just spread across more repositories.
The industry thinks the bottleneck is writing code. We don't. The bottleneck is understanding what should be shared across the estate, so the modernisation programme produces a coherent system instead of a collection of independent projects. That's the gap CodeDoctor was built to close.
The best developer reduces code and complexity. They do not add more of it.
02 — Methodology, proven at scale
The corpus underneath the platform.
Before talking to a customer about their estate, we built ours. Five hundred million lines of code across legacy enterprise and UK public-sector codebases, structured and analysed. Every assumption CodeDoctor makes is anchored against real precedent.
500M+
Lines of code analysed across legacy enterprise and modern target corpus
27,000
Real-world repositories spanning Java, .NET, COBOL, Python, Ruby, Node
48
UK government organisations covered — the largest public modern-target corpus
177,047
Routes extracted across 16 frameworks. 64,155 infrastructure resources mapped.
03 — Where we sit
Five capabilities together. The combination is uncontested.
Each capability exists somewhere else in the modernisation tooling landscape. The combination, applied as one methodology against a customer's estate, does not.
Intent-aware
The annotation flow captures the constraints that live outside the code — regulatory addenda, runbooks, institutional memory. The field no other tool captures.
Vendor-agnostic
Any cloud, any LLM, any target stack. Terraform-compliant output across AWS, Azure, GCP, Kubernetes, on-premises.
Customer-owned rulebook
Your dictionary of legacy-to-modern equivalences. It compounds across the programme. You keep it. The next migration starts from where the last one ended.
04 — Why modernisation fails
Three failures, every time.
After two decades inside large transformation programmes, the same three failures show up — across banks, government departments, and large enterprise estates. CodeDoctor was built to close each.
i.
Estate blindness
Most large organisations don't know what they're running. Which infrastructure drifted, which services are orphaned, which dependencies are critical. And just as critical — they don't know which patterns are duplicated across services, which primitives are reinvented every time, which standards exist on paper but nowhere in production. You cannot modernise what you cannot see.
ii.
Intent loss
The code survives. The intent doesn't. The architect leaves. The regulator changes a rule. A migration removes a workaround nobody documented. Five years later nobody understands why the system behaves the way it does.
iii.
Measurement distortion
Large programmes reward visible activity — commits, services, lines of code. The organisation optimises for producing more of them. Even when complexity is exploding underneath.
05 — How CodeDoctor works
From estate to running system — proven before cutover.
Before we tell you what it does, let us tell you what it doesn't. We do not mind-read your codebase. We don't have a magic bullet for intent extraction. The intent was never fully in the code to begin with — that's the whole problem. What we built is a methodology that turns the institutional knowledge in people's heads into a structured, machine-readable asset the customer owns — then compiles it to a running modern system and proves it behaves identically before anything is switched over.
01
Topology discovery
CodeDoctor reads what's already in place. Infrastructure-as-Code — Terraform, OpenTofu, CloudFormation, Bicep. Running Kubernetes state through the API. Cloud-account inventory through AWS Config, Azure Resource Graph, GCP Asset Inventory. We merge them into one canonical picture of the estate.
Deliverable:
In-sync, drifted, orphaned, removed. For most organisations, the first coherent picture they've had of their own estate.
02
Pattern extraction — a deterministic graph, reasoned over by AI
Two layers. First, compiler-grade analysis builds a deterministic relation graph of the estate — full type resolution, call-graph and data-flow, every edge traceable to source and reproducible across runs. Then AI reasons over that verified graph: recognising the same pattern expressed five different ways across services, matching a constrained journey to every other that shares its constraint, surfacing the indirect couplings ordinary call-graphs miss — services that talk through a shared database table instead of a direct call. The facts are extracted deterministically and can be audited; the intelligence reasons over ground truth, not raw code. We extract first, reason second. And because it needs no working build, it runs where legacy lives hardest — abandoned toolchains, dead dependency registries, air-gapped estates where build-dependent tools can't even start.
Deliverable:
Pattern catalogue with full provenance. Deterministic. Reproducible across runs.
03
Intent validation
Because code alone does not contain the whole truth. For every pattern surfaced, a structured prompt goes to the person who still holds the knowledge — the engineer, the SME, the compliance officer. The platform pre-populates what the code seems to mean. The human confirms it, corrects it, or adds what was never written down.
Principle:
AI surfaces patterns. Humans confirm intent. We assume nothing.
04
The rulebook
A structured, machine-readable rulebook. Every confirmed pattern, every exception, every standardisation decision — with its provenance. This is where CodeDoctor is fundamentally different from anything else. We don't copy code from one language to another. We extract intent and encode it in a language-agnostic intermediate format. That format compiles to any language, any framework, any cloud.
Deliverable:
The customer-owned rulebook. The asset compounds across every migration. The next one starts cheaper.
05
Generation & parallel-run verification
The rulebook compiles to the target stack and lands in a new repository and a new environment — the legacy system is never edited in place. Then production traffic is mirrored to both old and new. Every external call is an addressable dependency in our model, so the entire blast radius is redirected to a recording mock stack — no double emails, no live queue fired twice. We diff the behaviour of both systems under real traffic and surface every divergence as an edge-case worklist. Cutover happens only when behaviour matches.
Principle:
We don't ask you to trust the transformation. We run it beside the original under real traffic and prove behavioural equivalence first.
06 — Platform capabilities
Seven capabilities, composed into one platform.
Each capability is read-deep on its own page. Together they form the methodology applied during every CodeDoctor engagement.
Topology discovery
The estate, mapped. IaC, running Kubernetes state, and cloud-account inventory merged into one canonical model. Drift, orphans, and dead resources surfaced.
Pattern extraction
A deterministic relation graph built by compiler-grade analysis — type resolution, call-graph, data-flow, every edge traceable. Then AI reasons over verified ground truth, not raw code. We extract first, reason second.
Visual target stack canvas
Non-technical operators define target architecture without writing IaC or YAML. The canvas becomes the spec the platform generates against.
Bespoke runtime
An MCP-native target stack. Every route exposed as an MCP tool by construction. The modernised estate is AI-orchestrable from day one.
Vendor-agnostic IR
Bidirectional intermediate representation. Generates target IaC across AWS, Azure, GCP, Kubernetes. Ingests existing IaC into the same model.
Database logic extraction
The business logic legacy systems hide in the database — stored procedures, triggers, functions, scheduled jobs, view DDL — lifted into the same model as the application code. Source-only tools never see it. We treat the database as a first-class source of intent, not a black box behind the app.
Data governance
PII tagging at the inventory level. Log sanitisation generated by middleware. Per-jurisdiction routing. Practitioner-built, not theoretical.
07 — How we compare
The capabilities most enterprise buyers actually evaluate.
Every platform in the modernisation tooling landscape has its sweet spot. Here is how CodeDoctor maps against the named alternatives, on the capabilities that drive an enterprise buying decision.
| Capability | CodeDoctor | AWS Transform | Google Mainframe | MS Copilot | IBM watsonx Z | Moderne | Mech. Orchard |
|---|---|---|---|---|---|---|---|
| Deterministic pattern extraction static analysis · function-call extraction · relation graphs · auditable · no LLM hallucination | ✓ | — | — | — | ✓ | ✓ | behavioural |
| Works on un-buildable & air-gapped source abandoned toolchains · dead dependency registries · no outbound network | ✓ | — | — | — | — | — | via runtime obs. |
| Never executes your source or build static read only · no build script or plugin execution in the analysis environment | ✓ | — | — | — | — | — | — |
| Database logic extraction PL/SQL · stored procedures · triggers · DB-resident business logic | ✓ | — | — | — | DB2 / Z only | — | — |
| Out-of-code intent extraction regulatory addenda · runbooks · institutional memory | ✓ | — | — | — | — | — | via runtime obs. |
| Estate-wide infrastructure discovery IaC + running Kubernetes + cloud-account state, reconciled | ✓ | AWS only | — | Azure only | IBM Z only | — | — |
| Cross-codebase pattern standardisation shared libraries · shared primitives · shared cross-cutting concerns across services | ✓ | — | — | — | — | ✓ | — |
| Customer-owned portable rulebook language-agnostic intermediate format · exportable asset | ✓ | — | — | — | — | recipes (within-codebase) | — |
| Cloud-agnostic deployment AWS · Azure · GCP · on-prem · air-gapped | ✓ | AWS only | GCP only | Azure only | IBM only | ✓ | ✓ |
| LLM-agnostic any public model · customer-owned pretrained · air-gapped | ✓ | Bedrock | Gemini | Azure OpenAI | watsonx | — | proprietary |
| Multi-language source coverage Java EE · Spring 2.x · .NET Framework · COBOL · Python · Node | ✓ | Java · .NET | COBOL only | Java · .NET | COBOL · PL/I | ✓ | mainframe |
| No proprietary library required no vendor SDK lock-in · no captive runtime | ✓ | — | — | — | — | OSS core | managed |
✓Full support
PartialLimited or scoped
—Not supported or not the focus
Comparison based on public product positioning and documentation as of 2026. Each named platform has its strengths in its own scope; this matrix maps the capabilities most enterprise buyers evaluate during a modernisation programme.
08 — Use cases
Where CodeDoctor earns its keep.
The same methodology, applied to four shapes of the same problem. Each engagement begins with a Discovery assessment scoped to the slice of your estate that matters most.
Legacy modernisation
Java EE, Spring 2.x, non-Spring-Boot Java, .NET Framework, COBOL — modern target stacks with intent preserved, not just syntax translated.
Microservices consolidation
Scattered growth-era services collapsed into a single solid stack with unified observability, error handling, and data governance. Variance deleted at the inventory layer.
Regulatory & jurisdiction compliance
Multi-jurisdiction estates under one governance posture: GDPR, FCA, EBA/DORA, NIS2, CCPA/CPRA, NYDFS Part 500. Audit format co-designed with the regulator.
COBOL — recover decades-lost knowledge
Multi-layer extraction in tandem with your SMEs. Designed for organisations where the original engineers are gone and the institutional knowledge lives in business operators, not developers.
09 — Trust & deployment
Source code never leaves your environment.
The LLM runs inside infrastructure you control. Your jurisdiction, your cloud, your model. Source is read statically and never executed — your legacy build never runs inside the analysis environment. Audit trail compatible with FCA SUP 15, EBA/DORA, NIS2, NYDFS Part 500.
Data flow inside the customer's jurisdiction boundary
Customer jurisdiction
→ Source repository (read-only — never modified)
→ CodeDoctor agent (customer VPC)
→ LLM private endpoint
→ Generated target: new repository + IaC + tests
↓ New environment, deployed for parallel-run verification
The legacy system is read at source and never altered — the modern build lands in a new repository and a new environment, both inside the boundary. CodeDoctor's infrastructure receives audit metadata only — prompt hashes, source URLs, classification events. Never source code or generated artefacts.
AWS Bedrock
VPC endpoint in customer AWS account. Customer-selected region including GovCloud.
Azure OpenAI
Private endpoint in customer Azure tenant. Customer-selected region including Government.
Google Vertex AI
Private endpoint in customer GCP project. Assured Workloads regions supported.
Self-hosted
Customer-owned pretrained model on customer infrastructure. Air-gapped supported.
10 — The team
Built by practitioners who have lived this work.
Our team members bring decades of experience in digital transformation across the following organisations. Data governance, regulator engagement, PII discipline, and audit-trail patterns are practitioner-built, not theoretical.
11 — Join the waitlist
Be first when CodeDoctor opens to design partners.
We're onboarding a small number of regulated and enterprise estates. Register your interest and we'll reach out to scope a discovery assessment as access opens.