Legacy-Anwendungsmodernisierung für den deutschen Mittelstand: Ein strategischer Leitfaden
Die meisten deutschen Mittelstandsunternehmen betreiben mindestens eine Anwendung, die niemand anfassen will. Sie wickelt Aufträge, Produktionsplanung oder Abrechnung ab, sie läuft seit zwölf Jahren, und der Entwickler, der sie verstanden hat, ist 2019 gegangen. Legacy-Anwendungsmodernisierung ist das Projekt, das immer wieder ins Budget des nächsten Jahres geschoben wird, bis eine PHP-Version das End of Life erreicht, ein Hosting-Anbieter den Support einstellt oder ein Auditor fragt, warum Kundendaten in einem System liegen, das seit 2017 keinen Sicherheitspatch mehr bekommen hat.
Dieser Leitfaden richtet sich an CTOs und IT-Leiter in deutschen Mittelstandsunternehmen, die diese Entscheidung jetzt treffen müssen. Er behandelt, wie du zwischen Modernisieren und Neubauen entscheidest, die fünf Legacy-Situationen, denen wir in deutschen Unternehmen am häufigsten begegnen, einen Prozess, der funktioniert, ohne das Geschäft einzufrieren, und was diese Projekte realistisch kosten.
Modernisieren oder neu bauen: ein Entscheidungsrahmen mit echten Kriterien
Der Instinkt der meisten Engineering-Teams ist der Rewrite. Der Instinkt der meisten Finanzabteilungen ist das Weiterflicken. Beides ist meistens falsch, und die richtige Antwort hängt von einer Handvoll Kriterien ab, die du in einer Woche bewerten kannst.
Beginne mit der Geschäftslogik. Wenn die Anwendung Regeln enthält, die nirgendwo sonst aufgeschrieben sind (Preisausnahmen, steuerliche Sonderfälle, die Art, wie die Aufträge eines bestimmten Kunden auf Lager verteilt werden), bedeutet ein Rewrite, all das von Grund auf neu zu entdecken. Modernisierung im Bestand bewahrt das Verhalten, während du die Technologie drumherum ersetzt. Ist die Logik dagegen dünn und liegt der Wert vor allem in den Daten, trägt ein Neubau deutlich weniger Risiko.
Als Nächstes schau auf die Laufzeitumgebung. Eine Anwendung auf PHP 5.6 oder Symfony 2 lässt sich weiterhin Schritt für Schritt aktualisieren, und Tools wie Rector automatisieren einen großen Teil dieser Arbeit. Eine Anwendung auf einem Framework, das es nicht mehr gibt, oder auf einer Desktop-Technologie wie Windows Forms, die zur Webanwendung werden muss, hat keinen Upgrade-Pfad. Das ist per Definition ein Neubau, auch wenn du das Datenbankschema und das Domänenwissen wiederverwendest.
Dann prüfe die Testabdeckung. Null automatisierte Tests schließen Modernisierung nicht aus, aber sie verändern die erste Phase: Du brauchst Charakterisierungstests, bevor du irgendetwas änderst. Plane das ein.
Schließlich betrachte das Team. Wenn die Leute, die das System warten, noch da sind, können sie bei der Modernisierung ihr Wissen einbringen. Wenn das Wissen mit dem letzten Freelancer gegangen ist, ist ein Neubau mit einem frischen Team manchmal die ehrlichere Option, weil die "Modernisierung" ohnehin ein Rewrite wäre, nur ein verkleideter.
Unsere Faustregel nach Dutzenden solcher Projekte: Modernisieren, wenn die Geschäftslogik wertvoll ist und die Plattform noch einen Upgrade-Pfad hat. Neu bauen, wenn die Plattform tot oder die Logik trivial ist. Wenn du unsicher bist, kostet ein zweiwöchiges Assessment weniger als jede der beiden falschen Entscheidungen, und mehr zum Scoring-Ansatz haben wir in unserem Entscheidungsrahmen Rewrite vs. Refactor geschrieben.
Die fünf Legacy-Szenarien, die wir in deutschen Unternehmen am häufigsten sehen
Der deutsche Mittelstand hat eine besondere Geschichte mit Software. Viele Unternehmen haben in den 2000ern eigene Systeme gebaut, weil nichts auf dem Markt zu ihren Prozessen passte, und diese Systeme laufen noch. Die Situationen wiederholen sich oft genug, dass wir sie beschreiben können.
Symfony-2- und Symfony-3-Anwendungen
Das ist der häufigste Fall in unseren Audits. Eine Symfony-2.8- oder 3.4-Anwendung, oft zwischen 2014 und 2017 gestartet, mit einer Bundle-Struktur aus dieser Zeit, Doctrine-Annotations, Twig-Templates und ein paar hundert Controllern. Die gute Nachricht: Der Upgrade-Pfad zu Symfony 7 existiert und ist gut dokumentiert. Die schlechte Nachricht: Abhängigkeiten. Die Hälfte der 2016 verwendeten Bundles ist aufgegeben, und jedes einzelne muss ersetzt oder vendored werden. Die Mechanik haben wir in Legacy-PHP-Refactoring Schritt für Schritt beschrieben.
PHP-5.x-Systeme ohne Tests
Meist ein eigenes Framework oder schlichtes prozedurales PHP, manchmal mit selbstgebautem ORM. Keine Tests, und oft keine Versionshistorie über die letzten paar Jahre hinaus. Diese Systeme laufen auf PHP 5.6 oder 7.0, weil ein Upgrade einmal etwas kaputtgemacht hat und niemand es wieder gewagt hat. Die Modernisierung beginnt hier damit, den aktuellen Zustand exakt so zu containerisieren, wie er ist, damit du eine reproduzierbare Basis hast, und dann HTTP-Tests gegen die laufende Anwendung zu schreiben, bevor eine einzige Zeile Code angefasst wird.
Windows-Forms-Anwendungen, die zu Webanwendungen werden müssen
Erstaunlich viele Produktionsplanungs- und Lagertools in der deutschen Fertigung sind .NET-Desktop-Anwendungen aus den 2000ern. Sie lassen sich nicht im Bestand modernisieren, wenn das Ziel Browserzugriff, mobile Nutzung oder die Integration mit einem webbasierten ERP ist. Das ist das Neubau-Szenario, aber die Desktop-Anwendung ist eine hervorragende Spezifikation: Jedes Formular, jede Validierungsregel und jeder Report sagt dir, was die Web-Version können muss. Wir behandeln die alte Anwendung als Anforderungsdokument und bauen den Ersatz Bildschirm für Bildschirm, typischerweise als individuelle Webanwendung mit einer API, die auch andere Systeme nutzen können.
Eigenentwicklungen mit SAP-Anbindung
Viele Mittelständler betreiben SAP für die Finanzen und haben eigene Anwendungen für alles drumherum gebaut, was SAP für ihre Branche schlecht abdeckt: Konfiguratoren, Außendienst-Tools, Kundenportale. Die Eigenentwicklung hinkt oft Jahre hinterher, während die SAP-Seite planmäßig aktualisiert wird. Diese zu modernisieren heißt, zuerst die Integration zu entwirren. Direkter Datenbankzugriff auf SAP-Tabellen, über die Codebasis verstreute RFC-Aufrufe und nächtlicher CSV-Austausch müssen hinter einer einzigen Integrationsschicht zusammengeführt werden, bevor die Anwendung selbst bewegt werden kann.
Proprietäre Frameworks ohne Dokumentation
Der härteste Fall. Eine frühere Agentur oder ein früherer Mitarbeiter hat ein Framework gebaut, die Anwendung darauf gebaut und ist gegangen. Niemand weiß, wie das Routing funktioniert, das Templating-System ist einzigartig, und es gibt keine Dokumentation. Hier zählt die Assessment-Phase mehr als irgendwo sonst: Du musst das Framework kartieren, bevor du entscheiden kannst, ob die Anwendung darauf erhaltenswert ist. Oft lautet die Antwort auf eine Strangler-Fig-Migration, bei der neue Features vom ersten Tag an in eine Symfony-Anwendung wandern und das alte Framework mit der Zeit ausgetrocknet wird.
Der Modernisierungsprozess, Schritt für Schritt
Egal welches Szenario, der Prozess hat dieselbe Form. Was sich ändert, ist die Dauer der einzelnen Phasen.
Die erste Phase ist die Inventur. Bevor du irgendetwas schätzt, musst du wissen, was tatsächlich da ist: welche PHP-Version und Extensions, welche Abhängigkeiten und deren Wartungsstatus, wie viele Routen und Einstiegspunkte existieren, welche davon noch Traffic bekommen, wo die Datenbank zu einem undokumentierten Durcheinander gewachsen ist und welche Integrationen von der Anwendung abhängen. Die Access-Logs der letzten drei Monate sind in dieser Phase der mit Abstand nützlichste Input, weil sie dir sagen, welche Teile des Systems du einfach streichen kannst. In den meisten Audits bedienen 20 bis 40 Prozent der Codebasis überhaupt keinen Traffic.
Die zweite Phase ist die Risikobewertung. Nicht jeder Teil eines Legacy-Systems ist gleich gefährlich. Zahlungsabwicklung, Authentifizierung und alles, was ins ERP schreibt, bekommen die höchste Aufmerksamkeit. Reporting-Ansichten, die eine Handvoll Leute einmal im Monat öffnen, die niedrigste. Das Ergebnis ist eine priorisierte Liste von Komponenten mit einer Migrationsreihenfolge, und hier entscheidest du auch, was Charakterisierungstests braucht, bevor Änderungen beginnen. Unsere Code-Quality-Consulting-Engagements enden meist an dieser Stelle mit einem schriftlichen Bericht, wenn der Kunde die Arbeit intern erledigen will.
Die dritte Phase ist die Migration selbst, und hier empfehlen wir fast immer das Strangler-Fig-Pattern. Statt eines Big-Bang-Umstiegs setzt du eine Routing-Schicht vor die alte Anwendung, baust das neue System daneben auf und verschiebst den Traffic Route für Route oder Feature für Feature. Beide Systeme teilen sich zunächst die Datenbank, dann wird das Schema Stück für Stück migriert. Die alte Anwendung schrumpft, bis sie abgeschaltet werden kann. Auf dem Papier ist das Pattern langsamer als ein Rewrite, aber es lässt das Unternehmen nie ohne funktionierendes System zurück, und du kannst an jedem Punkt aufhören und hast eine teilweise modernisierte Anwendung, die immer noch besser ist als der Ausgangspunkt. Die Mechanik haben wir in Das Strangler-Fig-Pattern beschrieben.
Die vierte Phase wird oft vergessen: die betriebliche Übergabe. Eine modernisierte Anwendung, die nur der externe Partner versteht, ist ein neues Legacy-System in Wartestellung. Dokumentation, CI-Pipelines, Monitoring und eine Phase, in der das interne Team Änderungen mit Unterstützung ausliefert, gehören zum Projekt, sie sind keine optionalen Extras.
Was Legacy-Anwendungsmodernisierung in Deutschland kostet und wie lange sie dauert
Jedes Projekt ist anders, aber nach genügend Projekten zeichnen sich Spannen ab. Das sind Zahlen für den deutschen Markt mit Senior-Engineers, entweder freiberuflich oder aus einer kleinen Beratung, keine Agentursätze mit Account-Management-Overhead.
Ein Upgrade von Symfony 2 oder 3 auf Symfony 7 für eine mittelgroße Anwendung (50 bis 150 Tausend Zeilen, ein paar hundert Routen) dauert typischerweise drei bis sechs Monate mit ein bis zwei Engineers und landet zwischen 60.000 und 150.000 Euro. Rector und ein guter Test-Harness drücken es Richtung unteres Ende.
Ein PHP-5.x-System ohne Tests kostet pro Zeile mehr wegen der Testschreibphase. Rechne mit vier bis neun Monaten und 80.000 bis 200.000 Euro, wobei die ersten sechs Wochen fast vollständig für Containerisierung und Charakterisierungstests draufgehen, bevor überhaupt refactored wird.
Ein Neubau von Windows Forms zu Web hängt stark von der Zahl der Bildschirme und Reports ab. Ein Planungstool mit 30 bis 50 Formularen ist meist ein Projekt von sechs bis zwölf Monaten mit zwei bis drei Engineers, im Bereich von 150.000 bis 350.000 Euro. Die alte Anwendung als Spezifikation verkürzt die Discovery-Phase gegenüber einem Greenfield-Projekt erheblich.
SAP-angebundene Eigenentwicklungen bekommen eine zusätzliche Phase für die Integrationsschicht von ein bis drei Monaten obendrauf, und die Arbeit auf SAP-Seite erfordert in der Regel auch deinen SAP-Partner.
Migrationen proprietärer Frameworks sind vorab am schwersten zu schätzen. Wir bestehen immer auf einem bezahlten zwei- bis vierwöchigen Assessment, bevor wir die Migration anbieten, weil der Unterschied zwischen einem Framework, das lediglich undokumentiert ist, und einem, das nicht zu retten ist, leicht Faktor drei bei den Kosten ausmacht.
Zwei Anmerkungen zum Geld. Erstens: Vergleiche diese Zahlen damit, was dich das Legacy-System heute kostet: Hosting für einen nicht mehr unterstützten Stack, die Stunden, die dein Team mit Workarounds verbringt, die Features, die du nicht bauen kannst, und das Risiko eines Vorfalls, den niemand beheben kann. Die meisten Unternehmen, die diese Rechnung aufmachen, stellen fest, dass sich die Modernisierung innerhalb von zwei bis drei Jahren bezahlt macht. Zweitens: Phasenweise Lieferung heißt, dass das Budget keine einmalige Verpflichtung ist. Eine Strangler-Fig-Migration lässt sich Quartal für Quartal finanzieren, und jedes Quartal endet mit einem funktionierenden System.
Wie Wolf-Tech das mit Kunden durcharbeitet
Wir sind ein kleines Team aus Berlin, das den Großteil des letzten Jahrzehnts in genau diesen Systemen verbracht hat: Symfony-Anwendungen aus den frühen 2010ern, PHP-5-Monolithen in Fertigungs- und Logistikunternehmen und Eigenentwicklungen, die an SAP angeflanscht sind. Unsere Legacy-Code-Optimierung-Engagements beginnen mit dem oben beschriebenen Assessment und liefern einen schriftlichen Migrationsplan mit der priorisierten Komponentenliste, der Teststrategie und einem phasenweisen Budget. Kunden können diesen Plan zu ihrem internen Team oder einem anderen Partner mitnehmen oder mit uns die Migration fortsetzen.
Während der Migration arbeiten wir mit dem internen Team zusammen statt an ihm vorbei. Das ist im ersten Monat langsamer und in jedem weiteren Monat schneller, weil das Wissen im Unternehmen bleibt.
Wenn du ein System hast, das zu einem der fünf Szenarien oben passt, und eine zweite Meinung willst, bevor du ein Budget festlegst, schreib an hello@wolf-tech.io oder erfahre mehr über unsere Arbeitsweise auf wolf-tech.io. Ein erstes Gespräch über deine Codebasis kostet nichts, und es erspart meist ein paar falsche Annahmen.