Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

PatternChapter III · Evolution · Building block 6 of 7

Strangler migration

Strangler migration replaces selected capabilities of an existing system in controlled steps. Routing, data responsibility and return determine how long old and new implementation work together.

By Michael Meierhoff · Meierhoff Systems

  1. Small shareYou are releasing only one ability and only gradually.
  2. Measurement pointsLimit values decide on the next step.
  3. Return routeYou can switch back at any time.

Context

Why this is important

A complete replacement at once bundles risk and leaves no way back. Gradual detachment keeps old and new paths side by side and decides on the basis of measured values. Schema and data deals with data migration.

This building block deals with incremental detachment. Data migration plans schema and data transitions; deployment controls version deployment.

At a glance · Gradual detachment over a facade

The facade leads requests to the old system or new service; the share of the new service grows step by step.
Shop example · Playing through stages

Invoice search gradually redirect

Variant: The shop only directs the bill search to a new service. Ordering and payment remain in the modular monolith; routing can be deferred for search.

This is how you read the picture

  1. Small share You increase the share of 0 over 5 and 25 on 100 %.
  2. Measurement points Hit rate and response time are opposed to 97 % and 400 MS is tested.
  3. Return route Everyone walks with a switch 2.000 Search again in the monolith.
  • 100 from 2.000 Per daySearching for the new service
  • 96 %The new hit rate (limit ≥) 97 %)
  • 380 msResponse time P95 new (limit ≤) 400 ms

Only 5 % run through the service. The hit rate 96 % is below the limit 97 %. Hold the portion small or set it back.

Values illustrative

Increase the share over the new service and compare with the limits. Turn the reset on when a value drops.

Benefits & limitations

Helps if:

  • Self-contained business capabilities can be migrated separately from the rest of the existing system.
  • Step-by-step conversion limits migration risks during continuous product development.

Boundaries

  • Unclear write ownership creates conflicting data; each migrated slice needs an authoritative writer. See Data migration.
  • Growing routing logic becomes a permanent bottleneck; every legacy path needs an owner and retirement criteria.
  • The effort pays off for invoice search; routing provides little benefit for tightly coupled order and payment logic.

In practice

  1. Choose the capability and boundary. Identify a complete business function with bounded inputs, outputs and data effects. Check whether it can be tested and observed independently. This defines a slice with clear takeover responsibility.
  2. Plan routing and data ownership. Define which path receives requests, where changes are authoritatively stored and how failures propagate back. Document compatibility and switchover conditions. This keeps the old and new paths manageable during coexistence.
  3. Verify takeover and remove the old path. Measure quality and usage, test rollback and define retirement criteria before migration. Remove routing and legacy components after successful takeover. This demonstrably reduces transitional complexity.
Read the detailed explanation

A Strangler migration routes selected functions through a shared entry point to a new or existing implementation. Each slice needs a clear business boundary, data ownership and a verifiable operational state. The approach connects the transition to Data migration and uses suitable Module boundaries for separation.

Old and new paths coexist temporarily. Routing, synchronisation, monitoring and rollback add architectural work. Once the takeover is verified, the old path is removed; routing remains transitional and the new capability supports production operation. Small slices provide feedback from real use; choose them for business independence and limited risk. Parallel operation needs clear write ownership and coordination of changed data. Each migrated capability should have a defined point for rollback or retirement.

Martin Fowler named the pattern after the strangler fig, which gradually grows around a tree.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    At what proportion does the hit rate fall below the limit, and what do you do?

    View the solution with justification

    In case of: 5 % (96 % at least 97 %). Keep the proportion small or reset, clarify the deviation, then only increase.

  2. ApplyingTransferred to a new situation

    The new search service delivers fewer hits on the first requests than the old path. What are you doing?

    View the solution with justification

    Keep the portion small or reset the routing, investigate the deviation and only then redirect the next portion. The monolith remains the leader.

  3. EvaluateWeighing an alternative

    Instead of switching in steps, you could completely replace the bill search overnight. What speaks in favour, what speaks against?

    View the solution with justification

    A complete change is faster and knows no double paths. But he has no comparison values and no quick way back, if the new service hits worse.

Explore further

These building blocks continue the thoughts of this page.

EvolutionData migrationData migration coordinates changes to data models with software versions running in parallel.Opening OperationsDeployment & rolloutDeployment and rollout distribute software changes to the runtime environment under control.Opening EvolutionTrade-off analysisA trade-off analysis compares options against competing goals and their consequences.Opening

References

Continue on the learning path

Next in Evolution & assessment: Data migration.

7 Building blocks

Continue withData migration