Modernisieren oder neu entwickeln? Wie ich bestehende Anwendungen beurteile

Eine Anwendung wird langsamer weiterentwickelt, Änderungen verursachen unerwartete Fehler und niemand möchte den nächsten größeren Eingriff verantworten. Irgendwann fällt der Satz: „Wir sollten das neu bauen.“ Das kann richtig sein. Es kann aber auch ein teurer Umweg werden, wenn die tatsächlichen Schwierigkeiten noch nicht verstanden sind.

Bei der Beurteilung einer bestehenden Anwendung trenne ich drei Fragen: Passt sie fachlich noch zum Unternehmen? Lässt sie sich technisch sicher weiterentwickeln? Und kann eine Veränderung im laufenden Betrieb sinnvoll eingeführt werden? Erst zusammen ergeben die Antworten eine belastbare Richtung.

Das Ziel muss unabhängig von der Technologie verständlich sein

„Wir möchten einen modernen Stack“ beschreibt eine technische Präferenz. Für eine Entscheidung braucht es eine konkrete Verbesserung: Ein neuer Standort soll angebunden werden. Änderungen an einer Preisregel dürfen nicht mehrere Wochen Abstimmung auslösen. Eine notwendige Sicherheitsaktualisierung soll wieder möglich sein. Oder ein bestimmter Prozess verursacht regelmäßig Nacharbeit.

Diese Ziele helfen später bei der Abnahme. Wenn ein Neubau dieselben fachlichen Unklarheiten und dieselben umständlichen Übergaben übernimmt, kann er trotz neuer Technik wenig verbessern.

Ich beginne daher mit den Aufgaben, die die Anwendung heute erfüllt, und den Veränderungen, die tatsächlich benötigt werden. Dazu gehören ausdrücklich die Teile, die gut funktionieren. Bewährte Abläufe sind ein Wert, auch wenn ihre technische Umsetzung nicht mehr elegant wirkt.

Fachliche Eignung und technische Qualität getrennt ansehen

Eine fachlich passende Anwendung kann technisch veraltet sein. Umgekehrt kann eine sauber entwickelte Anwendung am heutigen Bedarf vorbeigehen. Diese Unterscheidung verhindert, dass ein Problem mit dem falschen Werkzeug bearbeitet wird.

Keine dieser Zeilen ist allein eine Entscheidung. Entscheidend sind Umfang, Abhängigkeiten und die Folgen eines Eingriffs. Auch ein altes Framework beweist nicht automatisch, dass die gesamte Anwendung neu entwickelt werden muss.

Den Änderungsaufwand an einem konkreten Fall prüfen

Abstrakte Aussagen wie „Der Code ist schlecht“ helfen der Geschäftsführung wenig. Ich möchte nachvollziehen können, welche Änderung schwierig ist und warum. Muss für eine neue Freigabestufe dieselbe Regel an mehreren Stellen geändert werden? Lässt sich eine Berechtigung isoliert testen? Sind fachliche Logik und Darstellung so verbunden, dass jeder Eingriff mehrere Abläufe berührt?

Ein begrenzter Untersuchungsauftrag kann hier sinnvoll sein. Dabei wird eine repräsentative Änderung durchdacht oder in einer sicheren Umgebung umgesetzt. Das liefert Hinweise auf Abhängigkeiten, Prüfaufwand und unbekannte Regeln. Es ist kein Versprechen, dass jede spätere Änderung gleich aufwendig sein wird.

Für Vue- und Nuxt-Anwendungen beschreibe ich die erste technische Bestandsaufnahme genauer im Artikel Ein bestehendes Projekt übernehmen.

Was für eine schrittweise Modernisierung spricht

Eine schrittweise Vorgehensweise ist attraktiv, wenn wichtige Funktionen weiterhin gebraucht werden und sich Bereiche sinnvoll voneinander trennen lassen. Dann kann beispielsweise zuerst eine problematische Erfassung ersetzt werden, während andere Abläufe weiter im Bestand laufen.

Das sogenannte Strangler-Fig-Muster beschreibt eine solche allmähliche Ablösung: Neue Teile übernehmen nach und nach Aufgaben des bestehenden Systems. Martin Fowler betont dabei auch die notwendige Übergangsarchitektur. Alt und Neu müssen während der Migration zusammenarbeiten können. Martin Fowler: Strangler Fig.

Für die Entscheidung bedeutet das: Kleine Schritte sind nicht kostenlos. Temporäre Schnittstellen, zusätzliche Prüfungen und zeitweiser Parallelbetrieb verursachen Aufwand. Sie können trotzdem sinnvoll sein, wenn einzelne Verbesserungen früher nutzbar werden und sich der Wechsel kontrollierter durchführen lässt.

Ein geeigneter erster Bereich hat einen klaren fachlichen Zweck, überschaubare Abhängigkeiten und eine überprüfbare Grenze. Eine bloße Aufteilung nach Bildschirmseiten ist dafür nicht immer ausreichend; mehrere Seiten können dieselben Regeln und Daten verändern.

