Endlich! Nach 3 Jahren Prokrastination habe ich internetzkidz.de zu einem neuen Hoster umgezogen! Hier eine kleine Recap der Journey.
Das Projekt internetzkidz.de ist eigentlich ein simples WordPress-Blog-Projekt, das ich seit 2012 bei ein und dem selben Web-Hoster betrieben habe. Mitlerweile umfasst das Projekt aber 300 Beiträge, 250 Unterseiten und unzählige Media-Files – ganz zu Schweigen von den verschiedenen Anpassungen, die ich im Laufe der letzten 8 Jahre gemacht habe. In weniger als einer Woche (Fr. 10.07. – Mo. 13.07.) habe ich Files, Datenbank und Domain zum neuen Hoster migriert.
In diesem Artikel werde ich ein paar Notizen festhalten in den Kategorien
- Migrieren / Wechseln – Warum?
- Migrationsschritte
- Migrations-feindliche WordPress-Komponenten
- Offene Flanken – Was ich noch nicht im Griff habe!
Server bzw. Hoster wechseln – Warum?
Bereits im Artikel Domain & Hosting der Website Setup Series habe ich angekündigt, dass ich mittelfristig meine Projekte in meinem neuen Webhosting-Projekt konsolidieren möchte. Es macht einfach Sinn ein größeres Paket mit allen Domains und Anwendungen in einem Paket zu nutzen statt diese über verschiedene Hoster zu verteilen und permanent deren Sockel-Kosten für ein Webhosting-Paket zu zahlen. Des Weiteren ist es echt lästig ständig Interfaces und Oberflächen zu wechseln, wenn man Anpassungen an der Server-Konfiguration machen möchte.
Auch wenn mein alter Hoster im Weiteren relativ schlecht wegkommen wird, möchte ich vorweg klarstellen: inernetzkidz.de war mein erstes selber gehostetes Web-Projekt in 2012. Ich war damals noch dumm deutlich dümmer und unerfahren. Ich habe quasi den ersten Hoster genommen der mir ein Webhosting-&-Domain-Paket- für-1-Euro unter die Nase gehalten hat. Erst im Laufe der Entwicklung habe ich dann gelernt, dass Dinge wie DNS-Verwaltung, Hosting-Interface, Speicher-Technologie uvm. wichtig werden könnten.
Wer noch immer Fragen nach dem Warum hat, dem kann ich ja mal den Vergleich unter die Nase halten:
Alter Hoster

- Inklusiv-Domains (.de): 3
- Web-Speicher: 5GB SSD
- Mail-Speicher: 20GB
- Interface: LiveConfig
- Datenbanken: 10
- Preis: 7,99 € pro Monat
Neuer Hoster

- Inklusiv-Domains (.de): 6
- Web-Speicher: 250GB SSD
- Mail-Speicher: 250GB
- Interface: PLESK
- Datenbanken: 25
- Preis: 5,99 € pro Monat
Need I say more …
Darüber hinaus stand auch das Gerücht im Raum, dass greatnet noch 150 weitere Projekte auf der gleichen IP / dem gleichen Server hostet – das geht natürlich aus Performance-Gründen nicht.
Migrationsschritte – Road 2 Glory
Ich möchte hier gar keinen Spannungsbogen aufbauen und kann sagen: Es war eine gute alte, dreckige, lästige manuelle Migration. Der Hauptgrund dafür war, dass DAS WordPress-Migrationsplugin Duplicator keine Lust auf meine Migration hatte. Dazu aber mehr in der Sektion „Migrationsfeindliche WordPress-Komponenten“. Entsprechend bin ich losgezogen und habe die Schritte in folgender Reihenfolge auf mich genommen.
1_ File-Export / Backup
Über Filezilla habe ich via FTP alle WordPress Files runtergezogen, die auf meinem alten Server zu finden waren. In 8 Jahren haben sich dort sagenhafte 2,9GB angesammelt. Eine Menge von Daten, die ultimativ auch die manuelle Migration getriggered hat.

2_ Datenbank Backup my phpMyAdmin
Über das phpMyAdmin Interface ließ sich erstaunlich leicht ein Export meiner SQL-Datenbank erstellen. Diese konnte ich gemeinsam mit meinen Files archivieren.
3_ Anlage einer lokalen Subdomain und Folder-Struktur
Bei meinem neuen Hoster kann ich Subdomains auf Systemdomains zu Testzwecken anlegen. Die haben zwar schäbige Strukturen, aber ich kann live checken, ob mein Endprodukt live erreichbar ist. Das Ganze konnte ich auf den Ordner auf meinem Server zeigen lassen, in dem sich später meine hochgeladenen internetzkidz.de-Files befinden würden. Big Win!
4_ Neue Datenbank für alte Inhalte
Ähnlich wie auch den Datei-Ordner habe ich dann noch eine neue Datenbank angelegt, die auf den Import meiner alten Datenbank gewartet hat.
5_ Upload / Import von Dateien und Datenbank
Passend zum vorherigen Export von Dateien und Datenbank-Inhalten, habe ich dann alles in die neuen Strukturen hochgeladen. Die WordPress-Dateien via FTP-Client und die Datenbank-Inhalte via phpMyAdmin-Interface.

