Software modernisieren oder neu entwickeln? Ein Entscheidungsguide
Modernisieren oder neu entwickeln? Das ist die teuerste Frage in der Software-Welt. Falsch entschieden kostet sie hunderttausende Euro und Jahre Ihrer Zeit. Die Wahrheit: In vier von fünf Fällen ist Modernisierung die bessere Wahl. Neuentwicklungen scheitern häufig oder werden teurer als versprochen. Dieser Guide zeigt, wie Sie die Entscheidung sauber treffen – mit klaren Kriterien, nicht aus dem Bauch heraus.
Die zwei Lager
In jedem Software-Projekt gibt es zwei Stimmen.
Lager A: "Lass uns das endlich neu machen." Klingt verlockend. Frische Technologien. Saubere Architektur. Keine Altlasten. Das Team motiviert.
Lager B: "Das funktioniert doch." Klingt vernünftig. Das System läuft. Es verdient Geld. Warum etwas riskieren?
Beide Stimmen haben recht – manchmal. Die Kunst ist, im konkreten Fall die richtige zu hören.
Was die Daten sagen
Studien zur Erfolgsquote von Software-Projekten sind ernüchternd. Standish-Chaos-Reports und ähnliche Untersuchungen zeigen über Jahre konstant: Etwa 30–40 Prozent der Großprojekte scheitern komplett. Weitere 40–50 Prozent sind erfolgreich nur unter starker Kompromittierung von Zeit, Budget oder Features.
Bei Neuentwicklungen zur Ablösung bestehender Systeme ist die Quote noch schlechter. Warum? Weil das Wissen im Alt-System mehr ist, als alle denken. Sonderfälle, die seit Jahren funktionieren. Geschäftsregeln, die niemand mehr im Kopf hat, aber im Code stehen.
Die Lektion: Neuentwicklung ist nicht das sichere Bett. Im Gegenteil.
Die acht Kriterien
Wann lohnt sich was? Hier die acht wichtigsten Kriterien aus der Praxis.
1. Codegröße
Klein (bis 20.000 Zeilen): Beide Wege machbar. Neubau dauert oft nur Wochen länger als gründliche Modernisierung.
Mittel (20.000 bis 100.000 Zeilen): Modernisierung meist klar im Vorteil. Neubau wird teuer und riskant.
Groß (über 100.000 Zeilen): Modernisierung fast immer die einzig vernünftige Option. Neubau ist Megaprojekt mit hohem Scheiterrisiko.
2. Domänenwissen im Code
Wie viel Geschäftslogik steckt im System? Sonderfälle, Regelausnahmen, Branchenwissen?
Wenig: CRUD-Anwendung mit Standardfunktionen. Neubau eher möglich.
Mittel: Spezifische Workflows, einige Sonderfälle. Modernisierung sicherer.
Viel: Hochspezialisierte Anwendung mit jahrelang gewachsenen Regeln. Modernisierung dringend empfohlen. Neubau verliert das Wissen.
3. Geschäftswert
Marginal: Anwendung wird kaum noch genutzt? Vielleicht abschalten statt erneuern.
Wichtig: Wichtige Anwendung, aber nicht zentral. Beide Wege denkbar.
Geschäftskritisch: Ohne diese Software steht das Unternehmen still. Modernisierung. Niemals Big-Bang-Neubau.
4. Zustand des Codes
Gut: Klare Struktur, dokumentiert, getestet. Modernisierung einfach. Neubau unnötig.
Mittel: Gewachsen, teils chaotisch, ohne Tests. Modernisierung mit Refactoring sinnvoll.
Schlecht: Niemand versteht den Code mehr. Hier wird die Entscheidung wirklich schwer. Reverse Engineering ist nötig – ob zur Modernisierung oder zur Spec für den Neubau.
5. Technologie-Stack
Modern oder erweiterbar: PHP 7.4, Java 11, Python 3.8. Klar modernisieren.
Veraltet, aber lebendig: PHP 5.6, Java 8. Modernisieren mit Versions-Upgrade.
Tot: ColdFusion, klassisches ASP, Delphi 7. Hier kann Neubau oder Migration auf moderne Plattform die einzige Option sein.
6. Team-Situation
Wer pflegt das System? Wenn niemand mehr da ist, ist Modernisierung mit externem Partner oft schneller als Neubau ohne Wissen.
Wer baut das neue System? Eigene Mannschaft? Externe Agentur? Beides geht – mit unterschiedlichen Risiken.
7. Zeitdruck
Akut: Sicherheitslücke, Hoster-Abschaltung, Compliance. Modernisierung deutlich schneller.
Geplant: Sechs Monate bis ein Jahr Vorlauf. Beide Wege möglich.
Strategisch: Mehrjährige Planung. Auch Neubau machbar, weil parallel gefahren werden kann.
8. Budget
Knapp: Modernisierung. Neubauten sprengen kleine Budgets fast immer.
Mittel: Modernisierung sicherer. Neubau möglich, aber riskant.
Groß: Beide Wege im Rahmen. Trotzdem: Neubau scheitert auch mit großem Budget oft.
Die Drittweg-Lösung: Strangler Fig
Es gibt einen dritten Weg, der die Vorteile beider verbindet: das Strangler-Fig-Pattern.
Die Idee: Sie reißen nichts ab. Sie bauen neue Funktionen um das alte System herum. Schritt für Schritt verlagern Sie Funktionalität ins neue System. Irgendwann ist das alte System leer und kann abgeschaltet werden.
Der Name kommt von den Würgefeigen im Regenwald: Sie wachsen um einen Baum herum und ersetzen ihn nach und nach.
Wie es konkret funktioniert
Phase 1: Eine Schnittstelle vor dem alten System. Eine Art Verteiler.
Phase 2: Neue Funktionen werden im neuen System gebaut. Der Verteiler leitet Anfragen entsprechend weiter.
Phase 3: Bestehende Funktionen werden Stück für Stück migriert. Immer eine zur Zeit. Immer mit Tests.
Phase 4: Wenn das alte System leer ist, wird es abgeschaltet.
Vorteile
- Kein Big-Bang-Risiko. Das alte System läuft während des gesamten Prozesses weiter.
- Schrittweise Wertschöpfung. Neue Funktionen sind schnell verfügbar.
- Lernprozess. Das Team versteht das Geschäft mit jedem migrierten Modul besser.
- Reversibel. Wenn ein Schritt nicht funktioniert, geht es zurück.
Nachteile
- Dauert oft länger als reine Modernisierung
- Erfordert disziplinierte Architektur
- Mehr Komplexität im Übergang
- Erfordert klare Prioritäten
Strangler Fig ist nicht für jede Situation richtig. Aber bei großen, geschäftskritischen Systemen oft der pragmatischste Weg. Mehr zur strukturierten Migration im Glossar.
Die typischen Fallen
Falle 1: "Wir bauen schnell neu"
Klassische Selbsttäuschung. Schätzungen für Neubauten sind notorisch falsch. Faktor 2 bis 3 ist normal. Bei großen Projekten Faktor 5.
Wer sagt "in einem Jahr fertig", liefert in drei. Mit deutlich weniger Features.
Falle 2: "Wir machen es richtig"
Bei Neubauten kommt oft der Wunsch, "alles richtig" zu machen. Microservices, Kubernetes, Event-Sourcing, GraphQL, alles. Ergebnis: Über-engineerte Lösung, die nie fertig wird.
Modernisierung ist meistens die ehrlichere Option. Sie zwingt zu Pragmatismus.
Falle 3: "Die Anforderungen kennen wir schon"
Die Anforderungen kennen Sie nicht. Sie sind im alten Code versteckt, in den Köpfen von Power-Usern und in jahrelang gewachsenen Sonderfällen.
Wer ohne ausführliche Bestandsaufnahme neu baut, baut ein anderes System als das, was die Nutzer brauchen.
Falle 4: "Wir laufen parallel weiter"
Klingt sicher: Altes System läuft, neues wird gebaut, dann Umschalten. Praxis: Doppelte Wartung, doppelte Kosten, doppelter Stress. Mitarbeiter sind ausgelastet.
Strangler Fig löst das partiell. Reiner Parallel-Betrieb ist meistens eine Falle.
Eine Entscheidungshilfe
Hier eine vereinfachte Faustregel:
Modernisieren, wenn:
- Codebasis über 50.000 Zeilen
- Viel Domänenwissen im Code
- Geschäftskritisch
- Niemand kann eine vollständige Spec liefern
- Budget unter 200.000 Euro
Neu entwickeln, wenn:
- Codebasis unter 20.000 Zeilen
- Wenig spezifische Logik (Standardfälle)
- Anforderungen klar dokumentiert
- Komplette Technologie-Plattform tot
- Funktionen sollen sich grundlegend ändern
Strangler Fig, wenn:
- Codebasis über 100.000 Zeilen
- Geschäftskritisch
- Mehrjähriges Modernisierungsbudget vorhanden
- Disziplinierte Architektur möglich
In den meisten realen Fällen ist Modernisierung der richtige Weg. Wenn doch Neubau, dann mit den Methoden des Strangler Fig.
Eine ehrliche Empfehlung
Wir lehnen Neuentwicklungs-Aufträge nicht ab. Aber wir prüfen genau, ob sie wirklich nötig sind. In über der Hälfte aller Fälle, in denen Kunden mit "wir wollen neu bauen" zu uns kommen, ist Modernisierung sinnvoller.
Das ist keine Verkaufsmasche – im Gegenteil. Modernisierung ist für uns oft das kleinere Geschäft als Neubau. Aber für den Kunden meist die bessere Lösung.
Wenn Sie wirklich neu entwickeln wollen oder müssen, prüfen wir das ehrlich. Wenn Modernisierung sinnvoller ist, sagen wir das.
Fazit
Die Entscheidung zwischen Modernisierung und Neuentwicklung ist keine Technikfrage. Sie ist eine Strategie- und Risikofrage. Wer sie ohne sorgfältige Bestandsaufnahme trifft, riskiert hunderttausende Euro. Wer die Kriterien systematisch durchgeht, trifft die richtige Entscheidung. Meistens heißt sie: modernisieren. Manchmal: Strangler Fig. Selten: kompletter Neubau.
FAQ
Wie lange dauert eine Modernisierung im Vergleich zum Neubau?
Modernisierung ist meistens 30–50 Prozent schneller. Sie können bestehende Strukturen nutzen, statt alles neu zu entwerfen. Außerdem läuft die Anwendung weiter, während Sie arbeiten.
Was kostet ein Neubau im Vergleich zur Modernisierung?
Neubauten kosten typischerweise das Zwei- bis Vierfache einer Modernisierung. Sie zahlen für Anforderungsanalyse, Architektur, neue Infrastruktur, doppelte Wartung in der Übergangsphase und höhere Risikoaufschläge.
Wie merke ich, dass ein Neubau unvermeidlich ist?
Klare Zeichen: Die Plattform ist tot (Sprache, Framework werden nicht mehr unterstützt). Der Code ist so chaotisch, dass jede Änderung neue Fehler erzeugt. Die Geschäftsanforderungen haben sich grundlegend geändert, sodass die Architektur nicht mehr passt.
Was ist mit hybriden Lösungen?
Hybrid heißt meist Strangler Fig. Sie modernisieren in Schritten und ersetzen Stück für Stück. Das ist oft die pragmatischste Lösung für mittlere und große Systeme.
Kann ich Modernisierung selber stemmen?
Wenn Sie ein erfahrenes internes Team mit Kapazität haben: ja. Wenn das Team mit Tagesgeschäft ausgelastet ist oder das Spezialwissen fehlt: besser externe Hilfe. Modernisierung neben dem Alltagsbetrieb scheitert oft.
Sie stehen vor der Entscheidung: modernisieren oder neu bauen? Wir hören uns Ihre Situation an und geben eine ehrliche Empfehlung. Auch wenn das gegen unsere Auftragslage spricht. Jetzt Kontakt aufnehmen.