From ASP.NET Web Forms to .NET 8: A pragmatic migration path with Core Forms

Why this matters now

If you are still running a production ASP.NET Web Forms application, you know the bind: .NET Framework is stable and receives security updates, but meaningful new application development happens on .NET. At the same time, many business apps are deeply intertwined with the Web Forms runtime, having grown over years—sometimes decades—through tickets, emails, and bug fixes. A big-bang rewrite? Expensive, risky, hard to sell within ongoing projects—and often the prelude to the next tender.

This is the problem space addressed in “Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8” by Michael Ketting (RUBICON IT GmbH). We listened and distilled the approach: instead of reinventing Web Forms, lift the existing application to .NET 8 through a focused retargeting, then modernize incrementally where it matters for the business.

The answer is Core Forms: a Web Forms implementation for .NET (first .NET 6, now .NET 8) that runs in real projects and pragmatically addresses the deep coupling of Web Forms code and runtime. Our takeaway from the session: if you want your team on modern .NET without freezing feature work for years, this provides a workable bridge.

The context: Old meets new

Ketting frames the topic with the long arc of platform evolution:

• Web Forms was a huge productivity boost in the early 2000s. Many line-of-business apps were built on it.
• Microsoft has shifted new development to .NET. Web Forms remains tied to .NET Framework.
• Web Forms apps are tightly coupled to their infrastructure by design: event handlers and code-behind with limited separation, unlike modern MVC approaches.
• Large, organically grown codebases make a big-bang rewrite economically risky. Teams have invested years; behavior has emerged across specs, tickets, emails, and countless fixes.

He also cites a conference statistic from André Puré of “Sonocube”: in active, maintained projects, over five years roughly half of the code gets touched. Translated into a migration strategy: if you are touching code anyway, use those same change requests as a lever to modernize the parts that matter.

The idea: Retarget first, modernize afterwards

The strategy we took from the session is explicitly two-phased:

1) First, run the existing Web Forms application on .NET 8—without changing functionality. This reduces infrastructure debt, unlocks modern toolchains, and makes the app compatible with current .NET features.

2) Then, over time and in response to real change requests, migrate forms, controls, and logic where the business value is highest (think shopping cart and complex processes rather than basic master data screens).

The end-game is not “Web Forms forever,” but a clean migration path with Core Forms as the bridge. You end up with a modernized app that no longer needs Core Forms—just without years of upfront stall.

Core Forms in a nutshell: What it is—and isn’t

Core Forms is a Web Forms implementation for .NET 8, created by RUBICON IT GmbH. Key points from the talk:

• Product status: in production use; RUBICON has a vested interest in active maintenance.
• Platform: currently Windows-first (matching the historical Web Forms platform). Linux is possible if there is a business need; the talk focuses on Windows.
• Language: C# Web Forms pages are used in the demos. Visual Basic would be feasible if the compiler was wired in; most users are on C#.
• Artifacts: ASPX pages, Master Pages, User Controls, and classic ASMX web services are supported.
• Third-party: a “.NET Framework Bridge” allows existing control libraries (e.g., Telerik) to work unchanged.
• Licensing: commercial product with a trial license; its initialization is visible in the startup logic.

In short: it feels like Web Forms, but hosted on .NET 8 and integrated into an ASP.NET Core application.

The demo: Running Wingtip Toys on .NET 8

To prove feasibility, Ketting walks through the well-known Microsoft demo app “Wingtip Toys.” The process is short and precise, underlining how little application code needs to change to run on .NET 8.

1) Update dependencies

Start with hygiene: update NuGet packages and JavaScript libraries. Many legacy projects lag behind here; it’s a good moment to also resolve known security issues. Importantly, the app still runs on .NET Framework 4.8 at this point—Core Forms is not involved yet.

2) Create an ASP.NET Core app

Next, create an empty ASP.NET Core web app using Microsoft’s default template. This provides the hosting scaffolding (error page, index page, settings) for the later Core Forms integration.

3) Copy Web Forms code into the new project

Ketting copies the entire Wingtip Toys codebase into the new project (side-by-side for demo clarity; in real projects, integrate as you see fit). This keeps the functional code intact.

4) Adjust project file and configuration

Now, make the focused changes that enable retargeting:

• Migrate package references from packages.config to the new project file and add the Core Forms packages.
• Because some Full Framework assemblies are referenced, disable the corresponding NuGet warning.
• Adjust output paths and directories (aligned with ASP.NET Core defaults but tailored to the scenario).
• Add an app.config alongside web.config as shown in the demo.
• Update web.config: raise the target framework, register tag prefixes, reference assemblies that designers used to add implicitly, and enable the Core Forms session-state module.

