andregoepel.dev
Gespräch anfragen
Alle Artikel
Softwaremodernisierung 5 Min. Lesezeit

Komplett neu bauen oder schrittweise modernisieren? So lässt sich die Entscheidung treffen

Eine neue Anwendung verspricht einen sauberen Anfang. Die schrittweise Modernisierung verspricht kleinere Eingriffe. Beide Ansätze müssen aber dieselbe Aufgabe lösen: vorhandene Geschäftsabläufe verlässlich weiterführen und eine konkrete Verbesserung liefern. Ich würde die Entscheidung deshalb am Nutzen und am Übergang ausrichten, nicht allein am Zustand des alten Codes.

.NETModernizationSoftware ArchitectureLegacy Systems

Den gewünschten Nutzen genauer beschreiben

„Das System ist alt“ kann vieles bedeuten: Die Runtime erhält bald keine Updates mehr. Eine Fachabteilung wartet zu lange auf Änderungen. Oder jede neue Funktion berührt so viele Stellen, dass das Team kaum noch verlässlich planen kann.

Diese Probleme verlangen unterschiedliche Antworten. Ein Versionswechsel kann ein Supportproblem lösen, ohne die Anwendung grundlegend umzubauen. Neue Modulgrenzen können die Weiterentwicklung erleichtern, ohne dass die Oberfläche neu geschrieben werden muss.

Ich würde deshalb vor jeder Entscheidung einen Satz vervollständigen: Nach der Modernisierung können wir etwas tun, das heute zu teuer, zu langsam oder zu unsicher ist. Je konkreter dieser Satz ausfällt, desto besser lassen sich die Optionen vergleichen.

Eine Supportfrist begrenzt den ersten Schritt

Für .NET 8 und .NET 9 endet der Support am 10. November 2026. Danach stellt Microsoft keine weiteren Sicherheitsupdates für diese Versionen bereit; als Migrationsziel empfiehlt Microsoft .NET 10. Das ist ein zeitgebundener Anlass, keine automatische Begründung für einen vollständigen Neubau. Microsofts Ankündigung

Wenn ein unterstützter Betrieb durch einen begrenzten Versionswechsel erreichbar ist, würde ich diesen Umfang separat planen. Ist dafür der Austausch einer zentralen Bibliothek nötig, gehört er dazu. Ein neues Frontend gehört nur dann hinein, wenn es für diesen Wechsel tatsächlich erforderlich ist.

Das Ziel ist ein belastbarer erster Schritt. Weitergehende Verbesserungen brauchen anschließend eigene Prioritäten und Mittel.

Wann ein Neubau eine ernsthafte Option ist

Ein Neubau kann sinnvoll sein, wenn die bisherige Anwendung eine klar abgegrenzte Aufgabe erfüllt und ihre heutigen Regeln ausreichend verstanden sind. Auch eine Plattform, für die wesentliche technische Grundlagen nicht mehr verfügbar sind, kann einen größeren Ersatz erforderlich machen.

Ich würde einen Neubau besonders dann genauer prüfen, wenn sich beantworten lässt:

  • Welche tatsächlich genutzten Funktionen muss der Ersatz übernehmen?
  • Welche Daten müssen in welcher Qualität übernommen werden?
  • Welche Verbraucher und Arbeitsabläufe hängen an der bisherigen Anwendung?
  • Wer betreut das Altsystem bis zur Abschaltung?
  • Woran erkennen wir, dass die Ablösung vollständig ist?

Ein kleines Werkzeug mit wenigen Nutzern und einem klaren Datenbestand ist ein anderer Fall als ein Portal, dessen Sonderfälle über Jahre in Code und Arbeitsanweisungen gewachsen sind.

Auch beim Neubau entsteht nicht automatisch eine saubere Ausgangslage. Unbekannte Regeln müssen gefunden werden. Eine neue Programmiersprache übernimmt diese Arbeit nicht.

Wann schrittweise Modernisierung besser planbar wird

Schrittweises Vorgehen ist interessant, wenn das bestehende System weiter Nutzen liefert und sich ein Bereich mit verständlicher Grenze herauslösen lässt. Der erste Schritt sollte eigenständig hilfreich sein, etwa eine lange Wartezeit verkürzen oder wiederkehrende Nacharbeit reduzieren.

