This chapter covers the Strangler Fig migration pattern, a critical strategy for incrementally modernizing legacy applications in Azure. For the AZ-305 exam, this topic appears in approximately 5-7% of questions, often within the context of migration strategies, application modernization, and solution design. Understanding the Strangler Fig pattern is essential for designing migration solutions that minimize risk and downtime while progressively replacing monolithic or on-premises systems with cloud-native architectures.
Jump to a section
Imagine a Formula 1 pit crew tasked with replacing a car's entire engine while the car is still racing around the track at 200 mph. The crew cannot stop the car, so they must work incrementally. They start by installing a new, more powerful engine alongside the old one, connecting it to the drivetrain through a secondary gearbox. Initially, only the old engine provides power. One by one, the crew transfers critical subsystems—fuel lines, cooling, exhaust—from the old engine to the new one. With each transfer, the new engine takes over a small function while the old engine's load decreases. Eventually, the old engine is completely disconnected and removed, leaving the car running solely on the new engine. Throughout the process, the car never stops; the driver feels no interruption. If at any point the new engine fails, the crew can instantly switch back to the old engine, maintaining operational continuity. This mirrors the Strangler Fig pattern: legacy components are gradually replaced by new ones, with routing logic (the driver) directing traffic to the appropriate system until migration is complete.
What is the Strangler Fig Migration Pattern?
The Strangler Fig pattern is a software migration strategy named after the tropical strangler fig tree, which grows around a host tree, gradually enveloping and replacing it. In application modernization, it involves incrementally replacing specific functionalities of a legacy system with new services, typically cloud-native microservices, while keeping the overall system operational. The legacy system is eventually "strangled" — decommissioned once all functionality has been migrated.
This pattern is particularly relevant when migrating from monolithic on-premises applications to Azure, as it allows for continuous delivery and minimal disruption. The Azure Well-Architected Framework recommends the Strangler Fig pattern for reducing risk during large-scale migrations.
How It Works Internally
The pattern operates through a routing layer (often an API gateway, reverse proxy, or load balancer) that intercepts requests to the legacy system. The routing layer determines whether to forward a request to the legacy system or to a new replacement service.
Initial State: All traffic flows to the legacy application. The routing layer is transparent.
Incremental Migration: For a specific feature (e.g., user authentication), a new microservice is deployed in Azure (e.g., Azure App Service, Azure Functions, or AKS). The routing layer is updated to redirect requests for that feature to the new service.
Feature Parity: The new service must handle the same inputs and produce the same outputs as the legacy feature. This may require data synchronization between legacy and new databases (e.g., using Azure SQL Database or Cosmos DB with change feed).
Testing and Validation: Traffic is gradually shifted using techniques like canary releases or A/B testing. The routing layer can use percentage-based routing or feature flags.
Complete Migration: Once all features are replaced, the legacy system is decommissioned. The routing layer now directs all traffic to the new services.
Key Components and Defaults
Routing Layer: Typically an API Gateway (Azure API Management), reverse proxy (NGINX, HAProxy), or a load balancer (Azure Application Gateway, Azure Load Balancer). Must support URL path-based routing or header-based routing.
Feature Flags: Tools like Azure App Configuration or LaunchDarkly enable dynamic routing decisions without redeploying the routing layer.
Data Migration: Often the most complex part. Use Azure Database Migration Service for schema and data sync. For near-zero downtime, use transactional replication or change data capture (CDC).
Health Checks: Both legacy and new systems must expose health endpoints. The routing layer should automatically route away from unhealthy instances.
Session State: If the legacy system uses server-side sessions, the new service must either share state (e.g., via Azure Redis Cache) or use stateless tokens (JWT).
Timeout Values: Default request timeout for Azure Application Gateway is 20 seconds. For API Management, default is 60 seconds. These may need adjustment during migration.
Configuration and Verification Commands
Assuming a scenario using Azure Application Gateway as the routing layer:
**Create a path-based rule to redirect /api/auth/* to the new service:**
# PowerShell Az module example
$rg = "MyResourceGroup"
$appgw = Get-AzApplicationGateway -Name "MyAppGateway" -ResourceGroupName $rg
# Add a new path-based rule
$pathRule = New-AzApplicationGatewayPathRuleConfig -Name "auth-rule" `
-Paths @("/api/auth/*") `
-BackendAddressPool $newServicePool `
-BackendHttpSettings $newServiceSettings
# Add the rule to an existing URL path map
$pathMap = Get-AzApplicationGatewayUrlPathMapConfig -Name "defaultPathMap" -ApplicationGateway $appgw
$pathMap.PathRules += $pathRule
# Update the gateway
Set-AzApplicationGateway -ApplicationGateway $appgwVerify routing using curl:
curl -I https://myapp.azure.com/api/auth/login
# Expect HTTP 200 from the new serviceCheck backend health:
Get-AzApplicationGatewayBackendHealth -ApplicationGateway $appgwInteraction with Related Technologies
Azure DevOps: CI/CD pipelines automate deployment of new microservices and routing rule updates.
Azure Monitor: Track request distribution, latency, and error rates for both legacy and new services.
Azure Traffic Manager: Can be used for global traffic routing during migration across regions.
Azure Front Door: Provides advanced routing capabilities including URL path-based routing, SSL termination, and WAF — suitable for HTTP(S) workloads.
Azure Service Bus: For asynchronous communication between legacy and new systems during migration (e.g., event-driven integration).
Common Pitfalls
Incomplete Data Sync: If the new service writes to a new database, the legacy system may need to read that data. Implement bidirectional sync or use a shared database temporarily.
Session Affinity: Sticky sessions can cause issues if the routing layer sends a request to the new service but the session is still on the legacy server. Use centralized session stores.
Feature Coupling: If legacy features are tightly coupled (e.g., a monolithic function that handles both auth and billing), replacing one requires careful decomposition.
Testing Complexity: Ensuring the new service behaves identically to the legacy one requires comprehensive integration tests.
Exam Emphasis
For AZ-305, focus on the pattern's suitability for incremental migration with minimal risk. The exam may present scenarios where you must choose between Strangler Fig, Rehost, Refactor, or Rebuild. Key discriminators: Strangler Fig is ideal when you cannot tolerate downtime and need to modernize gradually. It is not suitable for simple lift-and-shift (Rehost) or when the legacy system is already being replaced entirely (Rebuild).
Identify and Decompose Features
Analyze the legacy application to identify discrete functionalities that can be extracted independently. Each feature should have a well-defined API boundary. For example, in an e-commerce monolith, user authentication, product catalog, and payment processing are candidates. Prioritize features that are stable, less critical, or have clear interfaces. Decompose without breaking existing dependencies. Document input/output contracts for each feature.
Deploy New Service in Azure
Create a new cloud-native service for the chosen feature. This could be an Azure App Service Web App, an Azure Function, or a containerized microservice on AKS. Ensure it replicates the legacy feature's behavior exactly, including error handling, response formats, and data validation. Deploy the new service to a staging environment first, then to production but without routing traffic yet. Use Azure DevOps pipelines for automated deployment.
Configure Routing Layer
Update the routing layer (e.g., Azure Application Gateway, API Management, or Front Door) to forward requests for the extracted feature to the new service. This is typically done via URL path-based routing. For example, all requests to `/api/auth/*` are redirected to the new authentication service. The routing layer must also maintain fallback to the legacy system if the new service is unhealthy. Use health probes to monitor both endpoints.
Migrate Data and State
If the new service uses its own data store, migrate relevant data from the legacy database. Use Azure Database Migration Service for initial bulk copy and then set up continuous sync (e.g., transactional replication or change feed). For session state, use Azure Redis Cache as a shared session store so both legacy and new services can access it. Ensure data consistency during the transition; consider a two-phase commit or eventual consistency model.
Monitor and Shift Traffic Gradually
Start by routing a small percentage of traffic (e.g., 5%) to the new service using weighted routing or feature flags. Monitor application performance, error rates, and latency using Azure Monitor and Application Insights. Compare response times and error distributions. Gradually increase the percentage as confidence grows. If issues arise, immediately roll back by sending all traffic back to the legacy system. Once 100% traffic is on the new service, remove the old code path.
Decommission Legacy Feature
After confirming the new service handles all traffic correctly, remove the legacy feature from the monolith. This may involve deleting code, removing database tables, and decommissioning servers. Update the routing layer to remove the fallback to the legacy system. Repeat the process for the next feature. Eventually, the entire legacy system is decommissioned. Document the migration for compliance and future reference.
Enterprise Scenario 1: Financial Services API Modernization
A large bank had a monolithic on-premises application handling customer account management, transactions, and reporting. They wanted to move to Azure to improve scalability and reduce costs. Using the Strangler Fig pattern, they migrated the transaction processing feature first. They deployed an Azure Functions app behind Azure API Management. The API Management gateway was configured with URL path-based routing: /api/transactions/* went to the new service, while all other paths went to the legacy system. Data was migrated using Azure Database Migration Service with continuous sync via change data capture. The migration took six months, with each feature replacement taking two weeks. The challenge was maintaining transactional consistency between the legacy SQL Server and the new Azure SQL Database. They used distributed transactions via the Microsoft Distributed Transaction Coordinator (MSDTC) initially, then moved to a saga pattern. Performance monitoring showed a 40% reduction in latency for transaction processing after migration.
Enterprise Scenario 2: E-Commerce Platform Decomposition
A retail company had a monolithic .NET application running on-premises. They wanted to adopt a microservices architecture in Azure. They started with the product catalog feature because it had clear API boundaries. They deployed a containerized microservice on Azure Kubernetes Service (AKS). Azure Front Door was used as the routing layer, directing /api/products/* to the new service. The legacy system used a shared SQL Server database. The new service used Azure Cosmos DB. Data migration was handled via a custom sync service that read from the legacy database and wrote to Cosmos DB. They used Azure Service Bus to propagate changes from the new service back to the legacy system to keep product data consistent. The migration was done in phases: first, read-only operations (product listing) were moved; then write operations (add/update products). The entire migration took one year. Misconfiguration of the Front Door routing rules caused a brief outage when the new service returned a different response format for error cases, breaking the frontend. This was fixed by updating the new service to match the exact legacy response format.
Scenario 3: Healthcare Claims Processing
A healthcare insurer had a legacy COBOL-based claims processing system. They wanted to modernize without downtime. Using the Strangler Fig pattern, they extracted the claims validation logic into an Azure Logic App. The routing was implemented using a custom reverse proxy (NGINX) running on Azure VMs. The proxy examined request headers to determine if the request was for validation. Data migration was complex because the legacy system used VSAM files. They used Azure Data Factory to copy data to Azure SQL Database. The new Logic App used the same business rules but implemented in C#. The migration took over 18 months due to the complexity of the COBOL logic. The key lesson was the importance of comprehensive testing — many edge cases in the legacy system were undocumented. They used Azure Test Plans to create regression tests. After migration, claims processing time dropped from 24 hours to 2 hours.
AZ-305 Exam Focus
The Strangler Fig pattern is tested under objective 4.3: "Design a migration solution." Specifically, it aligns with the sub-objective "Recommend a migration strategy." The exam expects you to distinguish between five migration strategies: Rehost, Refactor, Rearchitect, Rebuild, and Replace. Strangler Fig is a pattern that supports the Refactor or Rearchitect strategies.
Common Wrong Answers and Why Candidates Choose Them
"Rehost (Lift-and-Shift) is the best approach for modernizing an application." Candidates choose this because they think moving to Azure quickly is always best. However, Rehost does not involve changing the application architecture. The Strangler Fig pattern is specifically for modernization, not just relocation. The exam will present a scenario where the company wants to adopt cloud-native features (e.g., serverless, containers) — Rehost does not achieve that.
"Use a blue-green deployment strategy instead." Blue-green deployment is about switching between two identical environments, not incrementally replacing functionality. Candidates confuse the two because both involve routing traffic. The key difference: blue-green deploys a complete copy of the application, while Strangler Fig replaces parts over time.
"Strangler Fig is only for web applications." While commonly used for web apps, the pattern can apply to any system with a routing layer, including message queues (e.g., replace a legacy message processor with Azure Functions) or database access layers.
"You must migrate all data at once." This is false. Data can be migrated incrementally, and the routing layer can direct reads to the new data store while writes still go to the legacy system initially. The exam tests understanding of phased data migration.
Specific Numbers and Terms on the Exam
"Incremental migration" and "minimal risk" are phrases often used in correct answers.
"API Gateway" or "reverse proxy" as the routing component.
Feature flags (e.g., Azure App Configuration) are mentioned as enabling gradual rollouts.
Health probes are critical for automatic rollback.
The exam may ask about data consistency during migration — eventual consistency is often acceptable.
Edge Cases and Exceptions
When the legacy system has no clear API boundaries (e.g., a monolithic desktop application), the Strangler Fig pattern is difficult to apply. The exam may present this as a reason to choose Rebuild instead.
When the legacy system is already being decommissioned (e.g., end-of-life), Strangler Fig is unnecessary.
When the migration must be completed within a tight deadline, Strangler Fig may not be suitable because it takes longer than Rehost.
How to Eliminate Wrong Answers
If the question emphasizes "modernize" or "adopt cloud-native", eliminate Rehost.
If the question mentions "gradual replacement of components", eliminate blue-green and Rehost.
If the question says "no downtime" and "minimal risk", Strangler Fig is likely the answer.
Look for keywords like "routing layer", "feature by feature", and "incremental".
Strangler Fig pattern enables incremental migration of legacy applications to Azure with minimal risk and zero downtime.
The pattern requires a routing layer (API Gateway, reverse proxy) to direct traffic to either legacy or new services based on feature.
Data migration can be done incrementally using sync mechanisms like change data capture or Azure Database Migration Service.
Feature flags (e.g., Azure App Configuration) are commonly used to control traffic routing without code changes.
The pattern is suitable for refactoring or rearchitecting strategies, not for rehost (lift-and-shift) migrations.
Health probes are essential for automatic rollback if the new service fails.
The pattern is not limited to web applications; it can be applied to any system with a routing layer.
On the AZ-305 exam, look for keywords like 'incremental', 'feature by feature', 'routing layer', and 'minimal risk' to identify Strangler Fig questions.
Common wrong answers include blue-green deployment and rehost, which do not involve incremental replacement of functionality.
The pattern is named after the strangler fig tree that grows around a host tree, eventually replacing it.
These come up on the exam all the time. Here's how to tell them apart.
Strangler Fig Pattern
Incremental migration, feature by feature.
Minimal risk; easy rollback per feature.
Requires a routing layer to direct traffic.
Longer overall migration timeline.
Allows continuous operation of legacy system.
Big Bang Migration
All functionality migrated at once.
High risk; if migration fails, entire system is affected.
No routing layer needed; cutover is a single switch.
Shorter migration timeline.
Requires downtime or a parallel run period.
Mistake
Strangler Fig pattern requires a complete rewrite of the legacy application.
Correct
No, the pattern allows for incremental replacement of individual features. The legacy system remains operational until all features are migrated. Only the extracted features are rewritten or refactored.
Mistake
Strangler Fig pattern is the same as a blue-green deployment.
Correct
Blue-green deployment switches between two complete copies of the application (old and new). Strangler Fig replaces functionality piece by piece, with the routing layer directing specific requests to the new service while others still go to the legacy system.
Mistake
Data migration must be completed before any traffic is routed to the new service.
Correct
Data can be migrated incrementally. For example, the new service can read from the legacy database initially, or a sync mechanism can keep both databases consistent. Full data migration can happen in parallel with feature migration.
Mistake
Strangler Fig pattern only works for HTTP-based applications.
Correct
While commonly used for web applications, the pattern can be applied to any system with a routing layer, including message queues (e.g., replace a legacy message processor with Azure Functions) or database access layers (e.g., use a proxy to redirect queries).
Mistake
The routing layer must be a dedicated appliance like Azure Application Gateway.
Correct
The routing layer can be any component capable of directing traffic based on request attributes. This includes Azure API Management, Azure Front Door, NGINX, HAProxy, or even a custom reverse proxy. The exam does not mandate a specific technology.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
The Strangler Fig pattern is a strategy for incrementally migrating a legacy application to a new platform (like Azure) by gradually replacing its features with new services. A routing layer intercepts requests and forwards them to either the legacy system or the new service based on the feature being accessed. Over time, the legacy system is 'strangled' and decommissioned. This pattern minimizes risk and avoids downtime.
Blue-green deployment involves running two identical environments (blue and green) and switching all traffic from one to the other. Strangler Fig replaces functionality piece by piece, with the routing layer directing specific requests to the new service while others still go to the legacy system. Blue-green is a deployment strategy, while Strangler Fig is a migration pattern.
Azure services suitable for the routing layer include Azure Application Gateway (for HTTP load balancing with path-based routing), Azure API Management (for API routing and transformation), Azure Front Door (for global HTTP routing with WAF), and Azure Load Balancer (for TCP/UDP traffic). Custom reverse proxies like NGINX running on Azure VMs are also common.
Yes, the pattern can be extended to databases. For example, you can route read queries to a new database while writes still go to the legacy database, using a database proxy. Over time, you migrate tables or schemas incrementally. Azure SQL Database and Cosmos DB support change feed for synchronization.
Risks include: data inconsistency if sync mechanisms fail; increased complexity due to the routing layer; longer migration timeline; and the need for the new service to exactly match legacy behavior. Proper health monitoring and rollback plans mitigate these risks.
Avoid Strangler Fig when: the legacy system is already being decommissioned (use Rehost or Replace); the application has no clear API boundaries (consider Rebuild); the migration must be completed very quickly (Big Bang may be faster); or the legacy system is too tightly coupled to extract features individually.
Use a centralized session store like Azure Redis Cache that both legacy and new services can access. Alternatively, make the new service stateless by using tokens (e.g., JWT) that carry session information. This avoids sticky session issues when routing traffic between systems.
You've just covered Strangler Fig Migration Pattern — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?