Software modernisieren oder neu entwickeln? Eine ehrliche Entscheidungshilfe
Software modernisieren oder neu entwickeln: Vor dieser Frage stehen viele Unternehmen irgendwann. Die Anwendung läuft, aber sie ist langsam, schwer zu warten, und niemand will mehr daran arbeiten. Irgendwann kommt der Punkt, an dem etwas geschehen muss.
Die häufigste Reaktion: "Wir bauen das neu." Die zweithäufigste: "Wir modernisieren es." Beide Antworten können richtig sein. Und beide können falsch sein. Es kommt darauf an, womit Sie es wirklich zu tun haben.
Dieser Artikel gibt Ihnen einen strukturierten Rahmen für diese Entscheidung. Kein Verkaufsgespräch. Keine Universalantwort. Nur eine ehrliche Analyse der Faktoren, die tatsächlich zählen.
Was bedeutet "modernisieren" genau?
Modernisierung heißt: Sie verbessern das bestehende System. Sie bauen es nicht von Grund auf neu. Technische Schulden werden abgebaut. Veraltete Komponenten werden ersetzt. Die Struktur wird verbessert, der Kern bleibt erhalten.
Das kann viele Formen annehmen. Ein PHP-Upgrade von Version 5 auf 8 ist eine Modernisierung. Die Einführung automatisierter Tests ist eine Modernisierung. Das Ersetzen einer unsicheren Authentifizierungslösung durch eine moderne Variante ist eine Modernisierung.
Der Vorteil: Das bewährte Wissen steckt im System. Die Geschäftslogik, die über Jahre gewachsen ist, bleibt erhalten. Kunden und Mitarbeiter kennen die Software. Dieses Wissen hat einen echten Wert, der beim Neubau verloren geht.
Was bedeutet "neu entwickeln" genau?
Ein Neubau (in der Entwicklerwelt oft "Rewrite" genannt) bedeutet: Sie starten von vorne. Neue Technologie, neue Architektur, neue Codebasis. Das Ziel ist oft, die Fehler der Vergangenheit nicht zu wiederholen.
Das klingt verlockend. In der Praxis ist es das riskanteste Szenario in der Softwareentwicklung. Bekannte Stimmen aus der Branche nennen den kompletten Rewrite seit Jahrzehnten den gefährlichsten strategischen Fehler, den Unternehmen machen können. Das gilt heute noch.
Das bedeutet nicht, dass Neubau immer falsch ist. Aber er sollte nie die erste Idee sein.
Wann ist Modernisierung die richtige Wahl?
Modernisierung ist die richtige Wahl, wenn das System grundsätzlich funktioniert. Die Geschäftslogik stimmt. Die Datenstrukturen sind sinnvoll. Nur die technische Umsetzung ist veraltet.
Konkrete Kriterien, die für Modernisierung sprechen:
Die Kernlogik ist komplex und bewährt. Wenn eine Anwendung über Jahre gewachsen ist, bildet sie oft tausende Sonderfälle ab. Dieses Wissen ist wertvoll. Ein Neubau muss es mühsam reproduzieren. Oder er übersieht es komplett.
Der Betrieb läuft stabil. Die Software läuft seit Jahren ohne große Abstürze. Die Probleme sind technischer Natur: veraltetes PHP, fehlende Sicherheits-Updates, langsame Performance. Diese Probleme lassen sich oft gezielt beheben.
Schrittweise Verbesserung ist möglich. Nicht alles muss auf einmal geändert werden. Wenn Teile des Systems unabhängig voneinander modernisiert werden können, ist das ein gutes Zeichen.
Das Budget ist begrenzt. Ein vollständiger Neubau kostet in der Regel das Zwei- bis Dreifache einer Modernisierung. Wenn das Budget knapp ist, ist Modernisierung oft der einzig realistische Weg.
Wer angesammelte technische Schulden systematisch abbaut, anstatt von vorne anzufangen, spart oft erheblich. Das Ergebnis ist häufig stabiler als erwartet.
Wann ist ein Neubau sinnvoll?
Es gibt Situationen, in denen ein Neubau tatsächlich die bessere Wahl ist. Diese Situationen sind seltener, als die meisten denken. Aber sie existieren.
Die Architektur ist grundlegend falsch. Wenn das System von Anfang an falsch konzipiert wurde, zieht sich das durch jeden Teil des Codes. Jede Modernisierung kämpft gegen die Grundstruktur. In solchen Fällen kann Neubau günstiger sein als jahrelange Reparatur.
Die Technologie hat keine Zukunft mehr. Nicht nur veraltetes PHP, sondern eine Plattform, für die es keine Entwickler, keine Bibliotheken und keinen Support mehr gibt. Das ist selten. Aber es kommt vor.
Die Anforderungen haben sich grundlegend geändert. Die ursprüngliche Software wurde für einen anderen Zweck gebaut. Was damals sinnvoll war, ist heute ein Hindernis. Neue Anforderungen lassen sich nicht sinnvoll in die alte Struktur integrieren.
Der Aufwand für Modernisierung übersteigt den Neubau nachweislich. Das sollte durch eine seriöse Analyse belegt sein, nicht durch eine Schätzung. Eine fundierte Prüfung des Systems kann diese Frage klären, bevor eine Entscheidung fällt.
Die gefährliche Mitte: Wenn beide Optionen attraktiv klingen
In der Praxis gibt es einen häufigen Fehler. Eine Agentur oder ein Entwickler schaut sich das System an und sagt: "Das ist zu alt. Wir müssen das neu bauen." Das klingt professionell. Oft ist es bequem.
Neu bauen macht mehr Spaß als alte Systeme zu verstehen. Das ist menschlich. Es führt aber nicht immer zum besten Ergebnis für den Kunden.
Umgekehrt gibt es den Fehler, ein System zu modernisieren, das wirklich zu kaputt ist. Man investiert Zeit und Geld. Am Ende hat man ein modernisiertes schlechtes System.
Woran erkennen Sie, welcher Fall vorliegt? Drei Fragen helfen dabei:
Können die Probleme des Systems auf konkrete technische Ursachen zurückgeführt werden? Oder ist die gesamte Grundstruktur das Problem?
Wie lange hat das System gut funktioniert, bevor es zum Problem wurde?
Wie viel Wissen steckt im System, das beim Neubau verloren gehen würde?
Ein ehrlicher Entscheidungsrahmen
Hier ist eine strukturierte Vorgehensweise, die wir in der Praxis empfehlen.
Schritt 1: Analyse vor Entscheidung. Bevor Sie sich entscheiden, brauchen Sie eine Bestandsaufnahme. Wie alt ist das System wirklich? Welche Teile funktionieren gut, welche schlecht? Gibt es Dokumentation? Wie hoch ist die technische Verschuldung?
Schritt 2: Kosten berechnen, nicht schätzen. Lassen Sie sich für beide Szenarien eine realistische Aufwandsschätzung erstellen. Inklusive der versteckten Kosten eines Neubaus: Datenmigration, Schulung der Nutzer, Parallelbetrieb während der Übergangszeit.
Schritt 3: Risiko abwägen. Ein Neubau dauert länger und birgt mehr unbekannte Risiken. Eine Modernisierung ist planbarer. Welches Risiko können Sie als Unternehmen tragen?
Schritt 4: Schrittweise denken. Die beste Antwort ist oft weder "komplett modernisieren" noch "komplett neu bauen". Es ist ein mittlerer Weg. Kritische Teile sanieren. Veraltete Komponenten ersetzen. Neuentwicklung nur dort, wo es wirklich nötig ist.
Diese Strategie nennt sich Strangler Fig Pattern (englisch für "Würgefeige"): Das alte System wird schrittweise von innen abgelöst, während es weiterläuft. Kein riskanter Gesamttausch. Kein Betriebsstillstand. Kontrollierter Fortschritt in überschaubaren Schritten.
Was kostet was?
Konkrete Zahlen ohne Analyse Ihres Systems sind nicht seriös nennbar. Aber Orientierungswerte helfen bei der Einordnung.
Für die Modernisierung typischer mittelständischer Anwendungen: mehrere Tausend bis mehrere Zehntausend Euro, je nach Umfang und Zustand.
Für einen vollständigen Neubau: oft das Zwei- bis Dreifache, mit höherem Risiko für Verzögerungen und Nachforderungen.
Hinzu kommt: Während eines Neubaus läuft das alte System weiter und muss weiter betreut werden. Das bedeutet Doppelkosten für eine Übergangszeit von oft sechs bis achtzehn Monaten. Diese Kosten werden in Angeboten für Neubauprojekte häufig nicht ausgewiesen.
Zwei häufige Denkfehler vermeiden
Denkfehler 1: "Alt ist gleich schlecht." Ein System, das seit zehn Jahren stabil läuft, hat bewiesen, dass es seinen Zweck erfüllt. Alte Software ist nicht per se schlechte Software. Sie hat angesammelte Schulden, aber auch angesammeltes Wissen.
Denkfehler 2: "Neu ist gleich besser." Neue Technologie löst keine organisatorischen Probleme. Wenn Anforderungen unklar sind, wenn Prozesse nicht definiert sind, wenn das Team fehlt: Ein Neubau verschiebt diese Probleme in eine neue Codebasis.
Das Ergebnis hängt von Ihrer Situation ab
Wann passt welcher Weg? Eine grobe Orientierung:
Wenn das System über viele Jahre stabil gelaufen ist und die Probleme klar benennbar sind, ist Modernisierung fast immer die bessere Wahl. Wenn die Grundstruktur grundlegend falsch ist und selbst erfahrene Entwickler keinen Einstieg mehr finden, ist ein Neubau zu prüfen.
Wenn das System geschäftskritisch ist und ein Ausfall nicht tolerierbar wäre, empfiehlt sich das schrittweise Vorgehen des Strangler Fig Pattern. Alles auf einmal ist hier zu riskant.
In den meisten Fällen, die wir sehen, ist Modernisierung der sicherere und günstigere Weg. Das sagen wir nicht, weil Modernisierung immer die kleinere Arbeit ist. Wir sagen es, weil wir die Ergebnisse beider Wege kennen.
Mehr dazu, wie wir konkret vorgehen, lesen Sie unter Software-Wartung und Modernisierung.
Fazit: Software modernisieren oder neu entwickeln?
Die Frage klingt nach einer Entweder-Oder-Entscheidung. In der Praxis ist sie das selten.
Die richtige Frage lautet: Welche Teile des Systems haben echten Wert, und welche sind ein Hindernis? Wo kann man mit Modernisierung schnell und günstig stabilisieren? Und wo lohnt sich Neubau, weil die Grundlage nicht mehr tragfähig ist?
Diese Fragen lassen sich nicht vom Schreibtisch aus beantworten. Sie brauchen jemanden, der sich das System wirklich anschaut und ehrlich sagt, was er findet.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen, wo Sie stehen.
