Legacy modernisation — Strangler Fig instead of big bang
Step-by-step replacement of legacy applications with the Strangler-fig pattern. Fixed price per module, no big bang, no downtime.
Big-bang migrations fail in 60–80 % of cases. We replace legacy systems module by module, without your business standing still.
When do you need this?
You have a legacy application
(Java EE, .NET monolith, Cobol, classical PHP) that is business-critical but expensive to maintain.
Knowledge about the system sits with 1–2 people
and they will retire soon.
Changes take weeks
instead of days because every change causes regressions.
A complete rewrite
is too expensive, too risky and would mean 2 years of standstill.
What we deliver
As-is analysis
architecture, interfaces, business modules, risks — documented.
Strangler-fig strategy
which modules first, which last, which stay unchanged.
API-first preparation
we wrap the legacy application with modern APIs before replacing modules.
Step-by-step migration
per module a mini project with its own fixed price and go-live.
Database migration
schema-friendly, with backwards-compatibility layer where needed.
Test-suite build-up
for legacy logic before replacement — no "blind" replacement.
Methodology (Strangler Fig pattern)
- 01
Reverse engineering
we understand the legacy application together with your team.
- 02
Build a façade
a modern API layer (Spring/Java) sits in front of the legacy.
- 03
Replace module by module
new implementation handles façade requests, old implementation continues in parallel.
- 04
Cutover per module
as soon as the new module runs stably, the old is switched off.
- 05
Full replacement
when all modules are migrated, the legacy application is decommissioned.
Typical use cases
Insurance policy administration
tariff module replaced, billing remains legacy initially
Industry ERP extension
custom build alongside SAP/Microsoft Dynamics, step by step
Java EE monolith
to microservices — one new service per bounded context
Cobol back office
to modern Spring/Java — database schema stays, logic moves
What we do NOT promise
No "big-bang cutover"
anyone promising that hides the risk.
No migration without test coverage
we build tests before replacing.
No lift-and-shift cloud migration
without functional improvement — that just relocates the problem.
Frequent questions
How long does a typical legacy modernisation take?
12–36 months for a larger monolith, in many small deliveries. But: first productive improvement often within 8–12 weeks.
Can you read Cobol/.NET legacy?
Yes, we have experience with Cobol, classical .NET, Java EE, PHP monoliths. If not, we say so.
Will our data be preserved?
Yes. Database migration is part of every module step, with rollback option.
What if a module cannot be replaced?
Then we leave it. Strangler fig is iterative — we decide per module.
Which process costs your team time every day?
In a free analysis call we look at it together and clarify whether automation makes sense.
60 minutes · no obligation