6_ Datenbank-Verknüpfung via wp-config.php
Die Hochzeit zwischen WordPress-Files und -Datenbank findet dann in der wp-config.php auf dem Server statt. Hier musste ich schnell den neuen Datenbanknamen, -Server, -Benutzer und -Passwort hinterlegen in den Values für
- DB_NAME
- DB_USER
- DB_PASSWORD
- DB_HOST
und alles ist wieder miteinander Verknüpft: Content, Software und Files.
7_ Datenbank URL-Rewrite-Fun
Damit mein Projekt dann tatsächlich unter meiner Test-Domain internetzkidz.hosting*****.****.netcup.net verfügbar war, musste ich WordPress noch beibringen, wo das neue Homeverzeichnis zu finden war. Die Domain internetzkidz.de zeigte ja noch auf die alte Server-IP und deren Inhalte. Wenn ich also die Stamm-URL ändere, weiß WordPress auch, dass er relative URLs wie z.B. /impressum an diesen neuen Stamm hängen muss. Das gilt leider nicht für Links innerhalb von Blogbeiträgen und Seiten. Diese sind leider in den meisten Fällen statisch im HTML hinterlegt. Das macht aber nichts, weil die alte Domain nach Umzug ja wieder auf den neuen Server zeigen wird.
Glücklicherweise reicht es meistens aus, in der Datenbank die beiden Einträge für
- siteurl
- home
in der _options Tabelle der Datenbank anzupassen, um grundlegende Erreichbarkeit wiederherzustellen. Damit konnte ich dann die Startseite (/) und das Admin-Dashboard (/wp-login.php und /wp-admin) wieder erreichen. Das war für einen Funktionstest ausreichend.

8_ Domain-Transfer initiieren
Theoretisch hätte ich nun die DNS-Konfiguration der Domain internetzkidz.de bei meinem alten Hoster so umstellen können, dass nach ein paar Stunden jeder Zugriff auf internetzkidz.de auf den neuen Server geroutet wird. Zwei Probleme dabei:
a) Mein alter Hoster ließ mich diese Konfiguration nicht selber vornehmen, sondern nur über eine Anfrage via Kontaktformular.
b) Ich wollte meine geliebte Domain nicht in der Verwaltung eines Anbieters lassen, der mir 7,99€ pro Monat für 5GB Webspace abknüpft.
Entsprechend habe ich schnell den Entschluss gefasst, die Domain direkt mit zu netcup zu migrieren. Das hat mich zwar auch eine Anfrage via Kontaktformular bei greatnet und ein fieses .pdf gekostet, aber so löse ich das Problem wenigstens ein für alle Male. Der Kündigung+Transfer-Workflow hat 3 Tage gedauert. Das ist nicht schnell wenn man die Migration End2End schnell durchführen möchte, aber deutlich schneller als erwartet.

9_ Domain-Transfer via Auth Code
Die Entgegennahme der Domain auf netcup-Seite war dann super easy. Über das Bestellen-Interface in der Domain-Übersicht wurde ich dann aufgefordert, den Auth Code zu hinterlegen, den mir greatnet zuvor hatte zukommen lassen. Bang! Domain steht im customercontrolpanel zur Verwaltung bereit.

10_ Domain-Einrichtung auf netcup Seite
Wie bei jeder neuen-alten Domain musste ich diese dann noch in meinem Interface einrichten. Dazu zählt z.B. die Bestellung eines Let’s Encrypt SSL-Zertifikats für die Domain und die Definition des des Server-Ordners, die die Domain in Zukunft referenzieren sollte. In dem Fall sehr simpel: /internetzkidz/
11_ Home-URL Re-Re-Write in der Datenbank
Den URL-Rewrite-Spaß, den ich mir Schritt 7 im phpMyAdmin Interface gemacht habe, musste ich nun also wieder rückgängig machen. Kurz die Datenbankfelder für siteurl und home auf https://internetzkidz.de zurückgeändert und WordPress wusst wieder wie es URLs generieren muss und wo alles zu finden ist.

