ASP.NET Development: From Web Forms and MVC to ASP.NET Core

How we build ASP.NET Core web apps, keep legacy Web Forms and MVC systems secure, and migrate them to modern .NET one route at a time.

Inferne Team 6 min read

A grid of old hatched modules being replaced one by one, with a crane lowering the next new module into place.

Most ASP.NET development requests we see fall into two groups. Some teams want a new web application on ASP.NET Core. Many more run an ASP.NET system on the .NET Framework, often Web Forms or MVC, that has handled a core business process for years and now raises hard questions about hosting, hiring, security and what comes next.

Good looks like a system you are not afraid of: patched and hardened today, with its risky parts covered by tests, and a path to modern .NET that moves one piece at a time while the business keeps running. For new builds, it looks like ASP.NET Core done cleanly from the first commit.

What our ASP.NET development work covers

  • Line-of-business web applications: portals, approval workflows, reporting and case management
  • Customer-facing web apps that integrate with Microsoft identity, SQL Server and Office tooling
  • Web APIs consumed by mobile apps, partner systems and single-page front ends
  • Legacy Web Forms, MVC, Web API, WCF and ASMX services that need maintenance, integration work or a migration plan

New work goes on ASP.NET Core, the cross-platform successor to classic ASP.NET, and follows the same discovery-to-launch process we use for all web application development. Our .NET development article covers the wider platform. This one focuses on the web layer, and on the legacy systems many organizations still depend on.

The state of classic ASP.NET, honestly

Classic ASP.NET runs on the .NET Framework, and the .NET Framework is finished. Its final release line still gets security and reliability fixes because it ships as a component of Windows, and it is supported for as long as the Windows version it runs on. So a Web Forms application is not unsupported. It is frozen.

That has practical consequences:

  • No new framework features, and fewer new libraries that target the .NET Framework.
  • Windows Server and IIS hosting only, which narrows container and cloud options.
  • Web Forms and the server side of WCF were never ported to modern .NET, so moving them means rebuilding, not recompiling.
  • A shrinking pool of developers who know Web Forms well, and fewer who want to work in it.

None of this forces an immediate rewrite. It does mean the system needs active care and a plan.

Keeping a legacy ASP.NET system secure

When we take over a .NET Framework application, the first pass is about risk, not features:

A legacy server inside concentric walls with one guarded gate, a key kept deep inside and a watchtower for monitoring.
  • Patch the platform. Windows Server, IIS and .NET Framework updates are applied on a schedule, and TLS is limited to current protocol versions.
  • Protect the machine key. ViewState and authentication cookies depend on it. Attackers have used keys copied from public code samples or leaked in repositories to forge ViewState and run code on servers. We rotate any key that was ever exposed and keep keys out of source control.
  • Harden configuration. Debug compilation off, custom errors on, version headers removed, cookies set to HttpOnly and Secure, and request validation left on.
  • Fix the classics. Anti-forgery tokens on forms, parameterized queries everywhere, and authorization enforced on every page and endpoint rather than by hiding menu items.
  • Update dependencies. Old NuGet packages and bundled JavaScript libraries often carry known vulnerabilities, and many can be updated without touching the framework.
  • Add visibility. Centralized logging and error monitoring, so problems reach us before they reach users.

Moving to ASP.NET Core without a big bang

Rewriting a system that runs the business in one go is the riskiest option available. We prefer incremental migration, an approach Microsoft documents and provides tooling for:

One gateway routing requests to a new modular building and to an old one, with a shared key passed between them.
  1. Put a new ASP.NET Core app in front. Using the YARP reverse proxy, it forwards every request it does not yet handle to the old application. Users see one site.
  2. Share what must be shared. Microsoft’s System.Web adapters let both applications share authentication and session state during the transition.
  3. Move shared code first. Business logic moves into class libraries that both applications can reference, targeting .NET Standard or both frameworks at once.
  4. Migrate route by route. Each page, controller or endpoint is rebuilt in ASP.NET Core, tested and switched over, until the old application can be turned off.

