Big-bang rewrites fail. Incremental migration works.
The temptation to rewrite a legacy system from scratch is strong — and almost always wrong. Big-bang rewrites take years, cost multiples of their estimates, and leave the organization running two systems in parallel with no clear cutover date. Meanwhile, the legacy system continues to accumulate workarounds, and the new system drifts from real requirements because it was designed against a specification, not against production reality.
The strangler fig pattern inverts this risk. Instead of replacing the entire system at once, you wrap the legacy system, intercept its interfaces and replace functionality piece by piece. Each piece is deployed, validated and delivering value before the next one starts. The legacy system shrinks until it disappears — without a single day of disruption.
Map & Wrap
We map every interface, data flow and business rule in the legacy system. Then we deploy a facade layer (API gateway or event bus) that intercepts traffic and routes it — initially to the legacy system, then progressively to new services.
Extract & Replace
We extract one bounded context at a time — typically starting with the highest-value or most painful module. Each new service is built, tested and deployed behind the facade before traffic is switched.
Validate & Retire
Parallel operation with automated comparison ensures the new service produces identical results. Once validated, the legacy module is decommissioned. Repeat until the monolith is gone.
What we deliver
API gateways, reverse proxies or event buses that intercept traffic to the legacy system. The facade enables gradual routing from old to new without changing upstream consumers.
Domain-driven decomposition of the monolith into independently deployable services. We identify natural seams in the legacy codebase and extract them with minimal cross-cutting changes.
Dual-write strategies, change data capture and eventual consistency patterns that keep legacy and modern databases synchronized during the migration period.
Automated comparison of legacy and new system outputs for every transaction. Shadow traffic, canary releases and feature flags ensure correctness before cutover.
Traffic shifting from legacy to modern services using percentage-based routing, geographic rollouts or user-segment targeting. Full rollback capability at every stage.
Afraid a full rewrite will break what already works?
Talk to an engineer who migrates monoliths incrementally.
Arvato Turkey
Arvato Turkey operated a monolithic order management system that could not scale for peak-season demand and resisted every attempt at feature extension.
We deployed an API gateway as a facade, extracted the order processing domain first, then inventory and fulfillment. Each service was validated in parallel before traffic was switched. The monolith shrank over 6 months.
Order processing throughput increased 4x. New features that previously took months were delivered in weeks. The legacy monolith was fully retired without a single outage.
Where we apply it
- Replace core monoliths without a single day of downtime
- Swap ERP modules one at a time while users keep working
- Decommission mainframes incrementally, not all at once
- Introduce modern APIs without breaking existing consumers
- Cut over to a new database platform with zero downtime
Technologies
Red Hat 
AWS 
Microsoft