ASP.NET WebForms modernisieren: Welche Optionen gibt es — und was kosten sie?

Es gibt diesen einen Anruf, der bei mir alle zwei Wochen ankommt:

"Wir haben eine WebForms-Anwendung von 2014. Sie läuft eigentlich
gut. Aber unser IT-Dienstleister hat gerade gemeint, das müssen wir
modernisieren. Was kostet das?"

Vor dem Antworten geht's um die richtige Frage: muss das wirklich
modernisiert werden — und wenn ja, jetzt? Diese Entscheidung
beantwortet sich nicht in einem Verkaufsgespräch, sondern entlang von
fünf Achsen: Risiko, Aufwand, Skill-Verfügbarkeit, Geschäftskritikalität
und Zeitdruck.

Drei Wege gibt's grundsätzlich. Hier eine ehrliche Einordnung jedes
einzelnen.

Warum WebForms 2026 zur Risiko-Position wird

Vier Punkte, jeder einzeln bewältigbar, alle zusammen aber irgendwann
nicht mehr:

1. Kein .NET-Core-Support, nie. WebForms lebt nur in .NET Framework
4.x. Microsoft hat klar gesagt: kein Port nach .NET 5/6/7/8/9 oder
neuer. Die Architektur (ViewState, Page-Lifecycle, Server-Controls)
passt nicht zu modernem ASP.NET. Du bist auf der Spur, die irgendwann
endet — die Frage ist nur wann.

2. .NET Framework 4.8.1 ist das Endlager. Microsoft pflegt es mit
Sicherheits-Patches solange Windows Server es supportet. Aber neue
Features, neue Tooling-Unterstützung (z. B. moderne IDE-Integrationen,
Container-Runtime-Optimierungen, neue Cryptographic APIs) gibt's nicht
mehr. Du bekommst Bugfixes, nicht Evolution.

3. Fachkräftemangel verschärft sich. Wer 2014 als Junior-Entwickler
mit WebForms angefangen hat, ist heute Anfang 30 und hat in den
letzten 8 Jahren wahrscheinlich Blazor, React oder Vue gelernt — nicht
mehr WebForms vertieft. Die Universitäten unterrichten WebForms seit
2018 nicht mehr aktiv. Wenn dein Inhouse-Entwickler in Rente geht oder
wechselt, wird der Nachfolger deutlich teurer und schwerer zu
finden.

4. Hosting-Realität. WebForms läuft auf Windows Server mit IIS.
Lizenz-Kosten Windows Server Standard 2022 (Stand 2026): ~1.000 EUR
pro Server, plus User-CALs. Moderne ASP.NET-Anwendungen laufen
genauso gut auf Linux mit Kestrel — und dort ist die OS-Lizenz null.
Bei 3–5 Servern Hosting-Footprint summiert sich das spürbar.

Keiner dieser vier Punkte ist akut kritisch. Aber sie alle drücken in
die gleiche Richtung. Die Frage ist nicht "ob", sondern "wann" und
"wie kontrolliert".

Weg A: Komplett-Neubau ("Big Bang")

Du baust die Anwendung neu, in der Zwischenzeit läuft die alte
unverändert weiter, und zum Stichtag X wechseln alle Nutzer auf die
neue.

Was dafür spricht

• Saubere Architektur ab Tag 1. Du musst nicht 12 Jahre alte
  Design-Entscheidungen mitschleppen.
• Modernes Datenmodell. Wenn das ursprüngliche Schema zu eng oder
  zu chaotisch ist, kannst du jetzt aufräumen.
• Klare Kommunikation an Anwender. "Am 1. Oktober wechseln wir."
  Kein monatelanger Schwebezustand.

Was dagegen spricht

• Doppel-Aufwand. Während du baust, läuft die alte App weiter und
  braucht weiter Pflege. Sechs bis 18 Monate parallel.
• Feature-Audit-Risiko. In jeder gewachsenen WebForms-Anwendung gibt
  es 30–50 Funktionen, die jemand im Haus regelmäßig nutzt, von denen
  aber niemand offiziell weiß. Beim Neubau werden die routinemäßig
  vergessen — und am Stichtag bricht der Vertriebsleiter zusammen, weil
  sein Excel-Export aus Modul 17 nicht mehr existiert.
• Risiko zu groß für kritische Systeme. Der "Big Bang" funktioniert
  in 60–70% der Fälle reibungslos. Die anderen 30–40% sind teuer.

Wann sinnvoll

• Kleine Anwendung (unter 20 Forms/Module)
• Wenig externe Integrationen
• Du wolltest sowieso das Datenmodell vereinfachen
• Anwendung ist nicht business-kritisch (Ausfall verschmerzbar)

Realistische Größenordnung

Diese Zahlen schwanken um den Faktor 2–3 je nach Komplexität,
Schnittstellen und benötigtem Compliance-Niveau. Sie sind nicht
verbindlich, aber sie helfen die Diskussion zu erden.