Wann ein Neubau ernsthaft geprüft werden sollte

Ein Neubau wird eher plausibel, wenn sich die benötigten Abläufe grundlegend verändert haben, die bisherige Architektur diese Aufgaben kaum tragen kann oder eine zentrale technische Grundlage nicht sinnvoll weitergeführt werden kann. Auch ein kleiner, gut verstandener Funktionsumfang kann einen vollständigen Ersatz überschaubar machen.

Dazu muss aber geklärt werden, was „vollständig“ bedeutet. Häufig gehören unscheinbare Exporte, Sonderfälle und manuelle Korrekturwege zum Betrieb. Wenn diese erst kurz vor der Umstellung entdeckt werden, verliert eine scheinbar klare Neuentwicklung ihre Planbarkeit.

Ein Neubau braucht daher mehr als eine Liste sichtbarer Masken. Er benötigt fachliche Regeln, Integrationen, Datenübernahme, Rollen, Betriebsanforderungen und eine Entscheidung darüber, welche alten Funktionen bewusst entfallen dürfen. Weniger Funktionsumfang kann richtig sein, muss aber ausdrücklich vereinbart werden.

Die Datenmigration ist ein eigenes Arbeitspaket

Daten lassen sich nicht zuverlässig migrieren, indem lediglich Tabellen kopiert werden. Kennungen, Beziehungen, historische Zustände und die Bedeutung einzelner Felder müssen zum neuen Modell passen. Manche alten Werte sind unvollständig oder widersprüchlich. Dann braucht es eine fachliche Entscheidung, keine stillschweigende technische Schätzung.

Für einen Migrationsplan kläre ich insbesondere:

• Welche Daten müssen weiterhin bearbeitbar sein, welche nur noch lesbar?
• Wie werden alte und neue Kennungen zugeordnet?
• Welche Kontrollen erkennen fehlende oder falsch zugeordnete Datensätze?
• Was passiert mit Änderungen zwischen einem Probelauf und der eigentlichen Umstellung?
• Wer bestätigt, dass die fachlich wichtigen Informationen vollständig angekommen sind?

Planen Sie mindestens einen Probelauf mit geeigneten, sicher behandelten Daten und dokumentierten Kontrollen. Eine passende Sicherung ist notwendig, ersetzt aber nicht den Nachweis, dass die neue Anwendung die übernommenen Daten richtig interpretiert.

Parallelbetrieb und Rückweg bewusst gestalten

Wenn Alt und Neu zeitweise nebeneinander laufen, muss für jede Information feststehen, welches System führend ist. Sonst entsteht ein zweiter Bestand, der immer aufwendiger abgeglichen werden muss. Die Regeln dazu ähneln denen einer Schnittstellenplanung.

Ein Rückweg braucht ebenfalls konkrete Grenzen. Nach einer reinen UI-Änderung kann ein vorheriger Build ausreichen. Nach einer Datenmigration oder neuen Schreibvorgängen ist die Rückkehr meist anspruchsvoller: Die inzwischen entstandenen Daten dürfen nicht einfach verschwinden.

Legen Sie deshalb fest, wann ein Wechsel gestoppt wird, wer darüber entscheidet und wie der Betrieb dann weitergeht. Für manche Änderungen ist eine vorwärtsgerichtete Korrektur sinnvoller als ein vollständiges Zurückrollen. Das sollte vor dem Eingriff besprochen werden, nicht erst während eines Ausfalls.

Eine Entscheidung mit Bedingungen treffen

Ich würde eine Empfehlung nicht allein als „modernisieren“ oder „neu bauen“ formulieren. Nützlicher ist eine begründete Richtung mit Voraussetzungen: Welches Ziel wird erreicht, welche Risiken bleiben und welche unbekannten Punkte müssen zuerst untersucht werden?

Vergleichen Sie dafür mehrere realistische Optionen auf derselben Grundlage. Neben Aufwand und laufenden Kosten zählen die Zeit bis zur ersten nutzbaren Verbesserung, die Belastung des Teams, die Umstellungsrisiken und die spätere Wartbarkeit. Prüfen Sie auch, ob Standardsoftware oder eine begrenzte Erweiterung die Aufgabe inzwischen besser lösen kann.

Ein sinnvoller nächster Schritt kann ein klar abgegrenztes Arbeitspaket sein: einen kritischen Ablauf absichern, eine technische Abhängigkeit untersuchen oder einen Migrationsdurchstich erproben. Sein Ergebnis soll eine Entscheidung ermöglichen, nicht bloß zusätzliche Dokumentation erzeugen.

Sie müssen sich vor einem Gespräch noch nicht auf Modernisierung oder Neubau festlegen. Beschreiben Sie, was heute funktioniert, was sich ändern soll und wo die Anwendung Sie daran hindert. Daraus lässt sich die Weiterentwicklung Ihrer bestehenden Anwendung konkret eingrenzen. Bestand und nächste Schritte besprechen.