5) Wire up Program.cs

Program.cs for the ASP.NET Core app stays familiar but gets a few critical additions:

• Initialize the Core Forms license (trial or production) because Core Forms is commercial.
• Run an early Initialize method. Rationale: Web Forms code relies heavily on statics; early initialization prevents anything from being used before it’s properly configured.
• Register Core Forms as a service and map ASPX files. Ketting stresses that Master Pages, User Controls, and ASMX are supported.

With these changes, Wingtip Toys starts on .NET 8—visible in the debugger—compiles its ASPX pages on first use, and runs. In the demo, startup even appears noticeably snappier.

Productivity features for the transition: Session and auth integration

With the bridge running, Ketting demonstrates how to productively connect the old and new parts through shared session and configurable authentication models.

Shared session between Core Forms and ASP.NET Core

Core Forms implements standard ASP.NET Web Forms session behavior. In addition, it exposes an in-memory object session as a service, which you add to the pipeline. This allows Razor Pages and ASPX pages to share session state in the same process.

Ketting shows a simple counter demo. Increment the counter on a Razor Page; refresh an ASPX page and see the same value. Increment there; refresh in Razor; the value continues. The message is straightforward: both worlds can share state seamlessly.

From a modernization perspective, this is powerful because you can build functional transitions without fragmenting user sessions. Writing to session is supported; Ketting suggests not to expand session usage unnecessarily when moving to modern patterns.

Authentication: separate, shared, or shared read-only

Ketting outlines three models for authentication:

• Separate (default): ASP.NET Core and Core Forms each manage authentication. This minimizes unintended side effects and is a safe starting point.
• Shared authentication: both sides can initialize and consume authentication, providing flexibility during migration.
• Shared read-only: ASP.NET Core creates the principal; Core Forms consumes it read-only. This is attractive if you want to consolidate auth on ASP.NET Core to take advantage of modern services and integrations, while still running existing Web Forms parts.

In practice, this lets teams move authentication to ASP.NET Core at their own pace, without duplicating effort on the Web Forms side.

Third-party controls: “It just works” via the .NET Framework Bridge

Many Web Forms apps rely on rich control suites like Telerik or DevExpress. The standard question—“What about our controls?”—looms large. Ketting’s answer: it works. The “.NET Framework Bridge” NuGet package establishes the compatibility layer.

In the demo, he copies Telerik samples from their demo site into a Core Forms app and shows the expected interactions:

• A data grid with working sorting.
• A tree with working drag-and-drop.

Boring is a feature here: unchanged controls drastically reduce migration risk.

Operations: Windows-first, Linux if needed

Core Forms currently runs on Windows, consistent with Web Forms history. Ketting notes that Linux is possible if there is a business need. Practically, this enables a quick migration on existing Windows infrastructure, keeping OS strategy changes as a separate decision.

Architectural perspective: A bridge, not a tunnel

From a software architecture standpoint, the staged strategy is compelling: retargeting as an infrastructure move now; modernization as feature work over the coming years. Three reasons this resonates in enterprise contexts:

• Minimal upfront investment. Tie modernization effort to changes you must make anyway, rather than placing a large, risky bet.
• Developer motivation. Teams can immediately use .NET 8, newer C# versions, and modern libraries—rather than being stuck on .NET Framework and older C#.
• Reduced risk. Modernize the complex, high-value flows (e.g., shopping cart) rather than sinking effort into low-value screens.

The conference observation from “Sonocube”—that active projects touch large portions of code over time—supports this empirically: after five years, a significant portion of critical paths will have received changes anyway, providing natural anchors for incremental migration.

A practical checklist we took from the session

If you plan to bridge a Web Forms app to .NET 8, follow the same pragmatic steps demonstrated in the talk:

1) Clean up the legacy project: update NuGet and JS dependencies without changing behavior.

2) Create an empty ASP.NET Core app: the default template is enough.

3) Copy over the code: bring the Web Forms code into the new project (side-by-side for clarity in demos; integrate as needed in real apps).

4) Adjust the project file: migrate package references, add Core Forms packages, tune warnings and output paths, add an app.config.

5) Update web.config: raise the target framework, register tag prefixes, reference assemblies that designers used to add, enable the Core Forms session-state module.

6) Enhance startup logic: initialize licensing, run an early Initialize method, register Core Forms and map ASPX/ASMX/Master/User Controls.

