.NET Framework weiterbetreiben oder migrieren? Eine Entscheidungshilfe
Wann sich der Weiterbetrieb von .NET Framework lohnt und wann eine Migration sinnvoll wird. Support, Abhängigkeiten, Business Case und Pilot für CTOs und IT-Leitung.
Die Geschäftsführung möchte wissen, warum Geld in ein System fließen soll, das heute funktioniert. Der CTO sieht wachsende Abhängigkeiten und schwieriger werdende Änderungen. Beide Perspektiven gehören in dieselbe Entscheidung: Welcher Weg erfüllt die Geschäftsanforderungen über den gewählten Zeitraum zu vertretbaren Kosten und Risiken?
Den Support der konkreten Plattform prüfen
.NET Framework 4.8.1 folgt als Windows-Komponente dem Lebenszyklus des zugrunde liegenden Betriebssystems. Ein pauschales Supportende für alle Installationen lässt sich daraus nicht ableiten. Prüfen Sie die eingesetzte Windows- beziehungsweise Windows-Server-Version und deren Supportbedingungen. Microsoft dokumentiert dies in der Lifecycle-FAQ zu .NET Framework.
Der unterstützte Framework-Kern ist nur ein Teil der Bestandsaufnahme. Bibliotheken, UI-Komponenten, Datenbanktreiber und externe Dienste haben eigene Abhängigkeiten. Halten Sie Version, Quelle der Supportinformation, benötigte Maßnahmen und Verantwortlichen fest. Für modernes .NET gelten wiederum die jeweiligen Versions- und Supportzeiträume.
Wann ein abgesicherter Weiterbetrieb sinnvoll sein kann
Ein stabiler Betrieb mit geringem Änderungsbedarf kann für eine begrenzte Weiterbetriebsphase sprechen. Voraussetzungen sind unter anderem eine unterstützte Plattform, verfügbare Wartungskompetenz und eine erprobte Wiederherstellung.
Die Entscheidung sollte einen nächsten Prüfzeitpunkt und konkrete Auslöser für eine Neubewertung enthalten: etwa eine auslaufende Bibliothek, neue fachliche Anforderungen oder steigende Änderungszeiten. Weiterbetrieb benötigt somit ebenfalls ein Budget für Updates, Tests, Dokumentation und den Abbau kritischer Wissensabhängigkeiten.
Wann eine Migration an Gewicht gewinnt
Eine Migration wird interessanter, wenn benötigte Funktionen zunehmend an technischen Grenzen scheitern, wichtige Abhängigkeiten auslaufen oder Aufwand und Risiko jeder Änderung steigen. Auch veränderte Betriebsanforderungen können ein Grund sein.
Dabei ist zwischen dem Wechsel einer Laufzeit und einer fachlichen Neuentwicklung zu unterscheiden. Eine Migration nach modernem .NET löst nicht automatisch unklare Modulgrenzen, fehlende Tests oder Engpässe bei Freigaben. Diese Punkte müssen im Plan ausdrücklich berücksichtigt werden.
Eine pauschale Einsparung durch Linux, Container oder Cloud ist ebenfalls keine ausreichende Begründung. Stellen Sie Ihren heutigen Betriebskosten die Kosten der Zielplattform einschließlich Monitoring, Bereitschaft, Plattformkompetenz und Übergangsphase gegenüber.
Drei Optionen gemeinsam vergleichen
| Option | Typischer Anlass | Zentrale offene Frage |
|---|---|---|
| Weiterbetreiben und absichern | Begrenzter Änderungsbedarf, stabile und unterstützte Umgebung | Können Betrieb und Wartung über den gewählten Zeitraum verlässlich sichergestellt werden? |
| Schrittweise modernisieren | Wertvolle Fachlogik, neue Anforderungen, entkoppelbare Bereiche | Wie werden Daten, Tests und Übergänge zwischen alt und neu beherrscht? |
| Ersetzen | Standardsoftware deckt den Bedarf oder die bestehende Lösung passt fachlich nicht mehr | Welche Anpassung, Migration und organisatorische Umstellung benötigt der Ersatz? |
Der Modernisierungsleitfaden beschreibt die Gesamtstrategie. Der Artikel zum Strangler-Fig-Pattern vertieft die schrittweise Ablösung.
Den Business Case überprüfbar machen
Vereinbaren Sie mit Geschäftsführung und Finance einen gemeinsamen Betrachtungszeitraum. Erfassen Sie laufende Ausgaben, intern gebundene Kapazität, Einmalaufwand, Parallelbetrieb und eine Reserve für offene Abhängigkeiten.
Kürzere Entwicklungszeiten sind wertvoll, aber nicht automatisch eingesparte Auszahlungen. Stellen Sie frei werdende Kapazität gesondert dar. Zusätzliche Umsätze bleiben bis zur Realisierung ein Szenario. So kann die Geschäftsführung nachvollziehen, welche Annahme eine Investition trägt und wo die Entscheidung empfindlich ist.
Die Business-Case-Tabelle und Budgetvorlage helfen bei dieser Abstimmung.
Ein Pilot beantwortet eine konkrete Unsicherheit
Wählen Sie einen begrenzten Bereich, der eine relevante technische oder wirtschaftliche Annahme prüft. Vereinbaren Sie vor dem Start Ausgangswerte, Abnahmekriterien, einen Zeitraum und einen Rückfallplan. Ein geeigneter Pilot zeigt beispielsweise, ob eine Schnittstelle unabhängig deployt werden kann oder ob die neue Plattform unter realistischen Lasten tragfähig ist.
Ein erfolgreicher Pilot rechtfertigt den nächsten Schritt. Er belegt nicht automatisch, dass jede weitere Komponente denselben Aufwand oder Nutzen haben wird. Überarbeiten Sie den Plan anhand der gewonnenen Erkenntnisse.
Nächster Schritt
Wenn die Ausgangslage noch unklar ist, schafft ein Architektur-Review eine unabhängige Grundlage. Steht der Wechsel bereits fest, können wir den .NET-Migrationspfad eingrenzen. Für die übergreifende Investitionsentscheidung finden Sie hier die Beratung zur Legacy-Modernisierung.