# Legacy modernisation

> Step-by-step replacement of legacy applications with the Strangler-fig pattern. Fixed price per module, no big bang, no downtime.

Existing applications are modernised step by step without unnecessarily interrupting operations.

## When it helps

Useful when a core application is outdated but cannot simply be switched off.

## Key points

- Stable, incremental migration without a big bang
- Less technical debt in core systems
- A clear technical roadmap for the next steps

## Details

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.

## Technologies

- Java
- Spring Boot
- Kubernetes
- Docker
- PostgreSQL
- REST APIs
- Apache Kafka
- CI/CD
- Strangler Fig Pattern

## Relevant links

- [HTML version](https://monadion.com/en/services/legacy-modernisierung)
- [English overview (llms.txt)](https://monadion.com/en/llms.txt)
- [Full AI context](https://monadion.com/en/llms-full.txt)
- [Book an analysis call](https://monadion.com/en/booking)
- [Contact](https://monadion.com/en/contact)

## Related

- [All services](https://monadion.com/en/services.md)
- [Industries](https://monadion.com/en/branchen.md)