Das Strangler-Fig-Muster beschreibt eine schrittweise Ablösung: Teile der Funktionalität wandern in eine neue Lösung, während der Rest zunächst weiterläuft. Das ist eine mögliche Struktur für den Übergang, keine Garantie für geringe Kosten.

Die schwierigere Frage lautet oft, wie lange zwei Wege gleichzeitig bestehen müssen. Während dieser Zeit sind Zugriffe, Daten und Fehlerfälle über beide Seiten hinweg zu verstehen. Wenn niemand die alte Variante abschaltet, wird aus dem Übergang eine dauerhafte zusätzliche Last.

Beispiel einer Dokumentenfunktion

Angenommen, ein Kundenportal funktioniert im Tagesgeschäft, aber die Dokumentensuche ist langsam und schwer zu erweitern. Dieses Beispiel ist hypothetisch.

Ein vollständiger Neubau würde neben der Suche auch Anmeldung, Berechtigungen, Auftragsbearbeitung und viele seltene Abläufe auf den Prüfstand stellen. Vielleicht ist das langfristig nötig. Für das aktuelle Suchproblem wäre es zunächst ein großer Umfang.

Als begrenzten Versuch würde ich einen neuen Suchweg für einen klar definierten Dokumentbereich prüfen. Dafür müssten Fragen wie diese beantwortet werden: Woher kommen die Daten? Wie aktuell muss der Suchbestand sein? Welche Berechtigungen müssen auch im neuen Weg gelten? Wie messen wir, ob Nutzer ihre Dokumente besser finden?

Eine neue Suchoberfläche allein wäre zu wenig. Der Versuch muss den tatsächlichen Ablauf abdecken und unter realistischen Bedingungen zeigen, ob die gewählte Grenze funktioniert.

Die Übergangsphase gehört ins Budget

Beim Vergleich der Optionen würde ich die neue Implementierung und den Übergang getrennt schätzen. Zum Übergang gehören unter anderem Datenübernahme, Testfälle, Anpassungen der Verbraucher und das Entfernen alter Wege.

Besonders wichtig ist die Schreibverantwortung. Wenn zwei Anwendungen dieselben fachlichen Daten verändern können, braucht es eine klare Regel dafür, welcher Stand gilt und wie Konflikte behandelt werden. Ungeplante doppelte Pflege wäre für mich ein Grund, den Zuschnitt noch einmal zu prüfen.

Dasselbe gilt für den Rückweg. Nach einer Datenänderung kann es zu wenig sein, nur eine alte Anwendungsversion zu starten. Vor der Umstellung sollte feststehen, welche Zustände kompatibel bleiben müssen und wie fehlerhafte Änderungen korrigiert werden können.

Ein kurzer Entscheidungsvermerk reicht für den Anfang

Ich würde beide Optionen auf derselben Grundlage beschreiben: erwarteter Nutzen, erster produktiver Schritt, notwendige Übergangsarbeit und Bedingungen für die Abschaltung des alten Wegs.

Dazu gehört eine bewusst unbequeme Frage: Wenn das Vorhaben nach dem ersten Schritt endet, haben wir dann eine Verbesserung oder lediglich eine weitere halbfertige Lösung?

Ein begrenzter Neubau kann diese Frage gut beantworten. Eine schrittweise Migration kann daran scheitern. Die Bezeichnung der Methode entscheidet nicht über den Erfolg; entscheidend ist, ob der Umfang zu den vorhandenen Kenntnissen und Kapazitäten passt.

Unterstützung bei der Entscheidung

Ich helfe Unternehmen, Modernisierung in ihrer .NET-Landschaft anhand konkreter Probleme zu planen. Wenn ihr zwischen Versionswechsel, schrittweiser Ablösung und Neubau abwägt, können wir im kostenlosen Erstgespräch euren ersten sinnvollen Schritt eingrenzen.

Neue Artikel per E-Mail

Eine Mail pro Artikel. Kein Newsletter-Theater, keine Tracking-Pixel.

Abmeldung mit einem Klick. Keine Weitergabe.