ASP.NET Web Forms ablösen: Welche Wege es gibt und was sie kosten

Ihre Firma betreibt eine Anwendung, die auf ASP.NET Web Forms läuft. Sie funktioniert. Sie verdient Geld. Nur: Microsoft baut diese Technologie nicht mehr weiter. Eine ASP.NET Web Forms Migration klingt nach einem Projekt, das Sie lieber verschieben. Das Problem verschwindet dadurch aber nicht. Es wird nur teurer, je länger Sie warten.

Dieser Artikel zeigt, welche Wege zur Ablösung es gibt. Er nennt auch die Kosten. Und er zeigt, wie Sie migrieren, ohne alles neu zu bauen.

Was ist ASP.NET Web Forms und warum ist das jetzt ein Problem?

ASP.NET Web Forms kam 2002 mit dem ersten .NET Framework auf den Markt. Microsoft wollte Windows-Entwicklern ein vertrautes Modell bieten. Oberflächen aus Steuerelementen, ähnlich wie bei einer Desktop-Anwendung, nur im Browser.

Viele dieser Anwendungen laufen seit über zehn Jahren im Hintergrund. Intranet-Portale, interne Verwaltungstools, Erweiterungen für ERP-Systeme. Niemand hat sie seitdem grundlegend angefasst, weil sie einfach funktionierten.

Das Problem: Web Forms gehört zum klassischen .NET Framework. Dieses Framework hat keine Zukunft mehr. Microsoft entwickelt seit Jahren nur noch die neue Plattform .NET weiter, früher .NET Core genannt. Web Forms wurde dort nie übernommen. Es wird dort auch nicht mehr ankommen.

Was das für alte .NET-Framework-Versionen bedeutet, erklärt unser Artikel zum .NET Framework End of Life. Er geht das Thema ausführlich durch. Für Web Forms gilt dieselbe Logik, nur zugespitzt. Die Technologie wechselt nie auf die neue Plattform.

Welche Konsequenzen hat es, wenn Sie nichts tun?

Wer eine Web-Forms-Anwendung einfach weiterlaufen lässt, merkt das Problem zunächst nicht. Genau das macht es gefährlich.

Entwickler, die sich mit Web Forms gut auskennen, werden seltener. Viele sind im Ruhestand oder auf modernere Technologien umgestiegen. Wer heute jemanden für Web-Forms-Wartung sucht, zahlt einen Aufpreis. Das liegt am knappen Wissen, nicht an der Schwierigkeit der Arbeit.

Auch die Infrastruktur wird enger. Web Forms braucht den vollen Internet Information Services (IIS) unter Windows. Moderne Hosting-Optionen wie Linux-Container bleiben verschlossen. Wer Serverkosten senken will, hat mit Web Forms wenig Spielraum.

Und die Sicherheit bleibt nicht stehen. ASP.NET Web Forms selbst erhält kaum noch Weiterentwicklung. Neue Bibliotheken setzen zunehmend auf das moderne .NET. Wer auf Web Forms sitzen bleibt, flickt nur noch alte Löcher.

Für ein internes Tool mag das tragbar sein. Für eine Anwendung mit Kundendaten oder Zahlungsprozessen wird es schnell riskant. Ein Vorfall kostet dann deutlich mehr als die Migration selbst.

Welche Wege gibt es, Web Forms abzulösen?

Für eine ASP.NET Web Forms Migration gibt es nicht den einen richtigen Weg. Es gibt drei realistische Richtungen. Welche passt, hängt von Ihrer Anwendung ab.

Migration zu Blazor

Blazor ist Microsofts aktuelles Framework für interaktive Weboberflächen. Es läuft auf der modernen .NET-Plattform. Entwickler schreiben die Oberfläche in C#, nicht in JavaScript.

Für Teams, die bereits .NET-Entwickler haben, ist das ein naheliegender Weg. Das Wissen aus der alten Anwendung lässt sich teilweise übertragen. Die Lernkurve bleibt überschaubar, weil die Sprache gleich bleibt.

Migration zu Razor Pages oder ASP.NET Core MVC

Razor Pages und ASP.NET Core MVC trennen Oberfläche und Logik klarer als Web Forms. Die Seiten werden auf dem Server gerendert und als normales HTML ausgeliefert.

Dieser Weg passt gut zu Anwendungen, die vor allem Formulare und Listen zeigen. Die Umstellung bedeutet mehr Struktur im Code. Dafür laufen diese Anwendungen auch auf Linux und in Containern.

API mit neuem Frontend

