Here’s how I’ve seen .NET teams make that work \u2014 where to cut first, how YARP fits in, and what usually goes wrong.<\/p>\n
Body<\/h2>\nThe rewrite that never ships<\/h3>\n
I’ve seen this play out more than once.<\/p>\n
A team picks up a .NET Framework app \u2014 MVC, Web API, sometimes with a WCF layer everyone’s afraid to touch. Leadership wants .NET 8. Or cloud. Or both. Someone in a meeting says “let’s just rewrite it.” Everyone nods. Six months later the new codebase is maybe 40% done, production is still on the old system, and nobody brings up “migration” in meetings anymore.<\/p>\n
That’s not really a coding problem. It’s a planning problem. And honestly, Strangler Fig exists because full rewrites keep failing in exactly this way.<\/p>\n
What the Strangler Fig pattern means<\/h3>\n
Okay, the name is weird. A strangler fig is a plant that grows around a tree and eventually takes its place. Martin Fowler<\/a> used that image years ago to describe how you’d modernize software \u2014 not by swapping everything out on a deadline, but by slowly building around what’s already there.<\/p>\n For .NET teams, the practical version is simpler: put YARP or a gateway in front, pull features into new ASP.NET Core services one at a time, and leave the monolith running until each slice is proven. No Saturday-night switch \u2014 just small moves you can roll back.<\/p>\n Most old .NET Framework apps I’ve worked on look familiar: giant solution file, one SQL Server everyone shares, auth tangled into the web project, a Windows Service doing something important at 2 AM, and a DLL or two that hasn’t been touched since 2016.<\/p>\n Trying to untangle all of that in one project is brutal. Strangler Fig gives you permission to fix one headache<\/strong> first \u2014 reporting, notifications, a customer API \u2014 while the rest of the app keeps chugging along. For a lot of teams, that’s the only approach that doesn’t get blocked by risk committees.<\/p>\n The mistake I see most often? Teams try to extract the “data layer” or “business layer” first because it looks clean on a whiteboard. In a codebase that’s 10+ years old, those layers are usually a mess \u2014 session state, stored procedures, business rules all mixed together.<\/p>\n Look for a business feature<\/strong> with a small surface area instead:<\/p>\n I’d stay away from core order processing, anything with distributed locks, or shared login\/session stuff unless you’ve thought through identity properly. One question helps: if this breaks for a day, how bad is it?<\/em> Start where the answer is “annoying, not catastrophic.”<\/p>\n First thing we usually do once we’ve picked a slice: stop exposing legacy and new stuff on separate URLs. One entry point. One place to decide where traffic goes.<\/p>\n If the team is mostly .NET, we reach for YARP<\/strong> a lot. Bigger setups might need a full API gateway; a BFF helps when clients need responses stitched from multiple backends.<\/p>\n Here’s a simple YARP setup we use fairly often \u2014 anything under Host side is short \u2014 register reverse proxy, load config, map it:<\/p>\n What I like about this stage: once routing works, shifting a path from old to new is often just a config edit. You’re not redeploying the whole monolith to test one change.<\/p>\n Pretty much how it works in real projects \u2014 legacy app stays up, YARP sits in the middle, and new services take over one route at a time.<\/p><\/div>\n Keep the first service boring. ASP.NET Core Web API, simple DTOs, logging, health checks. Don’t over-engineer it on day one.<\/p>\n It’s fine if the new service still reads from the same SQL Server at first. Not ideal long term, but realistic. We’ve done that plenty of times.<\/p>\n Version one isn’t about perfect architecture. It’s about proving you can send real traffic to new code and sleep through the night.<\/p>\n Big-bang cutovers are where things fall apart. Start with internal users. Then maybe 5% of production traffic. Then more. And know how to roll back before you flip anything \u2014 changing one route back to legacy should take minutes, not a war room.<\/p>\n Also \u2014 and teams skip this all the time \u2014 delete the legacy path<\/strong> once the new one is stable. I’ve seen projects run two systems for a year because nobody wanted to remove the old code. That’s not modernization. That’s just double the maintenance.<\/p>\n Before you call a slice “done,” I’d look for something like:<\/p>\n Shared database.<\/strong> This one catches people off guard. You stand up a shiny new microservice, but both apps still write to the same tables. On paper you’ve “extracted” something. In reality you’ve got the same coupling with extra deployment steps.<\/p>\n Session and login.<\/strong> If the legacy app uses Forms Authentication or in-proc session, don’t assume your new API can just plug in. We had a project stall for weeks because nobody mapped out how logged-in users would hit the new routes. Sometimes identity has to be the first slice, not the third.<\/p>\n Too many services, too fast.<\/strong> Five microservices sharing one database, deploying in a chain \u2014 often slower than the monolith you started with. One at a time is boring. Boring is fine.<\/p>\n Logging.<\/strong> Once traffic splits, “where did this request go?” is a real question. Set up correlation IDs and OpenTelemetry<\/a> before production routing, not after a late-night incident.<\/p>\n Timelines vary \u2014 routing alone took three weeks on one project, eight on another. But when someone asks what the first three months look like, this is roughly what I say.<\/p>\n Weeks 1\u20133:<\/strong> Map what the monolith actually does. Pick one seam that won’t blow up if it wobbles. Get YARP or a gateway in front. Add correlation IDs \u2014 basic, but easy to skip and regret.<\/p>\n Weeks 4\u20138:<\/strong> Build the first ASP.NET Core piece. Keep scope tiny. Non-prod first, then shadow traffic or internal users who’ll find the edge cases.<\/p>\n Weeks 9\u201312:<\/strong> Route real production traffic for that slice. Document rollback while you’re calm. If numbers hold for a few weeks, delete the legacy path \u2014 not “cleanup in Q4,” actually delete it.<\/p>\n You don’t need a three-year rewrite that ships half-finished. Strangler Fig is slower on paper and faster in reality, because you keep delivering while you move.<\/p>\n Pick a small slice. Get routing in place. Move traffic when you’ve got a rollback plan. Kill the old code when you’re sure. And when someone pushes for a full rewrite, ask which part of the business they’re fine pausing for six months. That tends to reset the conversation pretty quickly.<\/p>\n Working through a legacy .NET migration? Get in touch<\/a> or see our Application Modernization services<\/a>. Heading cloud-native next? Read our .NET Aspire post<\/a>. Done a strangler migration before \u2014 what did you pull out first? Leave a comment.<\/p>\n","protected":false},"excerpt":{"rendered":" Introduction Someone in leadership says “we need to move to .NET 8” or “let’s get this thing into Azure.” Cool. But when you ask what that actually means \u2014 which apps, which order, what happens to production while you’re mid-migration \u2014 you often get a vague answer and a timeline that makes no sense. I’ve […]<\/p>\n","protected":false},"author":2311,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":1,"footnotes":""},"categories":[5867],"tags":[8995,6734,3979,8993,8994],"class_list":["post-83014","post","type-post","status-publish","format-standard","hentry","category-net","tag-applicationmodernization","tag-dotnet","tag-microservices","tag-stranglerfig","tag-yarp"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\tWhy this works well for legacy .NET<\/h3>\n
Step 1: Find a seam, not a layer<\/h3>\n
\n
Step 2: Put a router in front<\/h3>\n
\/api\/reports\/*<\/code> goes to the new service, everything else falls back to legacy:<\/p>\n{\r\n \"ReverseProxy\": {\r\n \"Routes\": {\r\n \"reports-route\": {\r\n \"ClusterId\": \"reports-cluster\",\r\n \"Match\": { \"Path\": \"\/api\/reports\/{**catch-all}\" }\r\n },\r\n \"legacy-fallback\": {\r\n \"ClusterId\": \"legacy-cluster\",\r\n \"Match\": { \"Path\": \"{**catch-all}\" }\r\n }\r\n },\r\n \"Clusters\": {\r\n \"reports-cluster\": {\r\n \"Destinations\": { \"reports-api\": { \"Address\": \"https:\/\/reports.internal\/\" } }\r\n },\r\n \"legacy-cluster\": {\r\n \"Destinations\": { \"legacy-app\": { \"Address\": \"https:\/\/legacy.internal\/\" } }\r\n }\r\n }\r\n }\r\n}<\/code><\/pre>\nvar builder = WebApplication.CreateBuilder(args);\r\nbuilder.Services.AddReverseProxy()\r\n .LoadFromConfig(builder.Configuration.GetSection(\"ReverseProxy\"));\r\n\r\nvar app = builder.Build();\r\napp.MapReverseProxy();\r\napp.Run();<\/code><\/pre>\n![\"Diagram](\"https:\/\/www.tothenew.com\/blog\/wp-ttn-blog\/uploads\/2026\/09\/strangler-fig-diagram-1440x1000-1-1024x711.jpg\")
Step 3: Build the new slice<\/h3>\n
app.MapGet(\"\/api\/reports\/summary\", async (\r\n IReportService reports, CancellationToken ct) =>\r\n{\r\n var summary = await reports.GetSummaryAsync(ct);\r\n return Results.Ok(summary);\r\n});<\/code><\/pre>\nStep 4: Move traffic, then actually delete the old code<\/h3>\n
\n
Things that will bite you<\/h3>\n
What the first 90 days might look like<\/h3>\n
Conclusion<\/h2>\n