.NET Migration and Modernization Services

.NET modernization is the work of moving applications built on .NET Framework, ASP.NET WebForms, MVC, WCF or Classic ASP onto modern .NET (8, 9 and later) and, where it makes sense, onto Azure, without a rewrite from scratch. PS3G has worked on the Microsoft stack for more than ten years. We start with an assessment, choose the least disruptive path for each application, migrate in increments, and test for parity before cutover. It fits a founder whose first product has become a legacy system, an operations team with an aging intranet, and an IT director with a portfolio of .NET Framework applications to plan for.

Why migrate now

.NET Framework 4.8 is the last major version of the Windows-only framework. Microsoft continues to service it as a component of Windows, but new features, performance work and most new libraries go to modern .NET. For the exact support status of each version, check Microsoft’s lifecycle page. We do not publish dates here because they change and because the right date for you also depends on your Windows Server version.

The practical reasons to act usually look like this:

• Security and compliance. Auditors and customers ask about supported platforms. Older NuGet packages stop receiving fixes, and some have known vulnerabilities with no patched version for .NET Framework.
• Hosting cost. .NET Framework needs Windows Server and IIS. Modern .NET runs on Linux and in containers, which opens up Azure App Service on Linux, Container Apps and Kubernetes, and usually a smaller bill.
• Performance. ASP.NET Core is considerably faster than ASP.NET on .NET Framework for the same workload, which often means fewer servers.
• Hiring. Developers want to work on ASP.NET Core, Blazor and Azure. A WebForms codebase makes recruiting harder every year.
• Everything new assumes modern .NET. Blazor, minimal APIs, gRPC, .NET Aspire, the AI libraries and the newer Azure SDKs target modern .NET first or only.

The counter-argument is real too. A stable internal application with few users and no external exposure may be fine where it is for a while. Our assessment tells you which of your applications are in that category.

What we migrate

You have	Where it goes	Typical path
ASP.NET MVC 5 or Web API 2 on .NET Framework	ASP.NET Core MVC and Web API	In-place upgrade or incremental migration; controllers and views mostly carry over
ASP.NET WebForms	Blazor, Razor Pages or MVC	Incremental: new pages in ASP.NET Core alongside old ones, retired page by page
WCF services	CoreWCF, gRPC or ASP.NET Core Web API	Depends on who calls the service and which bindings are in use
Windows services and scheduled jobs	.NET Worker Services, Azure Functions, containers	Usually the easiest part of a portfolio
Classic ASP (VBScript)	ASP.NET Core Razor Pages or MVC	Rewrite of the page layer; the database usually stays
VB.NET web applications	C# on ASP.NET Core	Language conversion plus framework migration; VB class libraries can stay in VB
WPF and Windows Forms desktop apps	The same frameworks on modern .NET, or .NET MAUI	Often an in-place upgrade with Microsoft’s upgrade tooling
Older SQL Server versions	Current SQL Server, Azure SQL Database or SQL Managed Instance	Assessed and moved alongside the application

Our approach

1. Assessment

We run Microsoft’s .NET upgrade analysis tooling across every project, review the dependency graph (NuGet packages without modern .NET versions, COM components, System.Web references, AppDomain and remoting use, third-party control suites) and talk to the people who run and use the application. The output is a report that rates each application by effort and risk and recommends a path.

2. Strangler-fig or in-place

Where the code is largely MVC, Web API, class libraries and services, we upgrade in place: SDK-style project files, package updates, code fixes, and a move to ASP.NET Core’s hosting, configuration and dependency injection model. Where the application is large or has WebForms pages, we use the strangler-fig pattern: a new ASP.NET Core application sits in front, a reverse proxy (YARP) routes unmigrated paths to the old application, and Microsoft’s System.Web adapters share session and authentication between the two while routes move over one at a time. Users see one application throughout. Microsoft documents this pattern as incremental ASP.NET to ASP.NET Core migration.

3. Testing

Our software testing team builds a parity suite before migration starts: functional tests of current behavior, API contract tests, data comparisons and a performance baseline. The migrated application has to pass the same suite. Unit and integration tests are added as code is touched, so the application ends the project in better shape than it started.

4. Cutover

Side-by-side running, a staged switch of traffic, a rollback plan and monitoring on both sides. On the strangler-fig path, cutover happens gradually and the final step is turning off the last legacy route.

Ask for a migration assessment of your .NET applications.

WebForms and WCF: the hard parts and the options

Two technologies did not make the move to modern .NET and need a decision rather than a tool.

ASP.NET WebForms

There is no WebForms in ASP.NET Core. The options are a rewrite of the page layer in Blazor, which has a component model, event handling and server-side state that feel familiar to WebForms developers; a rewrite in Razor Pages or MVC with a JavaScript front end; or an incremental migration where WebForms pages keep running behind the YARP proxy until each is replaced. Business logic that lives in code-behind files is the main cost driver, and separating it is usually the first task. Our guide on WebForms and Classic ASP modernization compares the options in detail.

WCF

Modern .NET can call WCF services through the client libraries, but it cannot host them with the original framework. CoreWCF, a community-maintained port that Microsoft supports, keeps existing contracts and the common bindings (BasicHttp, NetTcp and much of WSHttp) with few code changes, and is the lowest-risk choice when external systems depend on SOAP.

gRPC fits service-to-service calls that need contract-first design and high throughput. ASP.NET Core Web API (REST) fits browser, mobile and partner clients. Many portfolios end up with a mix, and the Upgrade Assistant includes a WCF-to-CoreWCF path.

