"It would be much easier to start a next-gen system from scratch."

The problem is that the existing system already works. It carries years of edge cases, integrations, reporting, and revenue. I can’t simply ditch it and start on a greenfield, but I also can’t keep it as-is: complexity grows with every sprint, cognitive load increases, clear team ownership boundaries become impossible, and time to market slowing down.

What worked

Looking into design patterns, I found the Strangler Fig pattern that everyone mentions but in practice, it’s not enough. You also need an Anti-Corruption Layer (ACL). Without an ACL, you can’t keep the legacy system running without regression while new hosts run side by side.

They both allow you to incrementally replace specific pieces of functionality while the legacy system continues to run.

Important note

This kind of service separation should only be done when justified. For example, when you need team ownership boundaries or different hardware requirements. The example here is meant to explain the approach, not to suggest that every monolith should be split.

One caveat

This approach only works for systems where you can introduce a strangler. If you’re dealing with something like a background service “big ball of mud” with no interception point, then the next-gen is the way.

Next step

This guide has every diagram, from the initial monolith to the final state.