Wenn Sie ein Gründer, CTO oder Geschäftsleiter sind, der für ein Produkt verantwortlich ist, das auf veralteter Technologie basiert, haben Sie sich wahrscheinlich gefragt: Sollten wir das, was wir haben, weiter patchen — oder neu anfangen?
Vielleicht ist der Code brüchig. Vielleicht sind die ursprünglichen Architekten längst verschwunden. Vielleicht ist Ihr Team frustriert, Ihr Fahrplan blockiert und modernes Recruiting eine Herausforderung. Sie sind nicht allein — und es ist nicht falsch, diese Frage zu stellen.
Aber die Antwort ist nicht einfach. Ein Neuschreiben kann Chancen bringen — oder Risiken einführen, die sich in Ihrem Unternehmen ausbreiten. Was Sie brauchen, ist nicht nur eine Meinung — es ist ein Rahmen, um die richtige Entscheidung zu treffen.
Dieser Leitfaden ist für Sie. Egal, ob Sie zu einer großen technischen Überholung gedrängt werden oder einfach nur Ihre Optionen verstehen möchten, wir werden folgende Punkte durchgehen:
- Warum Teams sich gezwungen fühlen, neu zu schreiben
- Wann es sinnvoll ist (und wann nicht)
- Wie man veraltete Systeme sicher und strategisch modernisiert
Wir werden auch warnende Geschichten, praktische Taktiken und einen wichtigen Ratschlag teilen: Treffen Sie diese Entscheidung nicht im luftleeren Raum. Eine zweite Meinung — von jemandem außerhalb Ihres Tagesgeschäfts — kann Ihnen Monate an verschwendeter Mühe und Millionen an entgangenen Chancen ersparen. Dieser Leitfaden beleuchtet beide Seiten der Debatte, untersucht, warum Unternehmen Neuschreibungen in Betracht ziehen, skizziert die echten Risiken und stellt eine strategischere Alternative vor: inkrementelle Modernisierung. Am wichtigsten ist, dass es sich lohnt, vor der Verpflichtung zu größeren Änderungen eine zweite Meinung einzuholen — idealerweise von jemandem außerhalb des unmittelbaren Teams, wie einer digitalen Beratung, einem vertrauenswürdigen Berater oder einem anderen erfahrenen Blick. Manchmal kann eine kleine externe Perspektive einen großen Unterschied machen.
Warum Neuschreibungen so verlockend sind
Die Softwarelandschaft entwickelt sich schnell weiter. Neue Tools, Frameworks und architektonische Paradigmen versprechen bessere Leistung, ein reibungsloseres Entwicklererlebnis, schnellere Bereitstellung und niedrigere Wartungskosten.
Aus geschäftlicher Sicht:
- Wettbewerber, die moderne Stacks verwenden, scheinen schneller voranzukommen
- Entwickler für veraltete Technologien (wie Java 6, AngularJS oder PHP 5) zu einstellen, ist schwieriger
- Die Führungsebene hört „Legacy“ und geht von „Haftung“ aus
Aus der Perspektive eines Entwicklers:
- Die Wartung alter Codes fühlt sich demotivierend an
- Die Werkzeuge können umständlich sein, die Dokumentation veraltet und Tests nicht vorhanden
- Ingenieure möchten mit spannenden, marktgerechten Technologien arbeiten
Dies schafft eine Wahrnehmungsspaltung:
Legacy = schlecht | Refactor/Rewrite = gut
Aber das ist eine Vereinfachung. Legacy-Systeme steuern oft die kritischsten Teile eines Unternehmens — und Stabilität, nicht Glanz, sorgt für die Einnahmen.
Warum Unternehmen ihre Codebasen neu schreiben
Neuschreibungen erfolgen aus verschiedenen Gründen. Hier sind die häufigsten Treiber:
- Leistungs- & Skalierbarkeitsgrenzen: Ein System, das für 10.000 Benutzer ausgelegt ist, kann bei 1 Million zusammenbrechen. Manchmal ist das Neuschreiben mit einer anderen Architektur (z. B. der Wechsel von Monolith zu Microservices) der einzige Weg, um zu skalieren.
- Compliance & Sicherheit: Veraltete Technologie kann nicht patchbare Schwachstellen einführen oder es versäumen, aktualisierte Standards wie PCI DSS 4.0 oder OWASP zu erfüllen.
- Engpässe bei der Feature-Entwicklung: Altsysteme können so brüchig sein, dass das Hinzufügen von Funktionen riskant oder langsam wird.
- Talentbindung & Einstellung: Ingenieure verlassen oft Teams, die auf veralteten Stacks feststecken. Das Neuschreiben kann eine Talentstrategie sein, wenn auch eine riskante.
- M&A oder Geschäftstransformation: Fusionen, Übernahmen oder große Umstellungen erfordern oft Systeme, die flexibler oder besser integriert sind. Neuschreibungen können funktionieren – aber nur unter sehr spezifischen Bedingungen. Die meisten scheitern nicht aufgrund schlechter Absichten, sondern wegen unterschätzter Komplexität und überschätzter Kapazität.
Neuschreibungen können funktionieren – aber nur unter sehr spezifischen Bedingungen. Die meisten scheitern nicht aufgrund schlechter Absichten, sondern wegen unterschätzter Komplexität und überschätzter Kapazität.
Wann ein Rewrite notwendig erscheint (und was zuerst zu beachten ist)
Manchmal scheint ein Rewrite die einzige praktikable Option zu sein. Das System ist gefährlich veraltet. Die geschäftlichen Anforderungen haben sich geändert. Die Compliance ist gefährdet. Dies sind legitime Druckpunkte, die (und oft tun sie es) zu Forderungen nach einem vollständigen Neubau führen können.
Aber hier ist, was wir immer wieder gesehen haben: Während der Schmerz real ist, ist ein vollständiger Rewrite oft nicht der klügste oder schnellste Weg, um ihn zu lindern. In vielen Fällen können Sie das zugrunde liegende Problem — Leistung, Sicherheit, Flexibilität — mit einem viel kleineren, sichereren Schritt angehen.
Im Folgenden sind gängige Szenarien aufgeführt, die häufig dazu führen, dass Teams einen Rewrite in Betracht ziehen — und was stattdessen tatsächlich funktioniert hat.
1. Ihr Stack ist aktiv gefährlich
- Keine Tests
- Sicherheitslücken in der Produktion
- Veraltete Abhängigkeiten
- Niemand, der den Code versteht
Dies sind ernsthafte Risiken – und in einigen Fällen müssen kritische Module neu geschrieben werden. Aber das bedeutet nicht, dass die gesamte Codebasis verschwinden muss.
Beispiel: Ein Kunde kam zu uns mit einem Rails 3 Monolithen. Keine Test-Suite, deflierte Authentifizierungsabläufe, aufgegebene Gems. Anstatt alles neu zu bauen, haben wir das Zahlungsmodul (das volatilste Stück) herausgearbeitet, es als eigenständigen Dienst neu geschrieben und Tests sowie Beobachtbarkeit integriert.
→ Sie reduzierten das kritische Risiko, stellten das Vertrauen wieder her und setzten die Auslieferung fort – ohne die Produktarbeit einzufrieren.
2. Sie ändern das Geschäftsmodell
Wenn sich Ihre Produktstrategie grundlegend ändert – nicht nur durch das Hinzufügen neuer Funktionen, sondern durch eine Verschiebung des gesamten Wertangebots – dann können einige Teile des Codes möglicherweise nicht mehr für Sie von Nutzen sein.
Aber ein Pivot erfordert nicht immer eine neue Grundlage.
Beispiel: Ein SaaS-Unternehmen, das wir beraten haben, plante eine Neuschreibung zur Unterstützung eines großen Produktwandels. Nach der Überprüfung ihrer Architektur stellten wir fest, dass das Backend größtenteils bestehen bleiben konnte. Durch den Aufbau neuer Dienste und die Entkopplung von veralteter Logik, wo nötig, konnten sie 6–9 Monate Arbeit einsparen und die vollständige Einarbeitung ihrer gesamten Benutzerbasis vermeiden.
→ Was sie wirklich benötigten, war keine Neuschreibung – es waren Klarheit, Modularität und ein pragmatischer Lieferplan.
3. Sie können nicht skalieren oder konform sein
Manchmal blockieren alte Systeme wirklich Ihr Wachstum — sei es aufgrund fragiler Integrationen, mangelnder Beobachtbarkeit oder Sicherheitsanforderungen wie SSO, MFA oder Audit-Logs.
Selbst dann ist das vollständige Neuschreiben selten der einzige Weg nach vorne.
Beispiel: Eine B2B SaaS-Plattform hatte die Authentifizierungslogik über fünf Dienste verstreut, keine MFA und keine klare Zuständigkeit. Anstatt das gesamte Authentifizierungssystem neu zu erstellen, entwarfen wir eine moderne Zugriffsschicht, die neben dem bestehenden Stack sitzen konnte.
→ Sie erzielten Compliance- und UX-Gewinne mit minimalen Störungen, ohne Abrechnungsunterbrechungen und einer schnelleren als erwarteten Einführung.
Was verstehen wir unter "Legacy"?
"Legacy" ist kein Schimpfwort – es ist eine Beschreibung. Es bezieht sich allgemein auf Software, die:
- Veraltete Sprachen, Bibliotheken oder Paradigmen verwendet
- Schlechte Dokumentation oder Testabdeckung hat
- Unter Bedingungen erstellt wurde, die nicht mehr existieren
- Mehrere Produkt- oder Teamiterationen überstanden hat
Aber Legacy-Systeme sind auch:
- Bewährt: Sie haben sich unter realen Bedingungen bewährt
- Stabil: Viele übernehmen sensible Operationen (Zahlungen, Logistik, Compliance)
- Profitabel: Sie bilden geschäftskritische Funktionen ab
Aus kultureller Sicht gibt es eine psychologische Anziehungskraft zum Neuen und Glänzenden. Aber etwas nur zu ersetzen, weil es "alt" wirkt, ist wie ein funktionierendes Auto gegen ein neues einzutauschen, nur weil das Armaturenbrett nicht digital ist.
Die echten Risiken von vollständigen Neuschreibungen
Von vorne zu beginnen, mag verlockend erscheinen, aber in Wirklichkeit bergen vollständige Systemneuschreibungen erhebliche Risiken – insbesondere in Sektoren wie Fintech und Gesundheitswesen. Hier sind die Daten:
- Budgetüberschreitungen: Ungefähr 70% der Neuschreibungen von Altsystemen überschreiten ihre Budgets, und die Kosten können ~30 $ pro Codezeile erreichen, was bedeutet, dass selbst mittelgroße Systeme Millionen kosten können. (CAST Software / Mobilize.net)
- Verpasste Fristen: Laut dem CHAOS-Bericht der Standish Group werden nur 16% der Software-Neuschreibprojekte pünktlich und im Budgetrahmen abgeschlossen, während über 50% erheblich verzögert oder unvollständig bleiben. (CHAOS-Bericht 2020 – Zusammenfassung von Henny Portman)
- Verlorene Geschäftslogik: Vollständige Neuschreibungen riskieren den Verlust kritischer Geschäftsregeln, die in nicht dokumentierter Altsystemlogik eingebettet sind. (Gartner 2022 Vorhersagen)
- Teamfluktuation: Längere Neuschreibungsbemühungen (oft 2–3 Jahre) führen zu Burnout und höherer Fluktuation, da Entwickler mit zwei Systemen und verlängerter Unsicherheit jonglieren. (Fluktuationstrends bei Infosys – Economic Times)
- Eingefrorene Fahrpläne: Während vollständiger Neuschreibungen können Teams 12–18 Monate ohne neue Funktionen auskommen, was das Produktwachstum und die Innovation zum Stillstand bringt. (Accenture Life Trends 2023)
- Projektfehler: Alarmierend ist, dass 31% der Neuschreibprojekte komplett scheitern, und viele andere sind gezwungen, zu fragilen Altsystemen zurückzukehren. (CHAOS-Bericht 2020 – Zusammenfassung von Henny Portman)
Neuschreiben ist nicht von Natur aus schlecht – aber es ist von Natur aus riskant. Es sollte niemals die Standardoption sein. Stattdessen muss es eine kalkulierte Geschäftsentscheidung sein, die auf realen technischen, organisatorischen und ROI-Einsichten basiert.
Deshalb wird empfohlen, eine neutrale dritte Partei – wie eine digitale Beratung oder eine Expertenagentur – einzubeziehen. Sie können:
- Die tatsächliche Gesundheit Ihrer Altsysteme prüfen
- Feststellen, ob Ihre Blockaden technischer, team- oder prozessbezogener Natur sind
- Phasenweise, risikoärmere Modernisierungsstrategien vorschlagen, die Innovationen freisetzen, ohne die Stabilität zu opfern
Die strategische Alternative: Inkrementelle Modernisierung
Sie müssen sich nicht zwischen Stagnation und einem riskanten Neuschreiben entscheiden. Es gibt eine dritte — oft übersehene — Option: strategische, gestaffelte Modernisierung.
Anstatt alles neu zu bauen, modernisieren Sie das System Stück für Stück, beginnend mit den Bereichen, die tatsächlich den Fortschritt blockieren. Dieser Ansatz achtet auf den bestehenden Geschäftswert und reduziert gleichzeitig das technische Risiko und die Ausfallzeiten bei der Lieferung.
Warum es funktioniert
Ihr aktuelles System mag unvollkommen sein, aber es erfüllt bereits seinen Zweck: es verarbeitet Produktionsverkehr, speichert Geschäftslogik und hält die Nutzer zufrieden (oder zumindest funktionsfähig). Das ist nichts, was man leichtfertig abtun sollte.
Inkrementelle Modernisierung erkennt diese Realität an. Es geht nicht darum, an der Vergangenheit festzuhalten — es geht darum, kluge, risikoarme Fortschritte in Richtung einer besseren Zukunft zu machen.
Praxisbeispiel: Wie ein HRTech-Erbeunternehmen modernisiert wurde, ohne die Nutzer zu stören
Einer unserer Kunden, eine Plattform für fortgeschrittene psychometrische Bewertungen, kam mit einem großen, stark angepassten System zu uns. Es unterstützte Tausende von Nutzern, war jedoch im Laufe der Jahre zunehmend anfällig geworden – schwer skalierbar, schwer testbar und eng mit veralteter Logik verbunden.
Anstatt von Grund auf neu zu beginnen, arbeiteten wir gemeinsam daran:
- Wichtige Module zu entkoppeln – wie Testgenerierung und Ergebniskalkulation – in eigenständige Komponenten
- Veraltete Logik in moderne APIs zu verpacken, sodass Frontend-Teams Verbesserungen unabhängig bereitstellen konnten
- Beobachtbarkeit und CI/CD-Pipelines schrittweise einzuführen, um die Entwicklungsfriktion ohne eine vollständige Stack-Migration zu reduzieren
Das Ergebnis?
Neue Funktionalitäten wurden im ersten Quartal doppelt so schnell bereitgestellt, es gab keine Störungen für die Nutzer und ein Fahrplan, der nicht mehr von einem Rewrite abhing, um voranzukommen.
Wie inkrementelle Modernisierung funktioniert
Den Monolithen sanft strangulieren
Beginnen Sie damit, selbstständige Teile des Systems zu identifizieren — wie Benutzerauthentifizierung, Rechnungsstellung oder E-Mail-Benachrichtigungen — und extrahieren Sie diese in eigenständige Dienste. Dies ist das Strangler Fig Pattern, das von Martin Fowler populär gemacht wurde, bei dem neue Funktionalitäten die alten umhüllen und schrittweise ersetzen, ohne sie abzuschalten.
Beispiel: Ein Fintech-Unternehmen, mit dem wir zusammengearbeitet haben, ersetzte ihr Rechnungsmodul durch einen eigenständigen Dienst, ohne den Rest des Monolithen zu berühren. Über einen Zeitraum von 6 Monaten isolierten sie weitere Funktionen und ließen schließlich nur einen schlanken Kern zurück.
Adapter erstellen, keine Brecher
Führen Sie Abstraktionsschichten ein, um veraltete interne Systeme von der benutzerfreundlichen Erfahrung zu entkoppeln. Dies ermöglicht es Ihnen, im Hintergrund zu modernisieren, ohne APIs, Benutzerflüsse oder Integrationen zu beeinträchtigen. Denken Sie daran, es wie das Errichten von Gerüsten vor einer Renovierung eines Gebäudes.
Tipp: Dies erleichtert auch später den Austausch von Teilsystemen. Heute sind es die Zahlungen, morgen könnte es Ihre Analyse-Pipeline sein.
Beginnen Sie dort, wo der Schmerz ist
Zielen Sie nicht auf architektonische Reinheit — zielen Sie auf Wirkung. Konzentrieren Sie Ihre Bemühungen auf die Bereiche, die den Nutzern am meisten Schmerzen bereiten oder die Fähigkeit Ihres Teams, zu liefern, verlangsamen. Ist der Produktkatalog unmöglich zu aktualisieren? Ist das Reporting brüchig und unzuverlässig? Fangen Sie dort an.
Faustregel: Modernisieren Sie die 20% des Codes, die 80% des Wertes liefern. Der Rest kann warten.
Breadcrumbs hinterlassen
Dokumentieren Sie seltsame Randfälle und nicht offensichtliche Logik. Eine einzige undokumentierte Regel — wie eine Mehrwertsteuerberechnung aus 2017 — kann einen kritischen Workflow brechen, wenn sie versehentlich entfernt wird.
Tip: Hinterlassen Sie Kommentare wie # Erforderlich aufgrund der Mehrwertsteuerregel von 2017, damit zukünftige Teams verstehen, was nicht entfernt werden darf.
Messung, Refaktorisierung, Wiederholung
Betrachten Sie die Modernisierung als einen fortlaufenden Prozess und nicht als einmaliges Ereignis. Führen Sie Metriken ein: Bauzeit, Bereitstellungsfrequenz, Vorfallanzahl, Wiederherstellungszeit. Nutzen Sie diese dann, um zukünftige Verbesserungen zu rechtfertigen und zu priorisieren.
Pro-Tipp: Eine Kultur kleiner, sicherer Änderungen, die durch Telemetrie unterstützt wird, führt oft zu besseren langfristigen Ergebnissen als ein einzelnes, großes Neuschreibprojekt.
Fragen, die Sie stellen sollten, bevor Sie umschreiben
Bevor Sie den Sprung wagen, versammeln Sie die Stakeholder aus Produkt, Technik und Geschäft — und beantworten Sie diese Fragen gemeinsam:
- Können wir weiterhin Funktionen bereitstellen (auch wenn es langsam ist)?
- Sind mehr als 50 % der ursprünglichen Entwickler noch dabei?
- Ist der aktuelle Stack ein Sicherheits- oder Compliance-Risiko?
- Ist der Schmerz hauptsächlich technischer oder prozessbezogener Natur?
- Interessieren sich die Nutzer für die Probleme, die wir lösen?
- Haben wir die Datenmigration im Detail eingeplant und preislich bewertet?
- Was würden wir verlieren, das nicht dokumentiert ist?
Wenn die meisten Ihrer Antworten ungewiss oder gemischt sind — drücken Sie auf Pause. Holen Sie sich eine externe Perspektive. Gehen Sie nicht blind in das komplexeste technische Projekt, das Ihr Unternehmen jemals angehen könnte.
Zusammenfassung: Nicht alleine umschreiben
Altsysteme sind unvollkommen, aber sie sind oft widerstandsfähig, zuverlässig und tief in Ihr Geschäft integriert.
Umschreibungen können transformierend sein — aber sie können auch verschwenderisch, destabilisierend und unnötig sein. Inkrementelle Modernisierung bietet einen intelligenteren, sichereren Weg nach vorne.
Am wichtigsten: Konsultieren Sie erfahrene Fachleute, bevor Sie sich festlegen. Externe Agenturen und digitale Beratungen bringen Mustererkennung, hart erarbeitete Erfahrung und objektive Einsichten mit. Sie haben nur eine Chance für eine Umschreibung — stellen Sie sicher, dass es der richtige Schritt ist.