12_ Done! Willkommen auf dem neuen Hoster
Das war es auch schon. Dadurch, dass ich direkt online war als mich die Mail für den Domaintransfer erreicht hat, war die Website innerhalb von einer Stunde auf dem neuen Server erreichbar. Zwischenfälle gab es natürlich, diese habe ich zum Zweck dieses Walkthroughs aber ausgelassen und werde ich in der nächsten Sektion kurz bearbeiten.
Einen kleinen Workaround für die Validierung des Umzugs musste ich jedoch noch machen. Da ich die Inhalte von internetzkidz.de bis dahin auf beiden Servern auf einem identischen Stand gehalten habe, musste ich noch schnell einen neuen Beitrag auf die Startseite bekommen, um zu wissen, dass die Domain auf den richtigen Server zeigt. Dadurch ist der Content-schwache Beitrag Migration abgeschlossen! Willkommen beim neuen Hoster jetzt Teil des Blogs. Als ich den Teaser zum Artikel auf der Startseite gesehen habe, wusste ich also: Alles hat geklappt!

Migrationsfeindliche WordPress Komponenten
Natürlich habe ich im Vorfeld der Migration diverse Blogartikel und Foren-Beiträge zu dem Thema durchforstet, um auf verschiedene Eventualitäten bei der Migration vorbereitet zu sein. Trotzdem war ich mir sicher, dass es klappen würde. Immerhin sind 30% des Internets WordPress-Sites, von denen womöglich jeden Tag tausende migriert werden. Entsprechend war ich überrascht, dass einige Plugins sich etwas quer gestellt haben im Laufe des Prozesses. Namentlich waren das:
- Duplicator Plugin
- Yoast SEO
- W3 Total Cache
Ich erkläre auch kurz warum:
Duplicator WordPress Migrationsplugin
Eigentlich wollte ich die Migration mit dem Duplicator Plugin durchziehen, weil es im Web einen guten Ruf für genau diesen Zweck genießt. Das Plugin hat mir aber bereits bei dem Versuch ein Archiv meiner Site zu erstellen den Hinweis gegeben, dass das aufgrund der Größe meiner Site (fast 3GB) und den Konfigurationen meines Hosters (fair!) nicht möglich sei. Diese Meldung war für mich in Ordnung und verständlich – wenn auch ärgerlich. Ich habe die Archivierung abgebrochen und bin losgelaufen und habe manuelle Exporte gezogen.
Was mich dann aber angepisst hat war, dass Duplicator trotzdem ohne mein Wissen losgelaufen ist und versucht hat, ein Archiv zu erstellen! Das habe ich aber erst am Ende des Tages gesehen. Der Fortschritt lag da bei 59%! Das hat zu zwei Problemen geführt:
- Ich habe Teile des unfertigen Archivs in mein manuelles Backup kopiert.
- Das Plugin hat den ganzen Tag Last auf meinem alten Server verursacht, was womöglich zu Ausfällen beim User geführt hat.
Das fand ich entsprechend nicht so geil von DEM Migration-Plugin auf dem Markt.
Yoast SEO leitet munter weiter
Ein großer Teil meiner Migrationsbemühungen war es, meine WordPress-Kopie im netcup-Environment auf meiner Test-Domain internetzkidz.hosting******.****.netcup.net erreichbar zu bekommen. Für bestimmt zwei Stunden hat irgendeine Komponente diese Erreichbarkeit aber blockiert, weil jede Anwahl der Subdomain zu einem direkten Redirect auf die alte internetzkidz.de Domain geführt hat. Meine Suchen haben mich in die tiefen meiner Installation geführt:
- functions.php
- wp-config.php
- Datenbank-Einträge Rewrites
- etc.
Erst als ich das Yoast Plugin auf dem Server disabled habe, hörte die lästige Weiterleitung auf!
Ich habe das neue Yoast Indexierungsfeature in Verdacht, dass hier in irgendeiner Form gecachte Sites und Redirects aufrecht erhält! Beweisen kann ich das aber nicht. Ich war einfach nur happy, dass ich eine Lösung gefunden hatte. Den Umzug musste ich komplett mit deaktiviertem Yoast Plugin machen und danach musste ich Yoast einmal komplett deinstallieren und wieder installieren ehe es im neuen Environment funktioniert hat. Klassischer IT-Sysadmin-Move, aber jetzt läuft es halt wieder.
W3 Total Cache mag keine neuen Server
Keine Überraschung aber definitiv ein Learning: W3 Total Cache hat bei Migration auch Probleme verursacht. Das finde ich akzeptabel, weil der Job des Plugins die Auslieferung von alten gespeicherten Versionen meiner Website ist. Da arbeitet man verständlicher Weise nicht gut in neuen Umgebungen. Auch dieses Plugin lief aber nach einer neuen Installation wie WordPress Backend wieder einwandfrei. Sogar mit allen alten Konfigurationen!
Kleine Nacharbeiten und Crowd-Testing
Noch nicht alles läuft rund auf meinem alten Projekt – ich weiß! Zum Beispiel habe ich ein Problem mit der Auflösung von Media-URLs, die Umlaute enthalten. Das regel ich noch! Solltet ihr aber Probleme mit der Seite entdecken, sagt mir kurz Bescheid via internetzkidz.de/kontakt oder meinen Socials im Footer!
Vielen Dank im Voraus.