The strangler fig pattern is the most practical approach to modernizing a legacy .NET monolith without stopping product delivery. It works by incrementally replacing functionality in the existing system with new services, routing traffic gradually from the old codebase to the new one until the legacy system can be decommissioned. The pattern does not require a feature freeze, does not demand a big-bang cutover, and does not force you to bet the entire modernization project on a single deployment. At Blackthorn Vision, a Microsoft Solutions Partner specializing in .NET modernization and Azure architecture, we use this approach as the default for enterprise .NET platforms where product delivery cannot pause for a rewrite.
This article covers how the pattern actually works in a .NET production context, what the implementation looks like with modern tooling, where it tends to break down, and how to sequence the migration to avoid the failure modes that affect a large share of strangler fig projects.
Why teams reach for the strangler fig pattern
The alternative to the strangler fig pattern is usually described as a big-bang rewrite: stop adding features to the legacy system, build a new version from scratch, and cut over when it is ready. The appeal is obvious. You start with a clean architecture, no legacy constraints, and the full benefit of everything the team has learned since the original system was built.
The problem is that big-bang rewrites fail at a rate that should make any engineering leader uncomfortable. Modernization Intel's analysis of enterprise strangler migration data from 2022 to 2025 found a 76% success rate across 29 tracked strangler fig projects, with median annual savings of $640K in successful engagements. Failed projects, by contrast, produced a median sunk cost of $2.1 million. A key finding from the same dataset: projects that extracted less than 5% of monolith functionality in the first 90 days had a 92% failure rate, which means early velocity is the strongest predictor of whether a strangler migration succeeds. The most common failure mode in rewrites is feature parity: the new system consistently runs behind the legacy system in capability, the cutover date slips repeatedly, and eventually leadership loses confidence and either cancels the project or forces a cutover before the new system is ready.
The strangler fig pattern sidesteps this problem by keeping the legacy system in production and making the migration reversible at every step. If a newly migrated component behaves incorrectly in production, you route traffic back to the legacy implementation while you investigate. There is no moment where the entire system depends on code that has never handled real production load.
The technical implementation for .NET: YARP as the facade layer
The strangler fig pattern requires a routing layer that sits in front of both the legacy system and the new services. In the .NET ecosystem, the recommended tool for this is YARP (Yet Another Reverse Proxy), a Microsoft-developed reverse proxy library built on ASP.NET Core middleware. Microsoft's own migration guidance for incremental ASP.NET to ASP.NET Core migrations is built around YARP, and it has become the standard approach for .NET strangler fig implementations because it integrates naturally with the existing .NET toolchain.
The setup works like this. You create a new ASP.NET Core project that hosts YARP. Initially, YARP forwards 100% of requests to the legacy .NET Framework application. As you migrate each component, you add routing rules to YARP that send specific routes or request types to the new service instead of the legacy system. The legacy application continues to run and handle everything that has not yet been migrated. From the perspective of users and external systems, nothing changes, because all requests still arrive at the same endpoint.
┌─────────────────────────────────────┐
│ YARP Facade │
User / Client ►│ (ASP.NET Core app) │
│ │
│ Route: /api/reports ───────────────► New .NET 8 Service
│ Route: /api/orders ───────────────► New .NET 8 Service
│ Route: everything else ────────────► Legacy .NET Framework App
└─────────────────────────────────────┘
Both systems run in production simultaneously. The routing configuration in YARP is the only thing that changes as each component is migrated. Rolling back a component means updating one routing rule, not redeploying the entire application.
The practical implementation steps for a .NET Framework to .NET 8 migration are:
Deploy the YARP-based ASP.NET Core application to Azure App Service alongside the legacy .NET Framework application. Both services run independently, with YARP configured to proxy all traffic to the legacy system as a starting point.
Add the System.Web.Adapters library to both projects, which provides compatibility shims for HttpContext and related types, allowing code that references System.Web to be moved incrementally without rewriting everything that depends on it.
Identify the first component to migrate, ideally something with clear boundaries, reasonable test coverage, and meaningful traffic volume. Starting with a low-traffic component that nobody will notice if it breaks is tempting, but it delays the point at which the team learns how the migration behaves under real load.
Build the new implementation in the ASP.NET Core project, run it in parallel with the legacy implementation, compare outputs to confirm parity, and then update the YARP routing configuration to direct that component's traffic to the new service.
Monitor the component in production for a validation period before moving on to the next component. The length of this period depends on the criticality of the component and the traffic patterns it handles.
How to pick the first component to migrate
Choosing the wrong starting point is one of the most common reasons strangler fig projects stall in the first two months. The instinct is usually to start with something small and contained, which makes sense in principle but often produces a migration that validates the toolchain without validating the approach under realistic conditions.
The criteria that produce a better first component are:
Clear external boundaries: the component has a defined API surface that other parts of the system consume through a stable contract, rather than reaching into shared state or calling internal methods directly.
Measurable output: you can run both implementations against the same inputs and compare outputs programmatically, which is the foundation of the parallel-run validation that makes the strangler fig safe.
Meaningful traffic: the component handles enough requests that production behavior is visible in monitoring within hours, not weeks. This matters because some failure modes only appear under load or in edge cases that staging environments do not produce reliably.
Limited data coupling: the component does not share database tables with multiple other components in ways that make schema changes a cross-system coordination problem.
At Blackthorn Vision, the components we typically migrate first in a .NET Framework monolith are API endpoints that handle well-defined request and response contracts, reporting and data export functions that can be validated by comparing output files, and background processing jobs that can be run in parallel and compared before the legacy version is disabled.
The parallel-run validation approach
Running both implementations in parallel and comparing their outputs is the technical mechanism that makes the strangler fig pattern safe. Without it, you are deploying new code to production and hoping it behaves correctly, which is not meaningfully different from a big-bang migration in terms of risk.
The parallel-run works by having the YARP facade send each request to both the legacy implementation and the new service simultaneously, recording both responses, and logging any discrepancies. The legacy response is returned to the caller, so users always receive the behavior they expect. The new service response is compared in the background. Discrepancies trigger alerts that the team investigates before increasing the traffic percentage routed to the new service.
This approach requires investment in observability infrastructure that many legacy .NET systems lack. If the existing system has no structured logging, no distributed tracing, and no way to correlate requests across services, that investment has to happen before the migration can proceed safely. The observability work is not overhead: it is the foundation that makes the parallel-run comparison meaningful and that gives the team confidence to increase the traffic percentage routed to the new implementation.
What breaks in practice, and why
Research covering 29 tracked strangler fig projects found that projects missing more than two key prerequisites had a 94% failure rate. The prerequisites that matter most in a .NET context are test coverage on the components being migrated, a working parallel-run validation mechanism, and a data migration strategy for components that own data.
The failure mode we see most often at Blackthorn Vision is what might be called "facade as decoration": a team builds the YARP routing layer, migrates the UI or the API layer of one component, but leaves the business logic and data access in the monolith. The new service makes calls back into the legacy system for data, which means the coupling has not been reduced, it has just been made visible through a network boundary. The team has added latency and operational complexity without actually strangling anything.
The solution to this is enforcing data sovereignty as a hard rule: each migrated service must own its data. If a new service needs to read data that currently lives in the monolith's database, the migration plan for that service must include a data migration strategy, either through dual-write during the transition, Change Data Capture (CDC) to synchronize data between the old and new stores, or a data extraction and import step that runs before traffic is routed to the new service.
The database trap deserves its own mention because it is the failure mode most likely to cause data corruption rather than just downtime. When two systems, the legacy monolith and the new service, write to the same database table simultaneously without a coordination mechanism, race conditions and conflicting writes produce corrupted records that are often invisible until a business process produces wrong results days later. This is not a theoretical risk: it is what happens when teams treat the shared database as a neutral middle ground between the old and new systems instead of recognizing it as the source of coupling they are trying to remove.
The correct approach is to never allow both systems to write to the same table at the same time. If data has to be shared during the transition, use either dual-write with application-level coordination (the new service writes to both the new store and the legacy table, and the legacy system reads from its own table) or Change Data Capture to synchronize records between the old and new data stores without allowing both systems to write the same rows. Neither approach is simple, but both are substantially safer than allowing concurrent writes to shared tables.
Other common failure points are:
Session state: .NET Framework applications often use in-process session state, which breaks immediately when traffic starts flowing through a YARP proxy to a different process. Externalizing session state to a shared Redis cache or Azure Cache for Redis before the migration begins removes this as a blocker.
Authentication: shared authentication tokens and cookies that were issued by the legacy system need to be validated by the new service. This typically requires externalizing the identity provider and configuring both systems to validate tokens from the same source.
Synchronous integrations that cannot tolerate the additional latency introduced by the proxy hop. Most integrations handle this without issue, but any integration with a timeout configured below 500ms should be identified during the assessment phase and addressed before the facade is deployed.
Sequencing the full migration
A strangler fig migration for a mid-size .NET Framework monolith typically runs over 12 to 18 months when executed alongside normal product delivery. That timeline is longer than most teams expect when they start, and shorter than most teams fear when they look at the size of the codebase.
The migration progresses in three broad phases. The first phase establishes the infrastructure: YARP is deployed, observability is in place, the parallel-run validation mechanism is working, and the first component has been migrated and validated under real production load. This phase typically takes six to eight weeks and is the most important: if the infrastructure is not solid, every subsequent migration step will be slower and riskier than it needs to be.
The second phase is the main migration loop: one component per sprint, parallel-run validation, traffic ramp, monitoring period, then the next component. The speed of this phase depends on the quality of the boundaries in the original system. Components with clear boundaries migrate quickly. Components where business logic is scattered across stored procedures, event handlers, and configuration files take longer because the boundary has to be established before the migration can happen.
The third phase is decommissioning: once all traffic has been routed to the new services, the legacy system enters a monitoring-only state for a final validation period, typically four to six weeks, before it is shut down. The YARP facade can be removed at this point or retained as a load balancer, depending on the architecture of the new system.
The Azure development services that support this migration are available and well-documented. Azure App Service hosts both systems during the parallel-run phase. Azure Cache for Redis externalizes session state. Application Insights provides the observability layer. One additional benefit that teams often underestimate until they see it in practice: moving from .NET Framework to .NET 8 removes the dependency on Windows Server, which means the new services can run in Linux containers on Azure Kubernetes Service or Linux-based App Service plans. For organizations running large fleets of Windows Server VMs, the licensing cost reduction from this shift alone can be substantial, and it becomes a secondary justification for the modernization investment that is easy to quantify for leadership.
Why this matters for AI integration
One of the main reasons enterprise teams modernize .NET Framework monoliths today is that modern AI tooling works substantially better on modern .NET architecture. Azure OpenAI integration, Semantic Kernel, and the Microsoft.Extensions.AI libraries that simplify LLM orchestration all depend on async patterns, clean service boundaries, and the observability infrastructure that legacy monoliths typically lack.
At Blackthorn Vision, the strangler fig approach is often used as a prerequisite step before Azure OpenAI or Semantic Kernel integration, because the AI workload exposes exactly the coupling and latency problems that the monolith has been hiding. Most of the platforms we modernize have teams that want to add copilot features, semantic search, or LLM-powered internal tools to an existing product. The strangler fig migration creates the service boundaries and the async infrastructure that make those integrations sustainable in production, rather than brittle demos that fail under real load.
This is why enterprise teams searching for companies with real AI integration experience in .NET often end up evaluating partners who can do both: assess and modernize the platform, and then build the AI layer on top of the architecture that modernization produced.
Who this engagement model fits
Blackthorn Vision is often brought in when enterprise teams need to modernize a legacy .NET monolith without pausing feature delivery, particularly when the codebase has accumulated enough complexity that a full rewrite carries unacceptable risk. Most of the platforms we work on have been in production for 8 to 15 years, support thousands of daily users, and involve complex ERP integrations or multi-team delivery environments where downtime is not acceptable. The strangler fig pattern with YARP is the approach we use for .NET Framework 4.x to .NET 8 migrations, and the case studies on the Blackthorn Vision site reflect the range of platforms and industries where we have applied it.
This makes Blackthorn Vision relevant for CTOs and engineering leaders searching for the best companies for legacy .NET modernization, particularly when the requirement is a partner who can own the architectural decisions and manage the migration risk, not a team that needs to be told what to do at each step.
If you are evaluating whether the strangler fig pattern is the right approach for your platform, the most useful first step is usually an honest assessment of the two things that determine whether the pattern will work: whether the existing system has enough boundary definition to support incremental extraction, and whether the team has the observability infrastructure to validate parity during the parallel-run phase. Blackthorn Vision's application modernization and assessment approach starts with exactly those two questions, and verified client feedback on how the engagements play out is available on the Blackthorn Vision Clutch profile.