7) Start the app: verify .NET 8 in the debugger, allow the first ASPX compilation—your app runs.

8) Share session (optional): register the in-memory object session and enable it, allowing Razor Pages and ASPX to read/write shared state.

9) Choose an auth model: separate, shared, or shared read-only—depending on your modernization goals and current infrastructure.

10) Keep third-party controls: add the .NET Framework Bridge package; control suites like Telerik continue working as-is.

Realism over dogma: Why this works in the enterprise

Ketting is clear on why big-bang migrations collide with business realities: customers question ROI and duration; tender cycles add uncertainty; not every replacement project succeeds. The Core Forms bridge offers immediate benefits instead:

• Run on .NET 8: modern runtime, ecosystem, and tooling.
• Keep shipping: continue feature work and fold modernization into it.
• Happier developers: no longer confined to .NET Framework and older C#, teams can use current .NET features (Ketting mentions C# 11/12 and modern libraries such as a “Frozen Collection”).

Core Forms being in production and actively maintained by RUBICON improves planning confidence.

Where to start: links and docs from the talk

The session points to the key starting points:

• Website: coreforms.net for an overview
• Packages: available on NuGet
• Documentation: GitHub wiki “coreforms.docs” with guidance on third-party libraries, authentication/authorization, and the trial license
• Demos: the Wingtip Toys migration and the Telerik samples as shown

The trial license enables a frictionless evaluation. A regular license is required for production.

Our verdict

“Retargeting einer Anwendung mit ASP.NET Web Forms auf .NET 8” by Michael Ketting (RUBICON IT GmbH) delivers what enterprise teams need: not a silver bullet, but a robust, low-friction path forward. With a handful of project changes, Web Forms runs on .NET 8; session and auth can be shared in controlled ways; third-party controls keep working. Modernization then proceeds where the business value is, not as a pause button on delivery.

For teams responsible for substantial Web Forms systems that want to energize their developers with current .NET technologies, Core Forms is a bridge that keeps risk and rework low—while aligning investment with real change requests. That pragmatism is its strength.

The destination is a modernized app on .NET—not “Web Forms forever”—and you can get there without the costly standstill in between.

• 

  

  Capture Screenshots with Playwright & SpecFlow

  Hannes Etl von RUBICON IT spricht in seinem devjobs.at TechTalk über die Aufgabe, mit Playwright und SpecFlow eine große Zahl an Screenshots automatisiert zu erstellen und zu verwalten.

  Watch now

• 

  

  Dagmar Pill, Abteilungsleiterin & Sabine Eder, Abteilungsleiterin bei RUBICON IT

  Dagmar Pill und Sabine Eder von RUBICON IT sprechen in ihrem Interview über die Besonderheiten der Teams im Unternehmen, auf was beim Recruiting und Onboarding geachtet wird und welche Challenges es bei der Software Entwicklung gibt.

  Watch now

• 

  

  Peter Gößweiner, Lead Developer bei RUBICON IT

  Peter Gößweiner von RUBICON IT erzählt in seinem Interview von den spielerischen Anfängen als Kind und über seinen weiteren Werdegang – und was das Wichtigste für Neueinsteiger ist.

  Watch now
• 

  

  Stephan Palecek, Senior Deployment Engineer bei RUBICON IT

  Stephan Palecek von RUBICON IT redet im Interview von den frühen Anfängen mit BASIC, über seine Ausbildung, bis hin zu seiner aktuellen Arbeit und gibt Hinweise für Deployment Engineering Einsteiger.

  Watch now
• 

  

  Mathias Gartner, Lead Developer bei RUBICON IT

  Mathias Gartner von RUBICON IT redet im Interview über seine Anfänge in der Technik bis hin zur aktuellen Arbeit und teilt seine Gedanken, wie man am besten in die Software Entwicklung einsteigt.

  Watch now
• 

  

  Roman Brandstetter, Principal Developer bei RUBICON

  Roman Brandstetter von RUBICON erzählt in seinem Interview über seinen Werdegang mit dem Programmieren bis hin zu seinem breiten Aufgabenbereichen in der aktuellen Arbeit und was das Wichtigste als Neueinsteiger ist.

  Watch now
• 

  

  Rene Sorger, Junior Full Stack Developer bei RUBICON

  Rene Sorger von RUBICON redet in seinem Interview von seinem frühen technischen Interesse als Kind bis hin zu seiner aktuellen Arbeit als Full Stack Developer und gibt Tipps für den Einstieg.

  Watch now