Engineering & evolution
Modernize around a business boundary
A useful modernization plan makes the next change smaller and the final destination clearer. Start with a responsibility the business can understand, then design how old and new will coexist.
An ageing platform can be difficult to change while still doing something essential every day. That combination deserves a careful response. The first architectural question is which responsibility can move safely, with enough independence to improve delivery and enough business relevance to justify the transition.
Imagine a distributor whose customers telephone for order status because its portal is unreliable. Replacing order capture, inventory, invoicing and fulfilment together would create a very broad programme. A more useful first investigation might ask whether order visibility can become a dependable capability while those other responsibilities continue operating. This hypothetical boundary gives the modernization effort a specific customer problem to solve.
Choose a seam with a reason to exist
The strangler fig pattern gradually replaces selected functionality, using a façade to route requests to the existing system or its replacement. The old system continues serving the responsibilities that have not moved. Microsoft describes this as transitional architecture, with temporary infrastructure costs and a routing layer that needs its own reliability and performance consideration. [1]
That mechanism becomes valuable when the first slice has an intelligible purpose. Write down the task it serves, the information it owns, the callers that depend on it and the change that would count as progress. A boundary named after a business responsibility is easier to discuss with the people who must approve its behaviour.
For the distributor, the initial promise could be accurate order visibility with a clear explanation when information is delayed. The scope should identify which order states are included and how support staff can investigate a discrepancy. Those details make the boundary more useful than a general intention to modernize the portal.
Treat coexistence as part of the product
Draw the intermediate arrangement before committing to the destination. Show where a request enters, which system answers it and where the data comes from. Give each temporary connection an owner and an intended retirement condition. A transition diagram should explain the next release as clearly as the eventual platform.
Data deserves a separate conversation. Decide which system can change a record, how the other system learns about that change and what happens while the two disagree. In the hypothetical order-status service, a delayed update should have an explicit interpretation. A customer-facing message, a support view and a reconciliation procedure should all follow the same rule.
Keep legacy meanings at a deliberate boundary
A newer interface can inherit old ambiguity surprisingly easily. One application may use a single status field for payment, fulfilment and internal approval. Simply exposing that field through a new endpoint would leave the meaning unresolved.
An anti-corruption layer translates between systems with different models or semantics, helping the new component avoid adopting the older model throughout its design. Microsoft also identifies the maintenance, latency and observability costs of that extra layer. [3] Use it where translation has a clear purpose, document the mapping and test unusual states. Keep its responsibilities narrow enough that it remains understandable.
Agree on the evidence before moving traffic
Choose representative examples before the new slice becomes the default. Include the ordinary journey, an incomplete record, an unavailable dependency and an unfamiliar business exception. Decide which differences from the existing behaviour are intended improvements and which require investigation.
Define the release decision in operational terms: what can be observed, who reviews it, when traffic should pause and how support will recognise the new path. Specify what happens to records created during a trial if routing returns to the previous implementation. The rollback discussion should address business state as well as application deployment.
Keep a credible route to retirement
Incremental migration still needs a destination. Track the dependencies removed by each slice, the temporary adapters still running and the conditions for switching off a legacy responsibility. Otherwise, a sequence of successful releases can leave the organisation operating two permanent systems.
The approach also has limits. AWS highlights code access and unclear domain boundaries as important considerations. Microsoft identifies situations where requests cannot be intercepted, the system is small enough for straightforward replacement, or a rapid full retirement is required. [1][2] Compare those constraints before selecting the pattern. A sensible plan may combine incremental extraction, improvements within the existing application and a deliberately bounded replacement.
Sources & further reading
The references behind this perspective. Reviewed . Product documentation can change; check the source before making an implementation decision.
- Microsoft Azure Architecture Center — Strangler Fig pattern
Primary guidance for gradual replacement, façade routing, transitional costs and suitability constraints; checked 21 October 2026.
- AWS Prescriptive Guidance — Strangler fig pattern
Primary guidance for code access, domain boundaries and incremental extraction considerations; checked 21 October 2026.
- Microsoft Azure Architecture Center — Anti-Corruption Layer pattern
Primary guidance for translation between different system semantics and its operational tradeoffs; checked 21 October 2026.