A related question is whether to split a monolith into microservices during the migration. Our usual answer is no, not yet: migrate the monolith first, then extract services where there is a real scaling or team-ownership reason. The guide on monolith to microservices explains when the split is worth it.

Moving to Azure alongside the upgrade

Migration is the natural moment to change where the application runs. Typical combinations:

• ASP.NET Core on Azure App Service (Windows or Linux) with Azure SQL Database, Key Vault for secrets and Application Insights for monitoring.
• Containers on Azure Container Apps or AKS for applications that were already split into services, or that will be.
• Worker Services and scheduled jobs on Azure Functions or Container Apps jobs.
• Entra ID replacing Windows authentication or a custom membership database.
• Azure DevOps or GitHub Actions pipelines, with infrastructure defined in Bicep or Terraform.

We sequence this carefully. Upgrading the framework and changing the hosting platform in one step doubles the variables when something breaks. The usual order is framework first, then platform, unless hosting is the urgent problem. Our cloud migration team handles the infrastructure side and is vendor-neutral, so AWS or Google Cloud are options if that is where you already run.

What you get

• Assessment report: inventory, dependency findings, an effort and risk rating per application, and a recommended path and sequence.
• Migration plan: milestones, cutover strategy, testing approach, hosting target and the responsibilities on each side.
• Migrated code on modern .NET, in your repository, with SDK-style projects, dependency injection, configuration and logging done the current way.
• Tests: the parity suite plus unit and integration tests for the code we touched, wired into a CI pipeline.
• Documentation: architecture, deployment steps, runbooks and a list of deferred items.
• Handover or ongoing support: training for your team, or a managed-services agreement under defined SLAs.

Engagement models

• Fixed-scope project. An assessment with a written report, or the migration of a defined set of applications, quoted up front.
• Dedicated team or staff augmentation. Migration engineers working inside your team on a monthly basis, useful for a large portfolio migrated over several quarters.
• Managed services. We run the migrated applications afterward under defined SLAs, including the annual .NET upgrade.
• Advisory. Assessment and plan only, for a team that will do the migration itself.

How we start: a first conversation, a short assessment, a written proposal.

Why PS3G for .NET modernization

We have worked on the Microsoft stack for more than ten years, with engineers certified on Microsoft and open-source technologies, a US headquarters in Wilmington, Delaware and an India delivery center. We build and run our own products, including our HIPAA-compliant EHR and telehealth platform, DocVilla, so we know what it costs to keep a production system current while customers depend on it. Our testing center of excellence makes parity testing a first-class part of every migration rather than an afterthought. Ongoing .NET development after the migration is available from the same team.

Related services

• .NET development services: new features and products on modern .NET once the migration is done.
• Application modernization: for legacy systems in other stacks, or a portfolio-wide plan.
• Cloud migration: the infrastructure side of moving to Azure, AWS or Google Cloud.
• Software testing and QA: the parity and regression suites that make cutover safe.
• Microsoft technology services: SQL Server, Azure, Dynamics 365 and Microsoft 365 work around the application.
• All services: everything we build, modernize and run.

Guides on this topic

• .NET Framework End of Life: How to Migrate to Modern .NET
• ASP.NET WebForms and Classic ASP Modernization: Your Realistic Options
• Monolith to Microservices: When It’s Worth It and How to Do It

Frequently asked questions

Is .NET Framework end of life?

.NET Framework 4.8 is the last major version and Microsoft has said it will continue to service it as a component of Windows, so it is not abandoned, but it receives no new features and the ecosystem has moved to modern .NET. Support for older 4.x versions and for the Windows versions that carry the framework varies, so check Microsoft’s lifecycle page for your exact combination before you plan.

How long does a .NET Framework to .NET Core migration take?

It depends on the size of the codebase, how much of it is WebForms or WCF, how many third-party packages lack modern .NET versions, and whether tests exist. A class library or Windows service can often be upgraded in place quickly; a large WebForms application is a multi-phase program. The assessment gives you a per-application estimate in writing before you commit to anything.

What is the difference between ASP.NET and ASP.NET Core?

ASP.NET is the web framework inside .NET Framework: Windows-only, hosted in IIS, with System.Web, WebForms and MVC 5. ASP.NET Core is a rewrite for modern .NET: cross-platform, hosted on Kestrel behind any reverse proxy, with built-in dependency injection, middleware, Razor Pages, MVC, minimal APIs, SignalR and Blazor. Code written against MVC 5 and Web API 2 carries over with moderate changes; WebForms and WCF hosting do not.

Do we have to rewrite our WebForms application?

The page layer, yes, because WebForms does not exist in ASP.NET Core. The rest often does not. Business logic, data access and the database can usually be kept and reused, and the incremental approach lets old and new pages run side by side while the rewrite proceeds one screen at a time. Blazor is the most common target because its component model is familiar to WebForms developers.

Should we move to microservices during the migration?

Usually not at the same time. Changing the framework and the architecture together makes every problem harder to diagnose. We recommend migrating the application as it is, getting it stable on modern .NET and a CI pipeline, then extracting services where a clear scaling, deployment or team-ownership reason exists. .NET Core microservices are well supported when you get there, with gRPC, containers and .NET Aspire.

Can we migrate to .NET Core without moving to Azure?

Yes. Modern .NET runs on Windows Server with IIS, on Linux, in containers and on any cloud. Many clients upgrade the framework first and keep their current hosting, then decide about Azure, AWS or Google Cloud later with better information. If you do move, doing it as a second step keeps the variables separate and the rollback plan simple.