Migration von Legacy-PHP-Sites ohne Unterbrechung des Geschäftsbetriebs

Bei DigiForge haben wir schon zu viele Legacy-PHP-Migrationsprojekte schiefgehen sehen – nicht weil die Technologie schwierig war, sondern weil das Geschäft während des Umzugs weiterlief. Das Wort „Migration“ selbst stammt aus dem Lateinischen und bedeutet „von einem Ort zum anderen ziehen“. In der Informatik bezeichnet es speziell „die Einführung eines neuen Computersystems oder die Übertragung von Informationen von einem Systemtyp auf einen anderen“ [1]. Das klingt einfach, aber wenn Sie einen PHP-Monolithen migrieren, der Bestellungen, Benutzersitzungen und Zahlungsintegrationen verwaltet, besteht die eigentliche Herausforderung darin, sicherzustellen, dass Ihre Kunden nichts davon mitbekommen.

Bewerten, bevor Sie auch nur eine Zeile Code anfassen

Bevor wir auch nur daran denken, neue Router zu schreiben oder ein modernes Framework zu installieren, prüfen wir die bestehende Anwendung – nicht nur ihren Code, sondern auch ihr Laufzeitverhalten. Beginnen Sie mit einer gründlichen Bestandsaufnahme aller Einstiegspunkte: jeder Route, jeder Cron-Job, jede geplante Aufgabe. Legacy-PHP-Apps haben oft versteckte Endpunkte – vielleicht eine cron.php, die jeden Sonntag die Gehaltsabrechnung ausführt, oder einen benutzerdefinierten API-Endpunkt, der von einem externen Versanddienst genutzt wird. Wenn Sie einen übersehen, wird die Migration etwas kaputt machen.

Dokumentieren Sie während des Audits auch den Datenfluss: Wie verbindet sich die alte Anwendung mit der Datenbank? Gibt es gespeicherte Prozeduren? Gibt es ein gemeinsames Dateisystem für hochgeladene Bilder oder Sitzungsdateien? Viele Legacy-PHP-Apps verwenden dateibasierte Sitzungen, die sich nicht horizontal skalieren lassen. Das ist eine rote Flagge, die wir frühzeitig angehen, oft indem wir Sitzungen nach Redis oder in eine Datenbank migrieren.

Wählen Sie eine Migrationsstrategie, die zu Ihrer Risikobereitschaft passt

Bei DigiForge empfehlen wir in der Regel eine von drei Strategien, je nachdem, wie viel Risiko das Unternehmen verkraften kann.

Der Big-Bang-Rewrite

Dies ist die dramatischste Variante: Sie bauen das neue System von Grund auf neu und schalten dann auf einen Schlag um. Es ist auch die riskanteste. Wir haben erlebt, dass dies nur funktioniert, wenn die Legacy-Anwendung klein ist (denken Sie an ein paar Dutzend Seiten) oder wenn das Unternehmen ein geplantes Wartungsfenster tolerieren kann. Bei allem, was Echtzeittransaktionen oder 24/7-Kunden betrifft, sollten Sie diesen Ansatz vermeiden.

Das Strangler-Fig-Muster

Benannt nach der tropischen Pflanze, die ihren Wirt langsam umschlingt, ermöglicht dieses Muster, Teile der Legacy-Anwendung schrittweise zu ersetzen. Sie leiten bestimmte URLs oder API-Endpunkte zum neuen Code um, während der Rest weiterhin auf dem alten PHP läuft. Ein Load Balancer oder Reverse Proxy (wie Nginx oder HAProxy) kann den Datenverkehr basierend auf dem Anforderungspfad lenken. Jedes ersetzte Stück reduziert das Risiko, da Sie jeweils nur eine kleine Fläche ändern. Wir verwenden dieses Muster in fast jeder großen Migration.

Feature Flags überall

Selbst mit einer Würgefeige bieten Feature Flags einen Notausschalter. Wenn der neue Checkout-Endpunkt Fehler wirft, schalten Sie ein Flag um und der Datenverkehr geht zurück zum alten Code – ganz ohne Deployment. Tools wie LaunchDarkly oder ein einfacher datenbankgesteuerter Schalter funktionieren gut. Wir programmieren alles hinter einem Flag, sogar die Datenbankverbindung. So können wir eine neue Abfrage in der Produktion mit nur wenigen Benutzern testen, bevor wir sie für alle freigeben.

Führen Sie die Migration mit Null Ausfallzeit durch

Null Ausfallzeit bedeutet nicht null Risiko – es bedeutet, dass der Benutzer nie eine Fehlerseite sieht. Der Schlüssel ist Dual-Writing: Wenn Sie zu einem neuen Datenbankschema oder einem anderen Speicher-Backend wechseln, schreiben Sie Daten gleichzeitig in das alte und das neue System. Beginnen Sie damit, in beide zu schreiben, aber aus dem alten zu lesen. Sobald das neue System aufgeholt hat und Sie die Datenintegrität überprüft haben, schalten Sie die Lesevorgänge auf das neue System um. Schließlich stellen Sie das Schreiben in das alte System ein. Dies funktioniert für Datenbanken, Warteschlangen, Dateispeicher und sogar API-Integrationen.

<?php
// Example: dual-write to old and new databases
$legacyDb = getLegacyConnection();
$newDb = getNewConnection();

