Webspace-Migration von Strato zu All-Inkl

Auch wenn meine Migration einiger bestehender Webseiten von Strato zum Anbieter All-Inkl bereits einige Monate zurückliegt, folgt hier noch ein Artikel, der vielleicht anderen zukünftigen Ex-Strato-Kunden hilft.

Kurz die meiner Meinung nach größten Vorteile von All-Inkl im Vergleich zu Strato:

1. Man kann seine Domains auch bei einem anderen günstigeren Domain-Anbieter (z.B. Tecspace) registrieren und per DNS-Eintrag über den All-Inkl-Webspace laufen lassen. Das heißt, man kann trotz Ausschöpfen der Inklusiv-Domains beliebig weitere Domains von extern „aufschalten“.

2. In Zeiten, in denen Webseiten ohne SSL von Google abgestraft werden, ist der baldige Gebrauch eines SSL-Zertifikats unumgänglich. Bei All-Inkl kann man hier auf die kostenfreien Zertifikate von „Let’s Encrypt“ zurückgreifen! Diese werden sogar bei drohendem Ablauf automatisch erneuert. Bei Strato ist mittlerweile, soweit ich gesehen habe, nur ein SSL-Zertifikat pro Account inklusive und es ist nicht geplant für die Hosting-Pakete „Let’s Encrypt“ zu integrieren.

3. Es gibt mehr Inklusiv-Domains in den All-Inkl-Paketen. Beim Speicherplatz hat Strato mittlerweile nachgezogen, aber um ehrlich zu sein, ist es bei der Größenordnung der meisten privaten Webprojekte eher nebensächlich, ob man nun 100 oder 125 GB Webspace hat. Es sei denn, man möchte 4K-Videos auf seinem Webspace lagern.

4. Es gibt recht hohe Rabatte, wenn man für eine längere Laufzeit im Voraus bezahlt und 3 Monate sind sowieso kostenfrei zum Testen.

Der bisher einzige Nachteil, der aber nicht wirklich dramatisch ist, ist der in meinem All-Inkl-Paket fehlende SSH-Zugang. Aber bisher habe ich den auch gar nicht vermisst. Zumal man diesen, wenn man ihn unbedingt benötigt, in einem teureren Paket haben kann.

Hier sind meine Tipps für eine reibungslose Migration, damit der Wechsel möglichst ohne Downtime für die Seitenbesucher über die Bühne geht.

1. Den All-Inkl Account ca. 1 Woche vor Ablauf des Strato-Accounts erstellen. Hier reicht sogar erst einmal der kostenfreie Test-Account!

2. Die Webseiten und auch Mail-Konten auf All-Inkl im KAS einrichten, hierauf gehe ich nicht näher ein. Die eventuell vorhandenen Datenbanken und die ganzen Dateien müssen dann ebenfalls von Strato zu All-Inkl kopiert werden.

Wenn es sich um eine Seite handelt, bei der kein dynamischer Content durch externe User generiert wird hat man keine Probleme. Bei einer Seite auf der z.B. viele Kommentare geschrieben werden fehlen natürlich dann ab diesem Zeitpunkt erstellte Kommentare in der All-Inkl-Kopie. Wenn einem diese wichtig sind, sollte man entsprechende Funktionen eventuell mit einer vorübergehenden Info für die Besucher deaktivieren.

3. Nun kommt meine Lieblingsmethode um zu testen, ob die Webseiten auf dem neuen Webspace bei All-Inkl auch wirklich im kompletten Funktionsumfang funktionieren. Wenn die Webseite z.B. mit WordPress oder einem anderen CMS läuft, ist ein vernünftiger Test nur möglich, wenn die Seite unter Ihrer eigentlichen Web-Adresse aufgerufen wird.

Es gibt zwar eine vorübergehende Test-Domain bei All-Inkl, aber da die Seite ja noch bei Strato liegt, ist diese als Test unbrauchbar. Denn eventuell fehlende Ressourcen werden aufgrund ihrer Verlinkung noch vom Strato-Webspace geladen.

Deshalb ändert man nun die Windows-Hosts-Datei ab. Diese befindet sich unter „C:\Windows\System32\drivers\etc“ und nennt sich „hosts“. Diese muss als Administrator geöffnet werden, sonst kann man sie nicht speichern. Je nach Anti-Viren-Programm muss man auch kurz den Echtzeitschutz deaktivieren. Sonst blockt z.B. AntiVir einen Änderungsversuch an dieser Datei ab.