Weg B: Schrittweise Migration (Strangler-Fig)

Das ist der Weg, den ich in 70% der Mandate empfehle. Er hat einen
schönen Namen aus der Botanik.

Strangler-Fig erklärt — für Nicht-Techniker

Es gibt in den Tropen einen Baum, die Würgefeige. Sie wächst zunächst
um einen anderen, älteren Baum herum. Sie nutzt ihn als Stütze,
während sie sich nach oben rankt. Nach 20 oder 30 Jahren ist die
Würgefeige groß und stark — und der ursprüngliche Baum innen ist
abgestorben und manchmal verrottet. Übrig bleibt die Feige, die jetzt
selbständig steht.

In der Software-Welt: deine neue Blazor- (oder React-, oder
Razor-Pages-)Anwendung wächst um deine bestehende WebForms-Anwendung
herum. Sie ersetzt Stück für Stück Funktionen, ohne dass irgendwann
ein "Stichtag" nötig ist. Nutzer arbeiten von Anfang an in einem
gemischten System — manche Klicks gehen zur neuen, manche zur alten App.
Sie merken den Unterschied nur am etwas anderen Look einzelner Seiten.

Am Ende — nach 18, 24, manchmal 36 Monaten — ist die alte WebForms-
Anwendung leer. Niemand benutzt sie mehr, weil alle Funktionen migriert
sind. Du schaltest sie ab. Fertig.

Technisch — das absolute Minimum, dass ein Nicht-Techniker verstehen sollte

Vor beide Anwendungen kommt ein Reverse-Proxy (Apache, nginx, oder
ein Cloud-LoadBalancer). Der entscheidet pro URL, welche der beiden
Anwendungen die Anfrage bekommt:

