Eine bestehende PHP-Anwendung muss nicht auf einmal neu geschrieben werden. Eine schrittweise Ablösung ermöglicht es, Funktionen zu übertragen, während das Geschäft weiterläuft. Sie funktioniert jedoch nur, wenn präzise festgelegt ist, welches System den jeweiligen Vorgang verarbeitet und welches die Hoheit über die jeweiligen Daten hat. Ohne solche Grenzen können beide Anwendungen unterschiedliche Regeln ausführen, inkompatible Schreibvorgänge akzeptieren und Ergebnisse erzeugen, die sich nur schwer abgleichen lassen.
Ziel ist es nicht, zwei Implementierungen auf unbestimmte Zeit parallel zu betreiben. Verantwortlichkeiten sollen kontrolliert verlagert, das erforderliche Verhalten der neuen Lösung überprüft und alte Abhängigkeiten entfernt werden, sobald genügend Nachweise vorliegen. Dafür braucht es fachliche Grenzen, Observability, eine einzige Datenquelle der Wahrheit pro Datenbereich und gemeinsam von Technik und Produkt vereinbarte Kriterien für den Fortschritt.
Warum zwei parallel betriebene Anwendungen nicht ausreichen
Dass eine alte und eine neue Anwendung verfügbar sind, definiert noch keine Migration. Wenn beide denselben Vorgang annehmen, können sie unterschiedliche Regeln für Validierungen, Berechtigungen, Preise, Status oder Nebenwirkungen anwenden. Das Problem zeigt sich oft erst spät: Eine Rechnung wird auf zwei Arten berechnet, eine Benachrichtigung wird zweimal versendet oder eine Statusänderung wird nicht in allen Systemen übernommen.
Für die schrittweise Ablösung eines PHP-Altsystems muss ausdrücklich beschrieben werden, welche Funktion übertragen wird, wer die Anfragen erhält und wo die Datenhoheit liegt. Die Grenze sollte fachlich definiert sein und nicht einfach aus einer Liste von Controllern oder Tabellen bestehen. Eine Funktion wie „eine Rückgabe bearbeiten“ kann Autorisierung, Bestandsaktualisierung und Rückerstattung umfassen. Wird sie aufgeteilt, ohne diese Abhängigkeiten zu verstehen, entsteht eine irreführende Grenze.
Dokumentiere vor einer Änderung des Routings das beobachtbare Verhalten: Eingaben, Ausgaben, relevante Fehler, Berechtigungen, Nebenwirkungen und externe Abhängigkeiten. Unterscheide Geschäftsregeln von zufälligen Implementierungsdetails. Nicht jedes historische Verhalten muss erhalten bleiben, aber jede beabsichtigte Änderung muss ausdrücklich genehmigt und als solche getestet werden, statt stillschweigend der Migration zugeschrieben zu werden.
Eine erste Funktion auswählen, deren Verhalten überprüfbar ist
Der erste Kandidat muss weder der kleinste noch der sichtbarste sein. Sinnvoll ist eine Funktion mit verständlichen Grenzen, überschaubarer Kopplung und überprüfbarem Ergebnis. Auch der operative Nutzen zählt: Eine Migration kann ein Risiko verringern, häufige Änderungen ermöglichen oder einen Bereich verbessern, den das Unternehmen weiterentwickeln muss.
- Kopplung: Ermittle Aufrufe anderer Module, direkten Zugriff auf gemeinsam genutzte Tabellen, geplante Aufgaben und Abhängigkeiten von globalem Zustand. Viele Verbindungen schließen eine Migration nicht aus, erhöhen aber den Aufwand, die Grenze zu definieren.
- Überprüfbarkeit: Prüfe, ob sich repräsentative Fälle formulieren und Ergebnisse beobachten lassen, ohne auf subjektive Interpretationen angewiesen zu sein.
- Auswirkungen und Umkehrbarkeit: Bewerte, was passiert, wenn die Funktion ausfällt, und ob sie ohne Datenverlust oder wiederholte externe Effekte auf den bisherigen Pfad zurückgesetzt werden kann.
- Betriebliche Vorbereitung: Stelle sicher, dass Verantwortliche, Metriken und Verfahren zur Untersuchung von Abweichungen vorhanden sind, bevor echter Traffic umgeleitet wird.
Ein kurzes Inventar hilft: Funktion, Nutzer, gelesene und geänderte Daten, externe Effekte, Produktverantwortliche und technische Verantwortliche. Wenn sich nicht beantworten lässt, wer einen Vorgang verwendet oder welches System einen Datensatz aktualisiert, muss zunächst das System besser verstanden werden. Eine sofortige Migration verringert die Unsicherheit nicht.
Routing und Datenhoheit festlegen
Der Router muss ausdrücklich entscheiden, welche Implementierung eine Anfrage verarbeitet. Je nach Architektur kann dies eine Anwendungsschicht, ein Gateway oder eine Entscheidung am Einstiegspunkt übernehmen. Entscheidend ist, dass das Kriterium beobachtbar und konsistent ist: etwa nach Funktion, Kunde, Vorgang oder einer kontrollierten Kohorte. Vermeide, dass zwei Pfade denselben Auftrag ohne Abstimmung verarbeiten können.
Weise an jeder Grenze einem Eigentümer die Verantwortung für jeden Datensatz oder jedes Aggregat zu. Ist beispielsweise das neue System Eigentümer der Bestellungen, sollte das alte sie nicht weiterhin direkt über gemeinsam genutzte Tabellen ändern. Andere Komponenten können je nach Konsistenzanforderungen eine definierte Schnittstelle abfragen oder Änderungen über Events erhalten. Eine gemeinsame Datenbank kann eine Übergangsphase darstellen, bedeutet aber nicht, dass die Datenhoheit geteilt wird.
Bei der Synchronisierung müssen Richtung und Zweck festgelegt sein. Eine Lesekopie kann Berichte oder alte Consumer versorgen; sie darf nicht versehentlich zu einer zweiten autorisierten Schreibinstanz werden. Beim Austausch von Events sind IDs, bei Bedarf die Reihenfolge, Wiederholungsversuche, Deduplizierung und der Umgang mit fehlgeschlagenen Nachrichten festzulegen. Kläre außerdem, wie Verzögerungen erkannt werden und wer Abweichungen behebt.
Mehrdeutige doppelte Schreibvorgänge vermeiden
Während einer Anfrage in zwei Systeme zu schreiben, scheint eine einfache Möglichkeit zu sein, sie synchron zu halten, führt aber zu Teilausfällen: Ein Schreibvorgang kann erfolgreich sein, der andere nicht. Eine Wiederholung der Anfrage könnte einen Vorgang duplizieren. Ohne eine Strategie für Idempotenz, Abstimmung und Fehler gibt es keine einzelne Transaktion, die Konsistenz zwischen unabhängigen Anwendungen garantiert.
Setze für jeden Vorgang auf eine einzige Schreibinstanz mit Datenhoheit. Während einer Übergangsphase kann das zuständige System Änderungen veröffentlichen, um eine Projektion oder Kompatibilitätskopie zu aktualisieren. Bei asynchronen Prozessen sollten, sofern die Infrastruktur es zulässt, die Änderung und ihre Nachricht zuverlässig innerhalb derselben Transaktionsgrenze erfasst werden; außerdem sollten Consumer idempotent ausgelegt sein. Wenn eine konkrete Einschränkung doppelte Schreibvorgänge erfordert, behandle dies als zeitlich begrenzte Ausnahme: Lege Reihenfolge, mögliche Fehler, Abstimmung und das Datum oder die Bedingung für ihre Entfernung fest.
Auch für eine historische Datenkopie sind Regeln erforderlich. Lege fest, wie der Anfangsbestand geladen, wie mit gleichzeitigen Änderungen umgegangen und wie das Ergebnis vor dem Wechsel der Datenhoheit überprüft wird. Gehe nicht davon aus, dass ein erfolgreicher Import auch vollständige Beziehungen, abgeleitete Status und Berechtigungen garantiert.
Verhalten vergleichen, ohne Effekte zu duplizieren
Ein Vergleich verringert das Risiko, wenn Berechnung und Ausführung getrennt werden. Eine Möglichkeit besteht darin, eine Kopie der Eingabe an die neue Implementierung im Beobachtungsmodus zu senden und ihre Antwort mit der des aktiven Systems zu vergleichen, ohne dass die Kopie E-Mails versendet, Zahlungen auslöst, den Bestand ändert oder andere externe Effekte aufruft. Diese Ausführung sollte kontrollierte Daten und Abhängigkeiten verwenden oder die Effekte durch Adapter ersetzen, die lediglich die Absicht protokollieren.
Vergleiche die Ergebnisse semantisch: Status, Beträge, Entscheidungen und relevante Fehler, nicht unbedingt die Reihenfolge der Felder oder Zeitstempel. Nutze repräsentative Fälle, die Grenzwerte, unvollständige Daten, Berechtigungen und Abhängigkeitsfehler abdecken. Ergänze automatisierte Tests für kritische Regeln und bewahre anonymisierte oder synthetische Beispiele auf, wenn echte Daten für die Auswertung ungeeignet sind.
Eine Shadow-Ausführung beweist für sich genommen nicht, dass das neue System betriebsfähig ist. Sie bildet möglicherweise Latenzen, Parallelität oder reale Integrationen nicht nach, und eine Abweichung kann sowohl auf einen Fehler als auch auf eine undokumentierte alte Regel hinweisen. Jede Abweichung braucht eine Einordnung, eine verantwortliche Person und eine Lösung: beheben, eine genehmigte Änderung akzeptieren oder den Fall mit einem überprüfbaren Grund ausschließen.
Fortschritt instrumentieren und den Rückweg vorbereiten
Protokolliere den gewählten Pfad, die Implementierungsversion, die Korrelations-ID und das Ergebnis jedes Vorgangs. Miss Fehler, Latenz, Wiederholungsversuche, Synchronisierungsverzögerungen und Abweichungen, aufgeschlüsselt nach Funktion. Vermeide die unnötige Protokollierung von Geheimnissen oder personenbezogenen Daten und lege Zugriffskontrollen sowie Aufbewahrungsfristen für Logs fest.
Vereinbare vor einer Erhöhung des Traffic-Anteils Schwellenwerte für einen Stopp und kläre, wer den Fortschritt anhalten darf. Ein Rollback bedeutet nicht immer, das Routing zurückzustellen: Wenn das neue System bereits Schreibvorgänge angenommen hat, kann der alten Anwendung der neueste Zustand fehlen. Das Verfahren muss festlegen, was mit laufenden Vorgängen, ausstehenden Nachrichten und geschriebenen Daten geschieht; übe es in einer geeigneten Umgebung. Die Umkehrbarkeit hängt vom Zustand und den Effekten ab, nicht nur von einer Konfigurationsoption.
Das alte System anhand überprüfbarer Bedingungen außer Betrieb nehmen
Die Außerbetriebnahme sollte auf Nachweisen beruhen, nicht auf einem einzelnen Datum. Prüfe für eine Funktion, ob alle vorgesehenen Pfade beim neuen Eigentümer ankommen, ob kritische Vorgänge und ihre Fehlerfälle abgedeckt sind, ob Consumer und geplante Aufgaben nicht mehr von der alten Komponente abhängen und ob keine direkten Schreibvorgänge oder Abstimmungsprozesse ohne Verantwortliche zurückbleiben.
Beobachte danach den Betrieb während eines mit Produkt und Operations vereinbarten Zeitraums und berücksichtige dabei die für die Funktion relevanten Lasten und Zyklen. Prüfe ausstehende Daten, Kompatibilitätskopien sowie Audit- und Aufbewahrungsanforderungen, bevor Komponenten entfernt werden. Aktualisiere Dokumentation, Alerts und Supportverfahren. Auch ein altes Modul „für alle Fälle“ weiter zu betreiben, verursacht Kosten: Es kann Berechtigungen, Schwachstellen und Schreibpfade erhalten, die die Zuständigkeiten unklar machen.
Eine praktikable Abfolge lautet: Funktion abgrenzen, Datenhoheit zuweisen, Verhalten dokumentieren, Tests und Observability vorbereiten, Daten laden oder synchronisieren, ohne Nebenwirkungen vergleichen, einen kontrollierten Traffic-Anteil umleiten, Ergebnisse prüfen und Abhängigkeiten mit ausdrücklicher Genehmigung entfernen. Wenn für einen Schritt Akzeptanzkriterien oder Verantwortliche fehlen, ist die Migration noch nicht bereit für den nächsten Schritt.
