Legacy modernisation — Strangler Fig instead of big bang

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)

1. Reverse engineering: we understand the legacy application together with your team.
2. Build a façade: a modern API layer (Spring/Java) sits in front of the legacy.
3. Replace module by module: new implementation handles façade requests, old implementation continues in parallel.
4. Cutover per module: as soon as the new module runs stably, the old is switched off.
5. 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.