• /auftrag/* → die NEUE Blazor-Anwendung
• /kunden/* → die NEUE Blazor-Anwendung
• alles andere → die ALTE WebForms-Anwendung

Bei jedem Sprint migriert ihr ein paar Routes, der Proxy zeigt von da an
auf die neue Anwendung, und kein Nutzer muss sich umstellen.

Was dafür spricht

• Niedrigeres Risiko. Wenn die neue Anwendung an einer Stelle einen
  Fehler hat, bleibt der Rest funktionsfähig. Rollback ist eine
  Proxy-Konfigurations-Änderung.
• Produktiv ab Woche 4. Die erste migrierte Funktion kann nach
  einem Monat live sein. Du musst nicht ein Jahr lang warten, um
  irgendetwas anzufassen.
• Lernkurve eingebaut. Dein Team lernt Blazor/Razor an einer
  kleinen Funktion und nicht an der kritischen Abrechnungslogik.
• Stakeholder-akzeptiert. Die Geschäftsführung sieht jeden Monat
  Fortschritt — kein "wir arbeiten seit 8 Monaten und ihr seht noch
  nichts"-Szenario.

Was dagegen spricht

• Längere Gesamtdauer. Big Bang könnte in 12 Monaten fertig sein,
  Strangler dauert 18–30.
• Infrastruktur-Aufwand. Der Reverse-Proxy, geteilte Authentifizierung
  zwischen beiden Anwendungen, eventuell geteilte Sitzung — das ist
  Engineering-Arbeit, die im Big-Bang-Ansatz wegfällt.
• Disziplin nötig. Wer ohne klares Ende-Datum startet, betreibt
  irgendwann 5 Jahre Parallelsystem. Antworten: mache ein Ablaufdatum
  Teil des Projekts.

Wann sinnvoll

• Mittlere bis große Anwendungen (20+ Forms)
• Kritischer Produktivbetrieb (Ausfall kostet viel)
• Risiko-averse Stakeholder
• Vorhandenes IT-Team das die Lernkurve begleiten kann

Realistische Größenordnung

Der Strangler kostet im Total tendenziell 20–30% mehr als ein
gelungener Big Bang. Er kostet aber deutlich weniger als ein
misslungener Big Bang — und der ist die häufigere Realität.

Weg C: Weiterbetrieb mit Risiko-Management

Der unterschätzte Weg. Manchmal ist die ehrlichste Antwort: wir
modernisieren noch nicht.

Was das nicht heißt

• Es heißt nicht "die Augen zu und durch".
• Es heißt nicht "auf .NET 4.5 stehen bleiben".
• Es heißt nicht "keine Sicherheits-Updates einspielen".

Was das heißt

• Anwendung auf .NET Framework 4.8.1 aktuell halten. Das ist
  Pflicht, nicht Verhandlungssache.
• Server-OS aktuell. Windows Server 2022 oder neuer. Kein Server
  2012 R2, der hat EOL.
• Dokumentierte Abhängigkeiten. Welche Pakete, welche Komponenten
  Drittanbieter (Telerik-Controls, Infragistics-Grids, etc.), welche
  davon noch supported?
• Jährlicher Health-Check. 1–2 Beratertage pro Jahr: läuft das noch
  sicher? Was hat sich am Bedrohungsbild geändert? Was sind die
  Migrations-Optionen, wenn wir nächstes Jahr loslegen würden?
• Notfall-Plan. Was passiert, wenn der einzige interne
  WebForms-Entwickler ausfällt? Wer übernimmt? Welcher externe
  Dienstleister kann auf Zuruf einsteigen?

Was dafür spricht

• 0 EUR upfront für Migration.
• Anwendung läuft weiter wie bisher. Kein Produktiv-Risiko.
• Du kaufst Zeit. In 2 Jahren könnte die Technik-Landschaft
  klarer sein, das Budget besser passen, ein bestimmtes Modul ohnehin
  abgekündigt werden.

Was dagegen spricht

• Technische Schulden steigen. Pro Jahr, das du wartest, wird die
  spätere Migration aufwändiger — neue Anforderungen kommen, das
  Datenmodell wächst, mehr Spezialfälle.
• Risiko-Übersicht muss aktiv gepflegt werden. Wer das vergisst,
  wacht eines Tages auf und der Telerik-Lizenz-Server ist abgeschaltet,
  oder ein Sicherheitslücke in einer alten DLL kann nicht mehr gepatcht
  werden.
• Anschluss verloren. Neue Anforderungen ("können wir nicht eine
  Mobile-App dazu bauen?", "können wir ein KI-Chat einbauen?")
  beantworten sich mit "theoretisch ja, aber dafür müssten wir erstmal
  modernisieren".

Wann sinnvoll

• Anwendung läuft stabil, ist niedrig-priorisiert
• Klares Auslaufdatum in 3–5 Jahren ohnehin geplant (z. B. weil ein
  übergeordnetes ERP-Projekt das System ersetzt)
• Budget aktuell nicht verfügbar
• Geschäftsführung will keinen Veränderungs-Stress vor anstehendem
  Generationswechsel

Größenordnung

• 1–3 Beratertage pro Jahr für Health-Check: 1.500–6.000 EUR p.a.
• Sicherheits-Patches + Windows-Lizenz: läuft sowieso
• Eventuell 1–2 Tage Risiko-Review-Update mit der Geschäftsführung

Insgesamt: 5–10k EUR pro Jahr, um die Position auf dem Schirm zu
halten. Verglichen mit 200k+ Migration für Strangler/Neubau eine
strategische Option, die zu früh ausgeschlossen wird.

Decision Matrix — welcher Weg ist deiner?

Eine grobe Orientierung. Tipp pro Reihe geht in einer Richtung, wenn
mehrere Indikatoren in eine andere zeigen, kontert die Gesamt-
Empfehlung entsprechend.

Drei Fallstricke, die ich bei Mandanten gesehen habe

Big Bang ohne Feature-Audit. Drei Monate vor dem Go-Live merkt man,
dass irgendwer die Excel-Export-Funktion aus Modul 17 jeden Donnerstag
für die Vertriebsmeldungen nutzt. Drei Tage Notfall-Entwicklung, knapp
am Eskalations-Skandal vorbei. Fix: vor Projektstart 2–4 Wochen
Anwender-Beobachtung in den Alltag, nicht im Workshop-Raum.

Strangler ohne Endpunkt. Anti-Pattern: 5 Jahre Parallelbetrieb,
weil "wir migrieren die einfachen Module zuerst und an die schwierigen
geht keiner ran". Fix: Ablaufdatum für die WebForms-Komponente
vertraglich fixieren, vorzugsweise direkt im Projekt-Charter.
Letzte 20% sind die teuersten 60% — das ist OK, dafür muss man planen.

Weiterbetrieb ohne Health-Check. "Wir haben die Anwendung seit 5
Jahren nicht angefasst, sie läuft." Bedeutet meist: niemand weiß ob die
Backups noch funktionieren, niemand weiß welche Patches drauf sind,
niemand weiß ob die DSGVO-Anforderungen noch erfüllt sind. Fix:
einmal jährlich ein bezahlter Health-Check mit Bericht und Ampel-
Bewertung.

Was ich konkret tue, wenn jemand mich darauf anspricht

30 Minuten reichen für eine erste ehrliche Einschätzung — anhand dieser
Fragen:

1. Wie viele Forms / Hauptfunktionen hat die Anwendung etwa?
2. Wie viele Anwender, wie kritisch für den Tagesbetrieb?
3. Gibt es Schnittstellen — DATEV, ERP, CRM, Banking?
4. Wer entwickelt das aktuell (intern, extern, gar nicht)?
5. Welchen Zeit-Horizont hat die Anwendung — 3, 10, 20 Jahre?

Aus den Antworten kommt eine erste Wahrscheinlichkeits-Verteilung
zwischen A / B / C, plus die Frage welches Budget realistisch ist.

→ 30 Min Klartext-Sparring

— Bernhard