In meinem Fall habe ich aus dem All-Inkl-Backend die IP-Adresse genommen …

… und in der Hosts-Datei wie folgt eingetragen:

Dieser Eintrag sorgt nun dafür, dass alle Anfragen vom eigenen Rechner an die angegebene Domain, in diesem Fall devilatwork.de, an die hinterlegte IP-Adresse geleitet werden. Unabhängig davon, dass die Seite noch bei Strato liegt und von anderen Besuchern auch weiterhin vom Strato-Server abgerufen wird.

Wenn es noch Fehler gibt, können diese nun problemlos im Vorfeld abgeklärt werden und es erwarten einen beim finalen Providerwechsel keine all zu bösen Überraschungen! Man sollte sich aber eine Erinnerung schreiben um nicht zu vergessen den Host-Eintrag wieder zu löschen.

Ich fand bei meinen Projekten beispielsweise noch folgende Stolpersteine:

Sitemap-Umleitung

Bei All-Inkl scheint der Aufruf der URL „domain.de/sitemap“ automatisch auf die Datei „sitemap.xml“ weiterzuleiten. Deshalb musste ich für ein Webprojekt die Seite sitemap bzw. den Link umbenennen, da ich diese Seite für eine schöne Übersichtsseite aller Unterseiten für den Seitenbesucher und nicht für die Suchmaschinen vorgesehen hatte.

GZip-Komprimierung

Die GZip-Komprimierung muss bei All-Inkl etwas „ausführlicher“ als bei Strato aktiviert werden:

Bei Strato sah das nur so aus:

RewriteRules

Meine RewriteRule, um alle Anfragen auf die www-Subdomain umzuleiten, funktionierte bei All-Inkl nicht mehr und musste wie folgt konfiguriert werden:

Bei Strato sah das so ungefähr aus:

Für den Fall, dass man bei der Erstellung einer .htaccess für All-Inkl Hilfe benötigt, gibt es einen ganz guten .htaccess-Generator auf deren Website.

4. Eventuell macht es Sinn bei Strato die E-Mails schon an den All-Inkl-Serer weiterzuleiten wenn man viele E-Mails bekommt. Ich habe dies unterlassen. Hierzu müsste man den MX-Eintrag anpassen. Aufjedenfall sollte man aber, wenn man IMAP nutzt, schon einmal ein Backup der vorhandenen Mails machen!

5. Nun ist es Zeit sich von Strato zu verabschieden. Spätestens jetzt fordert man die AuthCodes von Strato an und stößt mit ihnen den Transfer der Domains beim neuen Hoster an. Um eine Downtime möglichst zu umgehen, lässt man die Daten der Webseite während des Transfers bei Strato noch auf dem Webspace liegen. Dadurch werden Anfragen an den alten Webserver von Strato auch noch korrekt bedient bis die Verbreitung des neuen DNS-Eintrags durch ist.

WICHTIG:

Ich hatte eigentlich geplant, vor dem eigentlichen Domain-Transfer, mittels A-Record die Seite schon über den All-Inkl-Server laufen zu lassen und dachte, dass bei Anfragen, die sich noch an den Strato-Server „verirren“ die Seite dann von Strato noch ausgeliefert wird. So wie es eigentlich auch üblich sein sollte. Bei Test-Domains die bei Tecspace liegen und dort per A-Record von Bplaced zu All-Inkl verschoben wurden lief dies ohne Probleme.

Bei Strato ist dies leider nicht der Fall! Sobald man den A-Record bei Strato auf einen externen Anbieter setzt, ist die Seite bei Strato in der Serverkonfiguration „gelöscht“ und der Webserver von Strato gibt einen 410-Error aus! Laut Strato kann es dann bis zu 48 Stunden dauern bis der neue A-Record durch ist. Unfassbar! Zum Glück hatte ich dies nur bei einem Testprojekt so versucht. Wenn man dazu mal googlet, findet man heraus, dass dies schon seit Ewigkeiten so ist.

Quellen und hilfreiche Links:
https://www.justusbluemer.de/blog/bei-all-inkl-com-domains-aufschalten
https://www.justusbluemer.de/blog/gzip-komprimierung-bei-all-inkl-com-aktivieren
https://blog.milsystems.de/2011/06/wie-richte-ich-eine-externe-domain-bei-all-inkl-com-ein