Legacy application modernization step by step instead of rebuilding. Strangler-fig migration, data migration and phased cutover, no interruption.
Rarely through an outage. Usually because initiatives stop starting — nobody can estimate the impact any more.
Both are close to retirement, and the knowledge is written down nowhere. Every change needs their time — and their goodwill.
What is functionally a small change becomes a technical intervention with unclear side effects. The business units have stopped asking.
The operating system, database or framework no longer receives security updates. The audit report flags it, and the clock is running.
No customer portal, no mobile app, no analytics — the system has no usable interface, and every integration becomes its own project.
Licences, specialists and emergency callouts add up quietly. The cost of inaction appears in no project proposal — but it appears in the budget.
The system runs the daily business. A green-field rebuild with a single cutover day is exactly the risk nobody wants to own.
Which path fits is decided by the analysis — not by sales. It is often a combination of two.
Replacing grown applications without a cutover day. We first bring the legacy system under test coverage, then replace it module by module, running old and new in parallel until the last piece has moved.
COBOL · .NET · Java EE · Delphi · VB6 · Oracle · SQL Server
Decomposition only where it pays off. Following the strangler-fig pattern, new services grow around the monolith and take over traffic step by step — with no single day when everything is new at once.
Kafka · RabbitMQ · Kubernetes · API Gateway · OpenTelemetry
For when the structure is the problem, not the technology. We surface the load-bearing architecture, price the technical debt by effort and risk, and design a target picture that can be reached in steps.
React · Angular · REST · GraphQL · Domain-Driven Design · CQRS
The part without which modernization stays a gamble. Before we replace anything, we pin the existing behaviour down with tests — after that, every replacement is verifiable instead of assumed.
Playwright · Cypress · JUnit · k6 · SonarQube · OWASP ZAP
A big-bang rewrite demands that every business rule of the legacy system is known. With grown systems, it never is. So we replace module by module — the legacy system remains the reference until the new module meets it.
We read the code, talk to the people who know the system, and write the business logic down. The result is a map with risk and effort per module.
Before anything is replaced, characterization tests capture today's behaviour. Those tests are what make every later replacement verifiable instead of assumed.
New modules take over traffic step by step while the legacy system keeps running. Every step individually approved, every step individually reversible.
Only when the last piece has moved and been confirmed in parallel operation is the legacy system switched off — with documentation, runbook and an onboarded team.
The cost of inaction appears in no project proposal — but it appears in the budget. Four things that measurably change.
No cutover day, no weekend of held breath. Parallel operation means: if a step doesn't hold, you go back one step — not twelve months.
Documented architecture and mainstream technologies mean you can hire from the market again — and no longer depend on two individuals.
Clear module boundaries and automated tests make changes calculable again. The business units start asking again.
Expiring licences, specialist premiums and emergency callouts drop away. The saving becomes visible because the legacy system's costs are captured first.
The analysis phase stands on its own: you receive risk, effort and sequence per module — and can then decide whether and with whom to continue.
Discuss an analysisPalisis of Switzerland — a frontend replacement, module by module, in parallel operation, with no forcing function for users.
In modernization the fear isn't the budget — it's stopping the system that runs the company. That's why every step is reversible.
There is no single day when everything is new at once. Old and new run in parallel, traffic shifts gradually, and every step has a way back.
Before business logic is rebuilt, we document it. You keep the documentation of your legacy system even if you stop after the analysis phase.
Full IP transfer, repository on your side, no retained licences. The same terms apply to legacy estates as to greenfield builds.
Because replacement happens module by module, every phase is a complete state. You are never at a point where the only options are pushing on or tearing down.
The legacy technologies we migrate out of, and the target technologies we move into. The target side is deliberately mainstream — you should be able to hire for it later.
The points that come up in every steering committee — answered up front.
On paper yes, in practice rarely. A rewrite requires every business rule of the legacy system to be known — and with grown systems that is never the case. Module-by-module replacement surfaces the unknown rules while the legacy system still runs as the reference. If, after analysis, a rebuild really is the better choice, we say so.
Yes — that is the foundational condition of our approach. Old and new run in parallel, traffic shifts gradually, and every wave has a rollback plan. A cutover day when everything switches at once is explicitly not part of the model.
That depends on the scope of the business logic, not the line count. The analysis phase typically takes 4–6 weeks and ends with an effort estimate per module. Only then do we quote an overall duration — as a range. A number before analysis would be a guess, and a missed date does more damage than a cautious estimate.
Data migration is planned as its own workstream, with validation against the legacy system and a documented rollback path. Test data is anonymized under revDSG and GDPR before it reaches development environments — whether or not the project brief asks for it.
As domain experts, not spectators. Your people know the rules that are written down nowhere — that is the most valuable contribution in the project. They typically join shared reviews and afterwards take over maintenance of the new system.
