Modernisierung: PHP-Upgrade und schrittweise Ablösung von Altsystemen

Manche Anwendungen lassen sich nicht mehr nur warten. Sie brauchen einen ehrlichen Sanierungsplan. PHP 5.6 ist seit 2019 End-of-Life. Symfony 2 wird seit Jahren nicht mehr unterstützt. Eine jQuery-1.x-Frontend-Code-Basis ist schwer zu erweitern. Wenn Sie an diesem Punkt sind, brauchen Sie keinen Neuanfang, sondern eine Modernisierung, die das Bestehende respektiert und schrittweise auf einen aktuellen Stand bringt.

Wir machen Modernisierung in Etappen. Kein „wir bauen das mal eben in $LIEBLINGSFRAMEWORK neu", sondern ein Plan mit klaren Meilensteinen, jeder davon einzeln freigeb- und abnehmbar.

Schrittweise Ablösung (Fachbegriff: „Strangler-Fig-Pattern")

Statt Ihre laufende Software komplett neu zu schreiben, bauen wir das neue System parallel auf. Feature für Feature wandert rüber, das alte System bleibt so lange in Betrieb, bis es nicht mehr gebraucht wird. Kein „Big Bang", kein Totalausfall-Risiko. Mehr dazu im Glossar.

Was wir konkret tun

PHP-Upgrades. Wir bringen Ihre PHP-Anwendung sicher von älteren Versionen auf aktuelle. Das umfasst die Analyse aller Inkompatibilitäten, schrittweise Anpassung im Code, Test in Staging, kontrolliertes Deployment. Typische Sprünge: 5.6 → 7.4, 7.x → 8.2, manchmal in einer Etappe, oft in zwei.

Framework-Migrationen. Symfony-Versionssprünge, Migration von Zend auf Laravel, Ablösung selbstgeschriebener Frameworks durch etablierte Lösungen. Auch hier in Etappen: zuerst Routing und Bootstrap modernisieren, dann Controller, dann Persistenz. Mit dem Strangler-Fig-Pattern lassen sich Teile der Anwendung schon im neuen Framework betreiben, während andere noch im alten laufen.

Frontend-Modernisierung. jQuery-Anwendungen schrittweise auf moderne Build-Pipelines bringen. Wo sinnvoll, einzelne Module in einem aktuellen Framework neu aufsetzen, statt alles auf einmal umzubauen. Wir empfehlen nur dann ein Frontend-Framework, wenn die Anforderungen es rechtfertigen. Viele Anwendungen kommen mit modernem Vanilla-JavaScript besser zurecht.

Datenbank-Migrationen. MySQL-Versionssprünge, Migration von MyISAM auf InnoDB, Aufräumarbeiten in gewachsenen Schemata. Mit Backup, Test und Rollback-Plan auf jedem Schritt.

Ablauf in Schritten

1. Ist-Aufnahme (1–2 Wochen). Wir dokumentieren das System: Komponenten, Versionen, Abhängigkeiten, kritische Stellen, vorhandene Tests. Das ist die Grundlage für den Plan.
2. Tilgungsplan (1 Woche). Wir schlagen eine Etappenfolge vor, mit Aufwand und Risiko pro Etappe. Sie entscheiden, welche Etappen jetzt umgesetzt werden und welche später.
3. Etappe 1, typischerweise die kritischste Sicherheits- oder EOL-Lücke. Umsetzung, Test, Deployment, Abnahme.
4. Etappe 2, typischerweise Framework- oder Major-Version-Sprung. Mit Staging, Regressionstests, Cutover-Plan.
5. Etappe 3 und folgende. Refactoring innerhalb der modernisierten Codebasis, Tests einführen, Build-Pipeline einrichten.
6. Übergang in laufende Wartung. Nach Abschluss der Modernisierung wechselt das System in den regulären Wartungsmodus.

Was Sie bekommen

• Schriftlicher Tilgungsplan mit Etappen, Aufwänden und Risiken
• Etappenweise Abrechnung mit Festpreis pro Etappe nach detaillierter Schätzung
• Funktionierende Staging-Umgebung mit echten Testdaten
• Rollback-Plan für jede Etappe, sodass Sie jederzeit zurück können
• Dokumentation aller Änderungen, die auch andere Dienstleister verstehen
• Tests für die geschäftskritischen Pfade, soweit sinnvoll und vereinbart
• Übergabe in laufende Software-Wartung am Ende

FAQ

Was bedeutet Strangler-Fig-Pattern in der Praxis?

Strangler-Fig bezeichnet ein Vorgehen, bei dem neue Funktionalität schrittweise um die alte herumwächst und sie nach und nach ablöst, wie eine Würgefeige um einen Baum. Konkret: Wir setzen einen Router oder Proxy vor die alte Anwendung, der Anfragen entweder an den Altcode oder an neu gebaute Module weiterleitet. So können wir ein Modul nach dem anderen neu schreiben, während die Anwendung produktiv bleibt. Im Glossar zum Strangler-Fig-Pattern finden Sie eine ausführlichere Erklärung mit Beispiel.

Wie lange dauert eine typische Modernisierung?

Das hängt stark vom System ab. Ein reines PHP-Upgrade von 7.4 auf 8.2 in einer mittelgroßen Anwendung dauert oft 4–8 Wochen Kalenderzeit. Ein vollständiger Framework-Wechsel von Symfony 2 auf 6 für eine Anwendung mit 200.000 Codezeilen kann 6–12 Monate dauern, aufgeteilt in Etappen, mit produktivem Betrieb während der gesamten Zeit. Ein Beispiel finden Sie im Szenario zur PHP-5.6-Migration.

Müssen wir während der Modernisierung den Betrieb einstellen?

Nein. Genau das verhindert das Strangler-Fig-Pattern und unsere Etappenplanung. Jede Etappe ist so dimensioniert, dass das System nach ihrem Abschluss wieder voll funktionsfähig ist. Größere Cutover-Schritte legen wir in Wartungsfenster, meist Sonntagmorgen oder Feiertagsabend. Bei vielen Modernisierungen bleibt der Betrieb komplett unterbrechungsfrei. Wir besprechen das pro Etappe.

Was, wenn unser Code so alt ist, dass eine Modernisierung sich nicht lohnt?

Das kommt vor, meistens aber seltener, als Sie denken. Ein System, das seit 20 Jahren produktiv läuft, bildet Geschäftsprozesse ab, die genau zu Ihrem Unternehmen passen. Diesen Wert kann ein Neuanfang nur unter hohen Kosten und Risiken nachbauen. Wenn die Modernisierung trotzdem teurer wäre als ein Neuanfang, sagen wir das ehrlich und besprechen mit Ihnen die Optionen Neuentwicklung mit Parallelbetrieb. Lesen Sie auch das Szenario zur Java-Anwendung aus 2008.

Was unterscheidet Modernisierung von Refactoring?

Refactoring ist die Verbesserung der inneren Struktur des Codes, ohne sein nach außen sichtbares Verhalten zu ändern (mehr dazu im Glossar zu Refactoring). Modernisierung ist umfassender: Sie umfasst auch Versions- und Frameworkwechsel, Infrastrukturanpassungen, Build-Pipelines, Testabdeckung. Refactoring ist oft ein Bestandteil von Modernisierung, aber nicht jedes Refactoring ist Modernisierung. Kleinere Refactorings führen wir auch im Rahmen der laufenden Wartung oder Weiterentwicklung durch.

Modernisierung als Voraussetzung für KI

Viele KI-Funktionen lassen sich nicht in ein veraltetes System integrieren, die Architektur lässt es schlicht nicht zu. Eine Modernisierung auf einen aktuellen Stack ist oft die Voraussetzung dafür, dass Ihr Unternehmen später KI sinnvoll einsetzen kann. Wir bauen mit diesem Ziel im Hinterkopf.

Bereit, anzufangen?

Eine Modernisierung beginnt mit einer ehrlichen Ist-Aufnahme. Lassen Sie uns einen Termin vereinbaren, in dem wir Ihr System gemeinsam ansehen und einen ersten Tilgungsplan skizzieren. Sie bekommen am Ende dieses Termins eine grobe Einschätzung, ob und wie sich Ihre Software modernisieren lässt. Ohne Vertragsbindung.

Modernisierung planen →