[ APP MODERNIZATION ] // .NET FRAMEWORK → .NET 8

Your .NET Framework 4.x app isn't dying. It's just expensive to keep alive.

We migrate ASP.NET WebForms, WCF, and System.Web-coupled monoliths to .NET 8 incrementally — using YARP, the Upgrade Assistant, and CoreWCF — without a six-month feature freeze.

Veteran-Owned SDVOSB
[001 / 005] Field Conditions

Most .NET Framework migrations stall at the first WCF service or WebForm.

// SITUATION

The pattern is consistent. A team gets approval to move off .NET Framework 4.7.2, runs the Upgrade Assistant on the main project, and hits a wall: System.Web is everywhere, three internal services use WCF with NetTcpBinding, half the app is WebForms, and there's a custom HttpModule nobody remembers writing. The team picks the biggest project to convert first, branches off main for four months, can't keep up with feature work shipping on the legacy branch, and the migration quietly dies. Meanwhile, support contracts expire and the security team starts asking pointed questions.

  • ▸ System.Web.HttpContext referenced from business logic layers, making controllers impossible to port without an adapter shim.
  • ▸ WCF services with NetTcpBinding or MSMQ transport that have no direct equivalent in modern .NET without CoreWCF.
  • ▸ WebForms pages with code-behind tightly coupled to ViewState, postbacks, and server controls — no automated converter exists.
  • ▸ Big-bang migration branches that diverge from main for months, then can't be merged because feature work kept shipping.
< 2 wks
From kickoff to first ported route in production
0
Feature freezes required during migration
60-70%
Of mechanical upgrade work handled by tooling
[002 / 005] Operational Approach

Assess honestly, strangle incrementally, ship in production every two weeks.

  1. STEP-01

    Honest dependency inventory

    Run Microsoft .NET Upgrade Assistant and try-convert against every project, then walk the report manually. We catalog System.Web, WCF service contracts, WebForms pages, AppDomain usage, BinaryFormatter, Enterprise Library, and any COM interop. Each gets a port/replace/retire decision before any code moves.

  2. STEP-02

    Stand up a side-by-side host

    We build the new .NET 8 host alongside the Framework app, sharing the same database and auth. YARP reverse-proxies traffic so individual routes can move one at a time. No flag day, no parallel infrastructure to maintain for six months.

  3. STEP-03

    Strangle by bounded context

    Pick the leaf modules first — reporting endpoints, background jobs, internal admin. Port them to .NET 8, route traffic via YARP, monitor for a week, then move inward toward the WebForms or WCF core. Each merge is shippable on its own.

  4. STEP-04

    Replace the Windows-isms

    WCF SOAP services move to CoreWCF or gRPC depending on consumers. WebForms gets rewritten to Razor Pages or Blazor Server, not Angular-from-scratch. System.Web.HttpContext usages get isolated behind an adapter so business logic ports without rewrite.

  5. STEP-05

    Cut over and decommission

    Once the last Framework route is dark in YARP for two weeks, we delete the old IIS site, retire the Windows Server VM, and consolidate CI/CD onto a single GitHub Actions or Azure DevOps pipeline targeting Linux containers where the workload allows.

// CSHARP PATTERN 
// Program.cs — .NET 8 host running side-by-side with legacy ASP.NET Framework app
// YARP routes traffic per-path so we can strangle the monolith one endpoint at a time.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddReverseProxy()
    .LoadFromMemory(
        routes: new[]
        {
            // Already ported to .NET 8 — handled in-process
            new RouteConfig { RouteId = "reports", ClusterId = "self",
                Match = new RouteMatch { Path = "/api/reports/{**catch-all}" } },

            // Still on Framework / IIS — proxied back to the legacy app
            new RouteConfig { RouteId = "legacy", ClusterId = "legacy_iis",
                Match = new RouteMatch { Path = "/{**catch-all}" } }
        },
        clusters: new[]
        {
            new ClusterConfig
            {
                ClusterId = "legacy_iis",
                Destinations = new Dictionary<string, DestinationConfig>
                {
                    ["iis"] = new() { Address = "http://legacy.internal:8080/" }
                }
            }
        });

var app = builder.Build();
app.MapReverseProxy();
app.MapControllers(); // ported endpoints live here
app.Run();

YARP in front of both hosts is the single highest-leverage pattern for incremental .NET migrations — it lets you ship one route at a time without DNS games.

[003 / 005] Common Questions

Field FAQ.

→ How long does a typical .NET Framework to .NET 8 migration actually take?