function saveOrder($orderData) {
    global $legacyDb, $newDb;
    // Write to both
    $legacyDb->insert('orders', $orderData);
    $newDb->insert('orders', $orderData);
}

// Read from legacy until we verify new data
function getOrder($orderId) {
    global $legacyDb;
    return $legacyDb->fetchOne('SELECT * FROM orders WHERE id = ?', [$orderId]);
}

Während der Dual-Write-Phase führen Sie alle paar Minuten Abgleichsskripte aus, um die beiden Speicher zu vergleichen. Jegliche Abweichungen werden schnell erkannt. Sobald das neue System einen vollständigen Geschäftszyklus (in der Regel 48 Stunden) fehlerfrei durchläuft, schalten Sie die Lesezugriffe um. Überwachen Sie die Fehlerprotokolle in der nächsten Stunde genau – wenn etwas schief aussieht, schalten Sie zurück.

Verwaltung des Sitzungszustands

Legacy-PHP verwendet oft $_SESSION, das in Dateien gespeichert wird. Eine neue Laravel- oder Symfony-Anwendung erwartet hingegen Datenbank- oder Redis-Sitzungen. Um Benutzer während der Migration angemeldet zu halten, implementieren wir eine Sitzungsbrücke: Die alte Anwendung schreibt Sitzungen sowohl in Dateien als auch in einen gemeinsamen Redis-Speicher; die neue Anwendung liest aus Redis. Sobald die Migration abgeschlossen ist, schalten Sie den Dateischreiber ab und entfernen den alten Sitzungs-Handler.

Validierung nach der Migration und Rollback-Planung

Selbst bei sorgfältiger Planung wird etwas schiefgehen. Das ist nicht Pessimismus – es ist technischer Realismus. Bevor Sie den finalen Schalter umlegen, schreiben Sie einen Rollback-Plan, der das Wiederherstellen von DNS-Einträgen, das Rückgängigmachen von Datenbankschema-Änderungen und das Hochfahren der alten Anwendung aus einem Snapshot umfasst. Üben Sie den Rollback mindestens einmal in der Staging-Umgebung.

Bei DigiForge lassen wir die alte Produktionsumgebung nach einer größeren Migration immer mindestens zwei Wochen lang laufen. Die Kosten für ein paar zusätzliche Server sind trivial im Vergleich zu den Kosten eines fehlgeschlagenen Rollbacks, das Stunden dauert.

Die Validierung geht über das reine Prüfen, ob Seiten laden, hinaus. Wir führen automatisierte Geschäftstransaktionstests durch: eine Bestellung aufgeben, ein Profil aktualisieren, eine Rückerstattung bearbeiten. Vergleichen Sie die Ausgabe kritischer API-Endpunkte zwischen alt und neu. Wenn Sie ein Überwachungstool wie New Relic oder Sentry verwenden, richten Sie benutzerdefinierte Alarme für alle 5xx-Fehler oder langsame Abfragen ein. Beziehen Sie schließlich das Geschäftsteam ein – lassen Sie es seine täglichen Arbeitsabläufe auf dem neuen System in einer Staging-Umgebung ausführen, bevor Sie live gehen.

Häufige Fallstricke und wie wir sie vermeiden

• Annahme, dass der alte Code korrekt ist. Legacy-PHP hat oft stille Fehler, die zu 'Features' wurden. Jedes Verhalten nachbilden? Manchmal ist es sicherer, den Fehler in der neuen Version zu beheben, wenn das Geschäft zustimmt.
• Vergessen von Cron-Jobs und geplanten Aufgaben. Diese alten curl-Aufrufe an ein benutzerdefiniertes Skript? Sie brauchen ein Zuhause im neuen System. Wir migrieren Cron-Aufgaben zu einem Task-Scheduler wie Laravels Scheduler oder einem dedizierten Worker.
• Vernachlässigung von Drittanbieter-Integrationen. Zahlungsgateways, Versand-APIs und Partner-Webhooks senden Daten in bestimmten Formaten. Testen Sie die Integrationsendpunkte frühzeitig – Sie möchten kein Format-Mismatch am Black Friday entdecken.

Eine weitere Lektion, die wir gelernt haben: Vertrauen Sie nicht der alten Dokumentation. Der Code ist die Quelle der Wahrheit. Wir führen immer ein tiefgehendes Code-Review mit dem Entwickler durch, der das Original geschrieben hat (falls verfügbar), oder mit einem Teammitglied, das es seit Jahren betreut. Dessen mentales Modell der Eigenheiten der App ist unbezahlbar.

Fazit

Die Migration einer alten PHP-Website gleicht einer offenen Herzoperation an einem Patienten, der einen Marathon läuft. Das Risiko ist real, aber die Belohnung – moderne Leistung, Sicherheit und Entwicklerproduktivität – ist enorm. Bei DigiForge haben wir Dutzende von Unternehmen durch diesen Prozess geführt. Der Schlüssel liegt darin, in kleinen, umkehrbaren Schritten vorzugehen, das alte System stets am Laufen zu halten und die Überwachung nicht zu beenden, bis Sie sicher sind, dass das neue System stabil ist.

Denken Sie daran: Bei einer Migration geht es nicht nur um die Technologie – es geht darum, Ihr Unternehmen am Laufen zu halten, während Sie den Motor im Flug wechseln. Planen Sie sorgfältig, testen Sie unermüdlich und halten Sie stets einen Rollback bereit. Ihre Benutzer werden nie merken, dass sich etwas geändert hat.