Strangler-fig sequencing
A written order of work that routes traffic gradually to new components while the old ones keep serving, so every step is reversible and no step needs a downtime window.
Infrastructure & Cloud
Legacy Application Modernisation
Untangle the monolith and the hand-built VM estate one piece at a time.
The work
What this actually does
Big-bang rewrites fail often enough that we do not propose them. Instead we find the seams in the existing system — the module with the clearest boundary, the feature with the least tangled data — and move one thing at a time, keeping the old path working until the new one is proven under real traffic.
The awkward parts are usually the database and the batch jobs. We plan schema changes that work for both old and new code, run the two side by side where necessary, and only decommission the legacy component once its traffic has been at zero for a period you agree. Some systems should be stabilised and left alone, and we will say so.
If any of these sound familiar
- Every change requires a release train and a weekend outage
- The original authors have left and the code has no tests
- A single database is shared by six applications nobody can separate
- The rewrite has been eighteen months in and still is not live
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Data and schema strategy
Expand-contract schema changes planned so old and new code can run against the same database, with backfill jobs and a defined point where the legacy columns are dropped.
Containerising existing workloads
Applications packaged into images without rewriting them first, which usually removes the hand-built host drift and makes the estate deployable by a pipeline rather than a person.
Interface and API extraction
Stable interfaces placed in front of legacy code so the internals can be replaced later without every consumer noticing, which is what makes incremental work actually incremental.
Risk and freeze control
Each migration step has a go and no-go check, a rollback and a named owner, and we agree in advance which components are too risky to touch this year.
Decommissioning plan
A dated list of what is switched off, in what order, and what evidence is needed first, because the savings only appear when the old servers are actually gone.
What changes
What teams typically see
1 seamOpened per migration step
0Big-bang cutover weekends
6 monthsTypical first decommission
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Component inventory with dependencies and risk ratings
- Sequenced migration plan showing reversible steps
- Schema change and backfill scripts with rollback
- Container build pipeline for the replatformed apps
- Decommissioning checklist with dates and owners
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
Docker
Kubernetes
Terraform
Java
.NET
PostgreSQL
GitLab
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Map the tangle
We trace calls, database tables and batch schedules across the estate, which produces the dependency picture most teams have never had written down.
- 02
Choose the first seam
The first component is picked for low coupling and visible value, not for architectural elegance, because the point is to prove the approach before the difficult work starts.
- 03
Run both paths
Old and new coexist behind routing or a feature flag, with metrics comparing them, until you are confident enough to send all the traffic to the new version.
- 04
Retire the old estate
Once a component has been quiet for the agreed period we remove it, cancel its infrastructure and update the runbooks, so the saving shows on the bill.
Questions
Asked before we start
Why not just rewrite it properly?
Because rewrites run long, deliver value late and lose the operational knowledge embedded in the current system. We will support a rewrite when the existing code genuinely cannot be extended, but that is a smaller set of cases than most estimates assume.
How do you handle a shared database?
Carefully. Shared schemas are usually the hardest constraint, so we introduce an interface or an API in front of the data before splitting anything, and the split itself is planned as a separate piece of work with its own rollback.
Will this slow down feature delivery?
Some quarters, yes, because the same engineers are moving components and shipping features. We sequence the work so a visible improvement lands early, and we keep the migration backlog small enough that it does not become a second full-time job.
What if the application cannot be containerised?
Some cannot, particularly anything with a hardware dependency or an unsupported runtime. For those we stabilise, isolate and document rather than force a migration, and we revisit the decision when the vendor releases a supported path.
Infrastructure & Cloud
Often needed alongside this
Infrastructure & Cloud
Cloud Architecture & Migration
Well-architected landing zones and migrations that move workloads without moving your risk profile.
- AWS, Azure and Google Cloud landing zones
- Lift-and-shift, replatform and re-architect paths
- Network, IAM and multi-account structure design
Platform & Containers
Docker & Containerization
Small, secure, reproducible images with builds fast enough that nobody avoids changing the Dockerfile.
- Multi-stage builds and layer cache optimisation
- Distroless and non-root runtime images
- Local development parity with production
Networking & Data
Database DevOps & Data Migrations
Schema changes shipped through the pipeline with rollback plans, rather than run by hand at midnight.
- Versioned migrations in CI/CD with review
- Zero-downtime, expand-contract schema changes
- Replication, failover and read-scaling design
Worth a conversation about Legacy Application Modernisation?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.