Bei diesem Weg wird die Geschäftslogik in eine API ausgelagert. Ein separates Frontend mit React, Vue oder Angular übernimmt die Oberfläche.

Das ist der aufwendigste Weg. Er ist aber auch der zukunftsoffenste. Die Anwendung lässt sich später leichter erweitern, etwa um eine mobile App. Für kleine interne Tools ist dieser Aufwand oft nicht nötig.

Welcher Weg passt zu Ihrer Situation?

Ein paar Fragen helfen bei der Entscheidung. Haben Sie bereits C#-Entwickler im Team oder im Umfeld? Dann liegt Blazor nahe. Soll die Anwendung später auch als native App laufen? Dann lohnt sich eine API mit eigenem Frontend.

Geht es vor allem darum, von Windows wegzukommen und Hosting-Kosten zu senken? Dann reicht oft schon Razor Pages oder ASP.NET Core MVC. Diese Variante bringt den geringsten Umbau im Denken des Teams. Das Grundprinzip serverseitiges Rendering bleibt gleich.

Was kostet eine Web-Forms-Migration?

Der Aufwand hängt stark vom Code ab, nicht nur von der Größe der Anwendung. Entscheidend ist der Blick ins Detail. Wie viel Logik steckt direkt im Code-Behind der Formulare? Gibt es automatisierte Tests? Und wie viele externe Abhängigkeiten nutzt das System?

Eine kleine interne Anwendung mit wenigen Formularen lässt sich oft in wenigen Wochen migrieren. Die Kosten liegen dann häufig im niedrigen fünfstelligen Bereich.

Eine gewachsene Fachanwendung mit hunderten Seiten dauert dagegen länger. Steckt viel Geschäftslogik im Code-Behind, werden daraus schnell mehrere Monate. Die Kosten können dann deutlich höher liegen, je nach Umfang auch im hohen fünfstelligen Bereich.

Eine seriöse Schätzung braucht immer einen Blick in den konkreten Code. Pauschale Preise pro Seite oder pro Formular sind selten belastbar.

Wie gelingt die Migration ohne kompletten Neustart?

Die größte Sorge bei einer ASP.NET Web Forms Migration ist meist dieselbe. Niemand will monatelang entwickeln, ohne dass im Betrieb etwas sichtbar wird.

Genau dafür gibt es einen bewährten Ansatz. Wir beschreiben ihn in unserem Artikel zum Strangler-Fig-Pattern. Statt die Anwendung auf einen Schlag zu ersetzen, wird sie Modul für Modul abgelöst. Neue Seiten entstehen in Blazor oder Razor Pages. Alte Seiten bleiben so lange bestehen, bis sie ersetzt sind.

Dieser Ansatz senkt das Risiko deutlich. Ein Fehlschlag in einem neuen Modul legt nicht die ganze Anwendung lahm. Der Betrieb läuft während der gesamten Migration normal weiter.

Nicht jede Anwendung profitiert gleich stark von diesem schrittweisen Umbau. Manchmal ist ein sauberer Neuanfang die bessere Wahl. Unser Artikel zur Frage Refactoring oder Rewrite gibt dafür einen strukturierten Rahmen.

Wann sollte die Migration beginnen?

Es gibt keinen einzelnen Termin, der die Entscheidung erzwingt. Stattdessen gibt es Signale, die Sie ernst nehmen sollten.

Suchen Sie seit Monaten erfolglos jemanden für die Web-Forms-Wartung? Das ist ein Signal. Wollen Sie neue Funktionen bauen, die mit dem alten Framework nur umständlich gehen? Auch das ist ein Signal. Steht ohnehin ein Serverwechsel oder ein Hosting-Vertrag zur Verlängerung an? Dann ist das ein guter Zeitpunkt, die Migration gleich mitzudenken.

Wer wartet, bis eines dieser Signale zur Krise wird, hat weniger Zeit. Eine saubere Planung wird dann schwierig. Was sich über Jahre an Code angesammelt hat, lässt sich in Ruhe besser abbauen. Unter Zeitdruck wird dieselbe Arbeit riskanter und teurer.

Fazit: Warten macht die Migration nicht billiger

ASP.NET Web Forms wird nicht plötzlich ausfallen. Das macht die Entscheidung schwerer, nicht leichter. Es gibt keinen Stichtag, der Druck erzeugt. Nur steigende Kosten, die sich leise aufbauen.

Je länger eine Web-Forms-Anwendung wächst, desto größer wird der spätere Migrationsaufwand. Wer früh einsteigt, hat mehr Optionen und niedrigere Kosten.

Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Web-Forms-Anwendung an und sagen Ihnen ehrlich, welcher Weg für Sie passt.