Nicht, dass ich nicht auch versucht hätte, die etwa 80GB große Multisite-Umgebung mit Hilfe eines Plugins auf einen anderen Server unter neuen Domains zu migrieren… Ab einer bestimmten Größenordnung kann man sich auf die gängigen Lösungen allerdings nicht mehr unbedingt verlassen. – Updraftplus wollte die alte Adresse einer Subsite durch die neue Hauptdomain ersetzen (sonst nichts…? – ich brach ab, als ich das sah), und die Archivdatei von duplicatorpro muss wohl auf ihren Reisen was abbgekommen haben, denn die war offenbar defekt, und die Installation ließ sich gar nicht erst starten.

Übertragung der Dateien (z.B. via FTP)

Potentiell könnte man über eine SSH-Shell (WP CLI wäre nochmal besser) beim alten Server die Dateien via FTP-Zugang vom neuen Server übertragen. Bevor sich das einer antut, lohnt es sich allerdings, die Tools des (neuen) Hosters zu erforschen. Bei All-inkl.com kann man sowohl Dateien als auch Daten vom früheren Hoster direkt auf den Server holen, und sich damit den Umweg über den eigenen Rechner sparen.

Ansonsten halt Dateien via FTP (schneller Internetzugang von Vorteil) holen, auf dem lokalen Rechner zwischenspeichern (den Schritt konnte ich mir annähernd sparen, da ich die meisten Dateien auch auf dem lokalen Webserver hatte, der meine Entwicklungsumgebung war). Bei weit mehr als 100.000 Einzeldateien kann sich das ziehen. Und dann kommt ja noch der Upload… Nunja, auch Backup Files muss man irgendwie übertragen, und auch das zieht sich, auch wenn eine große Datei natürlich schneller ihren Weg findet, als viele 1000 kleine.

Gehen wir davon aus, alle Dateien sind bereits an ihrem Bestimmungsort, die wp-config.php hat bereits die aktuellen MySQL-Zugangsdaten drin, und es ist auch bereits die korrekte Hauptdomain in der Multsite-Konfiguration eingetragen.

Vom alten Server wird nun die Datenbank via phpMyAdmin exportiert, und in die neue Datenbank importiert (was ab einer bestimmten Größe vielleicht auch SSH-Zugang erfordert, z.B. wer zu webgo migriert, kann den phpMyAdmin dafür vergessen, und findet auch kein Tool dafür, wie All-inkl.com für die DB-Migration bereithält).

Damit man nun überhaupt eine der neuen Adressen aufrufen kann, ist der Austausch folgender URLs in der Datenbank erforderlich:

Hauptsite-Tabellen

$prefix_site – neue Haupt-Domain eintragen
$prefix_blogs – dort alle Blog-Domains durch die neuen Adressen ersetzen

Alle Options-Tabellen (Haupt- und Subsites)

$prefix_option, $prefix_2_options… (für jede Site) – jeweils die siteurl und home mit der neuen URL überschreiben.

Damit sollte der Anmeldung auf der neuen Hauptdomain nichts mehr im Wege stehen. Doch nun müssen sämtliche Links in der Datenbank mit Hilfe eines Suchen und Ersetzen Tools ausgetauscht werden. Das erfordert ein wenig Geduld, Geschick und günstigerweise auch schon Erfahrungen damit. – Bei solchen Gelegenheiten komme ich immer wieder drauf, dass WordPress-User Sites usprünglich unter anderen (oft von Hostern bereitsgestellten) Adressen installiert und dann nicht sauber migriert hatten. So lange man damit den Hoster nicht wechselt, merkt man oft nichts davon, wenn Bilder von einer Adresse geholt werden, die dort auch noch exisitert.

Plugins, die Ersetzungen auch in serialisierten Daten korrekt vornehmen:

https://wordpress.org/plugins/better-search-replace/
https://wordpress.org/plugins/search-regex/

Alle Domains haben bereits SSL/TLS aktiviert? – Dann sollte ein Suchen und Ersetzendurchlauf pro alter/neuer Domain reichen.

Es können nämlich auch Speicherungen in der Form vorkommen: https%3A%2F%2Fdomain.meine oder https:\/\/domain.meine… – Das würde weitere Ersetzungen erfordern, wenn z.B. von http auf https gewechselt wird.

Auch ersetzt werden sollte der Serverpfad (z.B. /www/htdocs/kunde/projekt/), den findet man in den WordPress Tools, Website-Zustand im Tab Bericht, unter WordPress-Konstanten (sowohl unter der alten, als auch der neuen Adresse, und er gilt für die gesamte Installation). Mithin wird der Pfad in Einstellungen mit gespeichert, oder kommt auch mal in der post_meta-Tabelle vor.

Block CSS-Dateien im Frontend luden nicht mehr

Das hatte ich also alles gemacht, aufwendige Website, komplexes Design, alles da, Links passten… doch ich blickte auf eine einzige Layoutkatastrophe. Nachdem ich via Console ein paar CSS-Vergleiche alte Site neue Site anstellte, war klar, was hier schief lief. Im Frontend fehlten die Block-CSS-Dateien.

Noch ein, und nicht unbedingt der letzte erforderliche Schritt

Es war abschließend noch erforderlich, Transienten aus den Options-Tables zu löschen. Das sind jene, die unter dem Präfix _transient_ zu finden sind. Dabei handelt es sich um meist in festgelegten Abständen generierte, temporäre Einstellungen, die im Bedarfsfall neu angelegt werden.