For a single web app of 100k–300k lines with a normal SQL Server backend and no exotic dependencies, expect 4–7 months end to end with two engineers. WebForms-heavy apps run longer because the UI gets rewritten, not ported. WCF-heavy apps are faster than people expect once CoreWCF is on the table. The honest answer requires a two-week assessment first — anyone quoting a fixed timeline before reading your code is guessing.

→ Is the Microsoft .NET Upgrade Assistant actually useful or just marketing?

It's genuinely useful for the mechanical 60% — updating csproj formats, retargeting framework references, flagging incompatible APIs, and applying known code fixes. It will not solve your hard problems: System.Web coupling, WCF service contracts, WebForms pages, or anything touching HttpContext directly. Treat it as a power tool that handles boilerplate so your senior engineers focus on architectural decisions. We run it on every engagement, then review its output line by line.

→ Should we go big-bang or incremental?

Incremental, almost always. Big-bang migrations fail because you can't ship for months, the business keeps changing the Framework app under you, and merge conflicts compound. The strangler pattern with YARP lets you deploy weekly, keep the legacy app earning revenue, and roll back any single route in minutes. The only case for big-bang is small apps under ~30k lines where the rewrite is genuinely faster than the orchestration.

→ What happens to our WCF services?

Three options depending on who calls them. If internal .NET clients only, port to CoreWCF — it's a community-maintained reimplementation that supports most bindings and lets you keep service contracts intact. If external consumers can change, move to gRPC or REST, which are first-class in modern .NET. If you have BasicHttpBinding SOAP clients you don't control, CoreWCF with WSHttpBinding is the pragmatic answer. We benchmark each path before committing.

→ Can WebForms be ported automatically?

No. WebForms has no path forward in modern .NET and no automated converter produces usable output. The realistic targets are Razor Pages (closest mental model, server-rendered, minimal JavaScript) or Blazor Server (component model, SignalR-backed, good for internal apps). We rewrite page by page, keep the same URLs via YARP, and reuse business logic and EF models. Plan on roughly 1–2 days per non-trivial WebForm including testing.

→ What about Windows-only dependencies like System.Drawing or the registry?

System.Drawing.Common still works on Windows in .NET 8 but is deprecated cross-platform — we usually move to ImageSharp or SkiaSharp. Registry access via Microsoft.Win32.Registry is supported on Windows targets only. If you need to stay on Windows Server, that's fine — modern .NET runs there well. The decision to move to Linux containers is separate from the framework upgrade and shouldn't be bundled unless there's a real reason.

→ Does VooStack's SDVOSB status matter for federal .NET modernization work?

Yes, materially. As a Service-Disabled Veteran-Owned Small Business, we're eligible for SDVOSB set-aside contracts and sole-source awards up to the SDVOSB threshold. Agencies modernizing legacy .NET Framework systems — common at DoD, VA, and civilian agencies running ASP.NET WebForms apps from the 2010s — can contract with us directly under simplified vehicles. We hold the certifications and have shipped in FedRAMP and IL4/IL5 environments.

→ How do you handle the database during migration?

We don't touch it during the framework upgrade. EF6 has a supported path forward — you can keep EF6 in .NET 8 if your model is large, then migrate to EF Core as a separate project once the framework cutover is stable. Mixing two major changes (runtime + ORM) is how migrations slip six months. Same database, same schema, same connection strings during the port. ORM modernization comes after.

→ What does an assessment cost and what do we get?

Our standard assessment is a fixed-fee two-week engagement. Output is a written report covering project-by-project upgrade complexity, dependency risk register, WCF/WebForms/System.Web inventory, recommended sequencing, realistic timeline with confidence intervals, and a working proof-of-concept showing one endpoint ported and running under YARP. You own the artifacts whether or not you continue with us. No NDAs that lock you in, no abstract roadmaps.

[004 / 005] Adjacent Files

Continue recon.

REL-01

Modernization services

How we scope, sequence, and ship legacy-to-cloud migrations across .NET, Java, and PHP stacks.

 REL-02

Migration case studies

Real engagements: WebForms to Blazor, WCF to CoreWCF, on-prem IIS to containerized .NET 8.

 REL-03

Assessment packages

Two-week fixed-fee .NET Framework assessment with working proof-of-concept and written report.

 REL-04

Talk to an engineer

Skip the sales call. Get on a 30-minute technical call with someone who has shipped this.
[ NEXT ACTION ]

Get a real assessment of your .NET Framework codebase — not a sales deck.

Talk to a VooStack operator. We respond within one business day.

Open a Channel Full Services