TYPO3 in die Cloud: Was beim Umzug mitziehen muss.

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. Eine leere Testinstallation reicht dafür nicht aus.

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.

Ein automatisierter Ablauf, die CI/CD-Pipeline, erstellt aus dem Quellcode eine eindeutig versionierte Fassung der Anwendung und führt Tests aus. Diese Fassung wird auf einer getrennten Testumgebung (Staging) geprüft und nach Freigabe unverändert veröffentlicht. Bei containerbasiertem Hosting wird sie dafür als Container-Image verpackt. Änderungen an der Datenbank planen wir gesondert: Eine Rückkehr zum vorherigen Code setzt Daten und Datenbankstruktur nicht automatisch zurück. Im Rückfallplan halten wir fest, wie sich der vorherige Stand wiederherstellen lässt, und erproben diesen Ablauf.

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 sich durch den Umzug die gewünschten Verbesserungen ergeben haben.