Managed Server oder getrennte Cloud-Dienste?
Ein Wartungsproblem, höhere Lastspitzen oder die Vorgaben einer Konzern-IT führen zu unterschiedlichen Zielarchitekturen. Manchmal genügt ein betreuter Server. In anderen Fällen sind getrennte Dienste für Anwendung, Datenbank und Dateien sinnvoll. Kubernetes ist dabei eine mögliche Betriebsplattform, keine Voraussetzung für TYPO3.
Vor der Auswahl erfassen wir Core- und PHP-Version, Extensions, Composer-Abhängigkeiten, Dateispeicher, Datenbank und externe Anbindungen. Dazu kommen Aufgaben, die im Alltag leicht übersehen werden: zeitgesteuerte Importe, PDF-Erzeugung, Suchindizes, Bildverarbeitung und Mailversand.
Code ist austauschbar. Redaktionsdaten sind es nicht.
Ein neues Release kann aus dem Repository gebaut werden. Hochgeladene Bilder und die aktuelle Datenbank dagegen dürfen beim Austausch der Anwendung nicht verschwinden. Deshalb werden Code, Konfiguration, Zugangsdaten und veränderliche Daten getrennt behandelt.
Laufen mehrere Anwendungsinstanzen parallel, müssen sie dieselben maßgeblichen Inhalte und Dateien sehen. Ein Upload, der nur auf einem einzelnen Container liegt, wäre nach dessen Austausch weg oder von einer anderen Instanz nicht erreichbar. Gemeinsamer Dateispeicher beziehungsweise eine geeignete Storage-Anbindung ist deshalb eine Architekturentscheidung.
Scheduler, Suche, Uploads und E-Mail prüfen
Diese Funktionen prüfen wir in der neuen Umgebung mit vorhandenen Daten und den vorgesehenen Benutzerrollen:
- Scheduler und Hintergrundaufgaben
- Welche Aufgaben laufen wann? Wer führt sie aus? Bei mehreren Instanzen muss verhindert werden, dass ein Import versehentlich doppelt startet.
- Suche, Cache und Sessions
- Suchindizes müssen aufgebaut werden. Cache-Konfiguration und angemeldete Benutzer müssen auch dann funktionieren, wenn Anfragen auf verschiedene Instanzen verteilt werden.
- Dateien, Bilder und Dokumente
- Uploads, Dateirechte, Bildverarbeitung und eigene PDF-Funktionen werden mit echten Beispielen geprüft – nicht nur mit einer leeren Testinstallation.
- Schnittstellen und E-Mail
- Ausgehende Verbindungen, IP-Freigaben, Zertifikate und Mailzustellung können sich ändern. Ein erfolgreich abgesendetes Formular ist erst dann vollständig geprüft, wenn die Nachricht am vorgesehenen Ziel ankommt.
Den Wechsel vorher einmal durchspielen
Eine Testmigration zeigt, wie lange Datenübernahme und Nacharbeiten tatsächlich dauern. Für den Produktivwechsel legen wir fest, wann die Redaktion pausiert, welche Daten zuletzt synchronisiert werden und wie DNS, Zertifikate und Weiterleitungen umgestellt werden.
Eine CI/CD-Pipeline baut und testet ein versioniertes Release. Der auf Staging geprüfte Build wird nach Freigabe unverändert in Produktion ausgerollt, bei containerbasiertem Hosting als Container-Image. Datenbankmigrationen brauchen einen eigenen Ablauf: Der Rückwechsel auf eine frühere Anwendungsversion setzt Daten und Datenbankstruktur nicht automatisch zurück. Wir prüfen deshalb vorab, ob der vorherige Code mit dem geänderten Datenstand funktioniert, und erproben den Rückfallplan.
Monitoring, Updates und Wiederherstellung
Wer reagiert auf einen Alarm? Wer aktualisiert PHP und Extensions? Wie werden Backups gesichert und Wiederherstellungen erprobt? Diese Zuständigkeiten werden zwischen Unternehmen, Entwicklung und Hostingpartner festgelegt.
Zur Abnahme gehören außerdem Weiterleitungen, Suchmaschinenzugriff, Antwortzeiten und zentrale Benutzerabläufe. Wir vergleichen diese mit dem Ausgangszustand. Erst dann lässt sich beurteilen, ob der Umzug sein Ziel erreicht hat – und nicht bloß die Adresse des Servers geändert wurde.
Uploads müssen Instanzwechsel überstehen, Hintergrundaufgaben dürfen nicht doppelt laufen und ein Rückfall muss Datenbank und Code berücksichtigen. Diese Abhängigkeiten bestimmen die Cloud-Migration.