Strangler Fig Migration

A company's checkout logic lives inside one large, legacy .NET Framework application that also handles billing and reporting.

Rewriting all of it and switching every customer over to a new .NET microservice in a single release would mean weeks with no way to compare the new service's decisions against the trusted old ones.

A rewrite that only proves itself the moment it goes live risks every customer at once, on a system nobody has watched run for real yet. That's exactly what a strangler fig migration avoids.

A strangler fig migration moves traffic over gradually instead of all at once: route a small slice of traffic to the new .NET microservice first, using a weighted routing rule in Azure Front Door or Azure API Management, and keep the rest on the legacy application. Watch that slice closely, and only once it proves correct, shift the routing rule to move another slice over, continuing gradually until the legacy application has no traffic left to handle.

Use: Azure Front Door, Azure API Management (Weighted Routing)

A problem in the new system only costs you the slice of traffic already moved, never everyone at once.

A strangler fig seed lands in the branches of a host tree and sends roots down around its trunk. Over years, the fig grows into its own structure, wrapped around the tree it started on.

Eventually the fig can stand entirely on its own, and the original tree underneath is gone. The forest never went a single day without a tree standing in that spot.

A migration done this way never has a day where nothing is standing. The new system just gradually becomes the one actually holding everything up.