Decisions by technology

  • MVC and Web API port most directly. Controllers and views change, but the structure carries over.
  • Web Forms pages are rebuilt, usually as Razor Pages, or as Blazor components when they are highly interactive. Blazor’s component and event model feels familiar to Web Forms developers.
  • WCF services can move to CoreWCF, an open-source port of the WCF server, or be replaced with REST or gRPC when every client can change.
  • Windows Workflow Foundation has no official successor, so workflows are usually rewritten in code or moved to a maintained workflow engine.
  • Entity Framework 6 runs on modern .NET, so the move to EF Core can happen later, off the critical path.
  • Code built on HttpContext.Current, Global.asax and web.config is refactored toward dependency injection, middleware and standard configuration.

New ASP.NET Core applications

For new builds, we choose the web model by the product, not by habit:

  • Razor Pages or MVC for server-rendered applications, admin tools and content-heavy sites where SEO and simple hosting matter.
  • Web APIs, with controllers or minimal APIs, behind a JavaScript front end or a mobile app. Angular is a common partner for .NET in enterprise teams, and our Angular development article covers that side.
  • Blazor for internal tools where a C#-only team benefits from one language end to end.

The quality bar is the same in each case. Integration tests run the real HTTP pipeline against a real database in a container. Authentication goes through ASP.NET Core Identity or your organization’s identity provider. Security headers and rate limiting sit at the edge, and structured logs and traces exist from the first deployment. Because ASP.NET Core runs on Linux and in containers, it also opens hosting options that are often cheaper than a Windows-only setup.

When to maintain, when to migrate

Not every legacy system should move. Our usual guidance:

  • Maintain and harden when the application is stable, changes rarely, and is due to be replaced within your planning horizon.
  • Migrate incrementally when the system is central, still evolving and expensive to replace, which describes most of the ASP.NET applications we are asked about.
  • Replace when the business process has changed so much that the old data model no longer fits, or when an off-the-shelf product now covers the need.

Sometimes ASP.NET is not the right destination at all. If your team works mainly in JavaScript or PHP and the Microsoft ecosystem is not a factor, rebuilding in their stack can be the cheaper long-term choice. We will tell you when that is the case.

How an engagement works

We usually begin with a focused assessment under NDA, covering the codebase, hosting and dependencies. You receive a written report: security findings ranked by severity, what can be migrated directly and what must be rebuilt, and a phased plan with the trade-offs of each option.

The delivery team is shaped by that plan: .NET engineers, a QA tester who builds regression tests before anything moves, and a business analyst when undocumented behavior has to be recovered from the people who use the system every day. You see progress in regular demos and written reports, and every change lands in your own repository with the documentation to support it.

Frequently asked questions

Is ASP.NET Web Forms still supported?

The .NET Framework it runs on still receives security fixes as part of Windows, so it is supported in that sense. It gets no new features, and it will never run on modern .NET.

Can we move from .NET Framework to modern .NET without a rewrite?

Partly. Class libraries, MVC controllers and Web API code often port with moderate changes. Web Forms pages and WCF server code need rebuilding or replacing. Incremental migration spreads that work out and keeps the system live.

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

It depends on the size of the application and how much of it is Web Forms. After an assessment, we give you a phased plan in which each phase delivers something usable on its own.

Should we migrate to Blazor?

For interactive internal tools built by a C# team, it is a sensible target. For public-facing sites, Razor Pages or an API with a JavaScript front end is usually the safer choice.

Do we have to leave Windows hosting?

No. ASP.NET Core runs well on Windows and IIS too. Linux and containers become an option you gain, not an obligation.

If an ASP.NET system is carrying more of your business than anyone is comfortable with, start with a clear picture of where it stands. Tell us about your application, and we will suggest an assessment and a realistic first step.