Website umziehen – Hoster wechseln ohne Ausfallzeit

Kurz gesagt: Ein Hoster-Wechsel ist sinnvoll, wenn Ihr Anbieter dauerhaft langsame Antwortzeiten liefert, keine aktuellen PHP-Versionen anbietet, wiederholt ausfällt oder die Preise ohne Mehrwert deutlich erhöht. Ein einzelner Vorfall ist dagegen kein Wechselgrund.

Nicht jedes Problem mit der Website rechtfertigt einen Hoster-Wechsel. Ein einmaliger Serverausfall, ein kurzer Support-Engpass oder ein vorübergehendes Performance-Problem sind normal und kein Grund zur Panik. Wenn sich bestimmte Probleme aber häufen, wird es Zeit, über einen Wechsel nachzudenken.

Typische Gründe, die für einen Hoster-Wechsel sprechen:

• Dauerhaft langsame Ladezeiten: Wenn Ihre Website trotz Optimierung langsam lädt und der Server regelmäßig hohe Antwortzeiten liefert, liegt das Problem oft beim Hosting. Shared-Hosting-Pakete mit hunderten Websites auf einem Server sind hier besonders anfällig.
• Schlechter oder nicht erreichbarer Support: Wenn der Hoster auf Anfragen tagelang nicht reagiert oder nur standardisierte Textbausteine liefert, fehlt Ihnen im Ernstfall die Unterstützung. Guter Support ist bei Hosting-Problemen entscheidend.
• Steigende Preise ohne Mehrwert: Viele Hoster locken mit günstigen Einstiegspreisen und erhöhen die Kosten nach der Erstlaufzeit deutlich. Wenn Sie für das gleiche Paket plötzlich das Doppelte zahlen, lohnt sich ein Vergleich.
• Veraltete Technologie: Ihr Hoster bietet keine aktuelle PHP-Version (aktuell empfohlen: PHP 8.5), keinen SSH-Zugang, kein kostenloses SSL-Zertifikat oder keine HTTP/2-Unterstützung? Dann bremst er Ihre Website technisch aus.
• Fehlende Features: Kein Staging-Bereich, keine automatischen Backups, kein SSH-Zugang oder keine Möglichkeit, Cronjobs einzurichten – je nach Ihren Anforderungen können fehlende Funktionen den Wechsel notwendig machen.
• Häufige Ausfälle: Wenn Ihre Website regelmäßig nicht erreichbar ist, schadet das nicht nur Ihren Besuchern, sondern auch Ihrem Google-Ranking. Eine Uptime von mindestens 99,9 % sollte Standard sein.

Wann ein Wechsel NICHT sinnvoll ist: Eine einmalige Störung, ein einzelner schlechter Support-Kontakt oder ein kurzer Geschwindigkeitseinbruch sind kein Grund für einen sofortigen Hoster-Wechsel. Prüfen Sie zunächst, ob das Problem an Ihrer Website selbst liegt – etwa durch nicht optimierte Bilder, zu viele Plugins oder fehlerhaften Code. Erst wenn sich die Probleme über Wochen hinziehen und der Hoster keine Lösung bietet, sollten Sie die Website umziehen.

Vor dem Umzug brauchen Sie drei Dinge: ein vollständiges Backup (Dateien, Datenbank, E-Mails), ein fertig eingerichtetes neues Hosting-Paket und einen rechtzeitig gesenkten TTL-Wert. Der alte Vertrag bleibt bestehen, bis der neue Server bewiesen hat, dass er zuverlässig läuft.

Die Vorbereitung ist der wichtigste Teil beim Website umziehen. Wer hier sorgfältig arbeitet, vermeidet Datenverlust und minimiert die Ausfallzeit auf ein Minimum. Ich empfehle Ihnen, diese Schritte mindestens eine Woche vor dem geplanten Umzug zu beginnen.

1. Vertragslaufzeiten prüfen – alten Vertrag NICHT voreilig kündigen! Prüfen Sie zuerst die Kündigungsfristen bei Ihrem bisherigen Hoster. Der häufigste Fehler beim Hoster wechseln: Den alten Vertrag kündigen, bevor der neue Server eingerichtet und getestet ist. Lassen Sie den alten Vertrag mindestens zwei bis vier Wochen parallel zum neuen weiterlaufen. So haben Sie ein Sicherheitsnetz, falls beim Umzug etwas schiefgeht.

2. Neues Hosting-Paket buchen und einrichten. Buchen Sie das neue Hosting-Paket und richten Sie die Grundkonfiguration ein: PHP-Version einstellen (empfohlen: PHP 8.5), Datenbank anlegen, FTP/SFTP-Zugang einrichten. Notieren Sie sich alle Zugangsdaten sorgfältig – Sie brauchen sie im nächsten Schritt.

3. Vollständiges Backup erstellen. Sichern Sie alles – wirklich alles. Dazu gehören: sämtliche Dateien Ihres Webspaces (HTML, PHP, Bilder, Konfigurationsdateien), die komplette Datenbank (SQL-Export) und alle E-Mail-Postfächer, die auf dem Hosting-Server liegen. Eine ausführliche Anleitung zur Backup-Erstellung finden Sie in meinem Artikel Website-Backup erstellen. Speichern Sie das Backup zusätzlich auf Ihrem lokalen Rechner oder einem Cloud-Speicher – niemals nur auf dem alten Server.

4. TTL-Wert auf Minimum setzen (24-48 Stunden vorher!). Dieser Schritt wird oft vergessen, ist aber entscheidend für eine schnelle Umstellung. Der TTL-Wert (Time to Live) bestimmt, wie lange DNS-Server die Zuordnung Ihrer Domain zur Server-IP zwischenspeichern. Standard-TTL-Werte liegen bei 3.600 bis 86.400 Sekunden (1 bis 24 Stunden). Senken Sie den TTL-Wert Ihrer A-Records und MX-Records auf 300 bis 600 Sekunden (5 bis 10 Minuten) – und zwar mindestens 24 bis 48 Stunden, bevor Sie die DNS-Einstellungen ändern. Warum so früh? Weil der alte TTL-Wert erst ablaufen muss, bevor der neue wirksam wird. Wenn Ihr aktueller TTL bei 86.400 Sekunden liegt (24 Stunden), müssen DNS-Server weltweit erst diese 24 Stunden abwarten, bevor sie den neuen, kürzeren TTL-Wert akzeptieren.

5. Auth-Code für den Domain-Umzug anfordern. Wenn Sie auch die Domain umziehen und zum neuen Provider übertragen möchten, brauchen Sie einen Auth-Code (auch AuthInfo oder Transfer-Code genannt). Bei .de-Domains läuft der Prozess über die DENIC: Sie beauftragen Ihren aktuellen Provider, einen Auth-Code zu generieren. Der Provider übermittelt den verschlüsselten Code an die DENIC und teilt Ihnen den Code mit. Sie geben den Auth-Code beim neuen Provider ein, der damit den Transfer bei der DENIC beantragt. Stimmt der Code überein, wird die Domain sofort übertragen. Der Auth-Code ist 30 Tage gültig und muss danach neu beantragt werden. Reagiert der alte Provider nicht, kann Ihr neuer Provider bei der DENIC einen AuthInfo-Code beantragen. Die DENIC sendet diesen Code dann per Einschreiben an die hinterlegte Adresse des Domaininhabers. Beachten Sie: Für das AuthInfo-Verfahren können je nach Provider Gebühren anfallen.

6. Zugangsdaten dokumentieren. Bevor Sie mit der eigentlichen Migration beginnen, sammeln Sie alle Zugangsdaten an einem sicheren Ort: FTP/SFTP-Zugangsdaten (alter und neuer Server), Datenbank-Zugangsdaten (Host, Benutzername, Passwort, Datenbankname), Hosting-Panel-Login (cPanel, Plesk oder proprietäres Panel), CMS-Administrator-Login, Domain-Registrar-Login und E-Mail-Kontodaten. Ein Passwort-Manager wie Bitwarden oder KeePass ist hier sehr empfehlenswert.

Der eigentliche Umzug besteht aus fünf Schritten: Dateien per SFTP übertragen, Datenbank exportieren und importieren, Konfiguration anpassen, CMS-spezifische Einstellungen prüfen und die Website auf dem neuen Server testen – noch bevor die DNS umgestellt wird.

Jetzt wird es konkret: Sie wollen den Server wechseln und Ihre Website auf den neuen Hoster übertragen. Nehmen Sie sich für diesen Schritt ausreichend Zeit und arbeiten Sie konzentriert – Fehler bei der Datenübertragung können später schwer zu finden sein.

Schritt 1: Dateien übertragen. Verbinden Sie sich per SFTP (nicht FTP – SFTP verschlüsselt die Übertragung!) mit Ihrem alten Server und laden Sie den kompletten Webspace auf Ihren lokalen Rechner herunter. Anschließend laden Sie alle Dateien auf den neuen Server hoch. Nutzen Sie dafür ein Programm wie FileZilla, WinSCP oder Cyberduck. Bei größeren Websites mit vielen Dateien kann der Upload mehrere Stunden dauern – planen Sie das ein. Alternativ bieten manche Hoster SSH-Zugang an: Mit dem Kommandozeilenbefehl rsync oder scp übertragen Sie Dateien direkt von Server zu Server – deutlich schneller als der Umweg über Ihren lokalen Rechner.

Schritt 2: Datenbank exportieren und importieren. Öffnen Sie phpMyAdmin (oder ein vergleichbares Tool wie Adminer) auf dem alten Server und exportieren Sie die komplette Datenbank als SQL-Datei. Wählen Sie dabei das Format "SQL" und die Komprimierung "gzip" bei größeren Datenbanken. Erstellen Sie auf dem neuen Server eine leere Datenbank und importieren Sie die SQL-Datei über phpMyAdmin. Bei großen Datenbanken (über 50 MB) kann es vorkommen, dass phpMyAdmin ein Upload-Limit hat. In diesem Fall importieren Sie die Datenbank per SSH-Kommandozeile – das ist schneller und kennt keine Dateigrößenbeschränkung.

Schritt 3: Konfiguration anpassen. Auf dem neuen Server müssen Sie die Datenbank-Zugangsdaten in der Konfigurationsdatei Ihres CMS aktualisieren. Die Datenbankverbindung auf dem neuen Server hat in der Regel einen anderen Hostnamen, Benutzernamen und ein anderes Passwort. Bei WordPress ändern Sie die Werte DB_NAME, DB_USER, DB_PASSWORD und DB_HOST in der Datei wp-config.php. Bei Joomla finden Sie die Einstellungen in configuration.php (Variablen $host, $user, $password, $db). Bei TYPO3 (bis v11) passen Sie die Werte in typo3conf/LocalConfiguration.php an, ab TYPO3 v12 liegt die Konfiguration unter config/system/settings.php. Bei Laravel-Anwendungen aktualisieren Sie die .env-Datei.

Schritt 4: CMS-spezifische Anpassungen. Je nach CMS können weitere Anpassungen nötig sein. Bei WordPress prüfen Sie die Optionen siteurl und home in der Tabelle wp_options – diese müssen auf Ihre korrekte Domain zeigen. Bei Joomla prüfen Sie den Wert $live_site in der configuration.php. Leeren Sie nach dem Umzug den Cache Ihres CMS, damit keine alten Pfade oder URLs zwischengespeichert bleiben.

Aus der Entwickler-Praxis: drei Fehlerbilder, die ich beim Datenumzug immer wieder sehe. Erstens Zeichensalat nach dem Datenbank-Import: Statt "für" steht plötzlich "für" im Text. Die Ursache ist fast immer ein Zeichensatz-Konflikt – die Datenbank wurde etwa mit latin1 exportiert, aber als utf8mb4 importiert. Prüfen Sie deshalb vor dem Export den Zeichensatz der Quelldatenbank und behalten Sie ihn beim Import bei. Zweitens der PHP-Versionssprung: Der neue Server läuft auf PHP 8.5, der alte noch auf einer längst abgekündigten Version – und plötzlich wirft ein altes Plugin oder Theme fatale Fehler. Mein Rat: Stellen Sie auf dem neuen Server zunächst dieselbe PHP-Version ein wie auf dem alten, ziehen Sie um, und heben Sie die Version erst danach kontrolliert an. Drittens zerstörte serialisierte Daten bei WordPress: Wer URLs per Suchen-und-Ersetzen direkt in der SQL-Datei austauscht, beschädigt serialisierte Strings, weil deren Längenangaben nicht mehr stimmen – Widgets und Theme-Einstellungen verschwinden scheinbar grundlos. Nutzen Sie stattdessen WP-CLI (wp search-replace) oder das Plugin Better Search Replace, die serialisierte Daten korrekt behandeln.

Schritt 5: Website auf dem neuen Server testen. Testen Sie die Website auf dem neuen Server, bevor Sie die DNS-Einstellungen ändern. Dafür gibt es zwei bewährte Methoden:

• hosts-Datei auf Ihrem Computer anpassen: Tragen Sie die IP-Adresse des neuen Servers zusammen mit Ihrer Domain in die lokale hosts-Datei ein (unter Windows: C:\Windows\System32\drivers\etc\hosts, unter macOS/Linux: /etc/hosts). Danach löst Ihr Rechner – und nur Ihr Rechner – die Domain auf den neuen Server auf. So können Sie die gesamte Website testen, ohne dass andere Besucher etwas bemerken. Vergessen Sie nicht, den DNS-Cache zu leeren und den Eintrag nach dem Test wieder zu entfernen.
• Temporäre URL oder Server-IP verwenden: Viele Hoster stellen eine temporäre URL oder eine Staging-Umgebung bereit, über die Sie die Website direkt auf dem neuen Server aufrufen können, ohne die DNS zu ändern.

Die DNS-Umstellung ist der Moment, in dem der Umzug live geht: Sie ändern den A-Record Ihrer Domain auf die IP-Adresse des neuen Servers oder tragen die Nameserver des neuen Hosters ein. Mit vorher gesenktem TTL-Wert greift die Änderung bei den meisten Besuchern oft innerhalb weniger Stunden.

Wenn Sie Ihre Website umziehen und auf dem neuen Server alles getestet haben, kommt also der entscheidende Schritt. Mit der DNS-Umstellung sagen Sie dem Internet, dass Ihre Domain ab jetzt auf den neuen Server zeigt.

Was sind DNS, Nameserver und A-Records? Das Domain Name System (DNS) funktioniert wie ein Telefonbuch des Internets: Es übersetzt lesbare Domainnamen (z. B. saschafix.de) in IP-Adressen (z. B. 123.456.78.90), die Computer verstehen. Nameserver sind die Server, die diese Zuordnung verwalten. Ein A-Record ist der DNS-Eintrag, der Ihre Domain direkt einer IPv4-Adresse zuordnet. Wenn Sie den Server wechseln, müssen Sie im Wesentlichen den A-Record Ihrer Domain auf die neue Server-IP ändern.

Methode 1: Nameserver beim Domain-Registrar ändern. Sie können die Nameserver Ihrer Domain komplett auf die Nameserver des neuen Hosters umstellen. Das ist die einfachste Methode, wenn Ihr neuer Hoster auch die DNS-Verwaltung übernehmen soll. Loggen Sie sich dazu beim Domain-Registrar ein (z. B. DENIC-Mitglied, IONOS, Strato) und tragen Sie die neuen Nameserver ein. Ihr neuer Hoster teilt Ihnen die korrekten Nameserver-Adressen mit.

Methode 2: A-Record auf neue Server-IP ändern. Wenn Sie die DNS-Verwaltung bei Ihrem bisherigen Registrar behalten möchten, ändern Sie nur den A-Record Ihrer Domain auf die IP-Adresse des neuen Servers. Diese Methode hat den Vorteil, dass Sie die volle Kontrolle über Ihre DNS-Einträge behalten und gezielt einzelne Records (z. B. MX für E-Mail) separat verwalten können.

DNS-Propagation: Warum dauert das so lange? Nach der DNS-Änderung dauert es erfahrungsgemäß zwischen wenigen Minuten und bis zu 48 Stunden, bis alle DNS-Server weltweit die neue Zuordnung übernommen haben. Das liegt daran, dass DNS-Server die Einträge zwischenspeichern (cachen) und erst nach Ablauf des TTL-Werts eine neue Abfrage starten. Manche Internetanbieter halten sich zudem nicht strikt an TTL-Vorgaben und cachen DNS-Einträge länger als vorgesehen. In der Praxis ist die Umstellung bei einem niedrigen TTL-Wert (300 Sekunden) oft innerhalb von 1 bis 4 Stunden bei den meisten Nutzern wirksam. Vollständig abgeschlossen ist die DNS-Propagation typischerweise nach 24 bis 48 Stunden.

TTL-Trick: Wartezeit minimieren. Wenn Sie den TTL-Wert wie in der Vorbereitung empfohlen 24 bis 48 Stunden vor dem Umzug auf 300 bis 600 Sekunden gesenkt haben, sorgen Sie dafür, dass DNS-Server die alte Zuordnung nur noch wenige Minuten cachen. Nach der DNS-Änderung holen sich die Server innerhalb von 5 bis 10 Minuten die neue IP-Adresse. Nach erfolgreichem Umzug und vollständiger DNS-Propagation können Sie den TTL-Wert wieder auf den Standardwert (z. B. 3.600 oder 86.400 Sekunden) anheben, um die Anzahl der DNS-Anfragen zu reduzieren.

E-Mail-Postfächer wandern beim Hoster-Wechsel nicht automatisch mit: Sie müssen jedes Postfach aktiv sichern und auf den neuen Server übertragen. Genau hier gehen beim Website umziehen am häufigsten Daten verloren. Der Grund: Viele Websitebetreiber vergessen, dass E-Mails oft direkt auf dem Hosting-Server gespeichert sind. Wird der alte Server abgeschaltet, bevor die E-Mails gesichert wurden, sind die Nachrichten unwiederbringlich weg. Eine ausführliche Anleitung mit drei konkreten Sicherungsmethoden finden Sie in meinem Artikel E-Mail beim Hoster-Wechsel sichern.

E-Mails vorher sichern: Richten Sie Ihr E-Mail-Programm (Thunderbird, Outlook oder Apple Mail) so ein, dass es per IMAP auf Ihr altes Postfach zugreift. IMAP synchronisiert alle Ordner und Nachrichten zwischen Server und Ihrem lokalen Rechner. Sobald alle E-Mails heruntergeladen sind, haben Sie eine lokale Kopie. Für eine zusätzliche Sicherung exportieren Sie die Ordner als lokale Archivdateien. Thunderbird bietet dafür die ImportExportTools-Erweiterung. Für die direkte Server-zu-Server-Migration eignet sich das frei verfügbare Tool imapsync, das Postfächer zuverlässig zwischen zwei IMAP-Servern spiegelt – inklusive Ordnerstruktur und Nachrichtenstatus.

E-Mail-Konten auf dem neuen Server einrichten. Erstellen Sie auf dem neuen Server die gleichen E-Mail-Adressen wie auf dem alten. Achten Sie auf identische Schreibweisen. Richten Sie die gleichen Passwörter oder – besser – neue, sichere Passwörter ein und aktualisieren Sie anschließend die Einstellungen in Ihrem E-Mail-Programm (SMTP-Server, IMAP-Server, Benutzername, Passwort).

MX-Records korrekt setzen. Die MX-Records (Mail Exchange) in Ihrer DNS-Zone bestimmen, welcher Server E-Mails für Ihre Domain empfängt. Beim Hoster-Wechsel müssen Sie die MX-Records auf den neuen Mailserver umstellen. Senken Sie auch hier vorher den TTL-Wert, um die Umstellungszeit zu minimieren. In der Übergangsphase (während der DNS-Propagation) können E-Mails sowohl auf dem alten als auch auf dem neuen Server ankommen – prüfen Sie daher beide Postfächer für 24 bis 48 Stunden.

SPF, DKIM und DMARC aktualisieren. Nach dem Hoster-Wechsel müssen Sie die DNS-Einträge für E-Mail-Authentifizierung aktualisieren, damit Ihre E-Mails nicht als Spam markiert werden. Der SPF-Record muss die IP-Adresse oder den Hostnamen des neuen Mailservers enthalten. Für DKIM generieren Sie neue Schlüssel auf dem neuen Server und tragen den öffentlichen Schlüssel als DNS-TXT-Record ein. Der DMARC-Record bleibt in der Regel unverändert, sollte aber geprüft werden. Eine ausführliche Anleitung finden Sie in meinem Artikel SPF, DKIM und DMARC einrichten.

Ein SSL-Zertifikat lässt sich nicht einfach mitnehmen: Auf dem neuen Server beantragen Sie ein neues Zertifikat – bei den meisten Hostern kostenlos über Let's Encrypt und mit wenigen Klicks im Hosting-Panel. Ohne HTTPS zeigen Browser eine "Nicht sicher"-Warnung, und Google bewertet Seiten ohne SSL schlechter im Ranking. Bei kommerziellen Zertifikaten (z. B. von DigiCert oder Sectigo) prüfen Sie bei Ihrem Anbieter, ob eine kostenlose Neuausstellung für den neuen Server möglich ist – viele CAs bieten das an.

Let's Encrypt auf dem neuen Server einrichten. Die meisten Hosting-Anbieter bieten kostenlose Let's-Encrypt-Zertifikate an, die sich automatisch verlängern. Bei Shared-Hosting-Paketen aktivieren Sie SSL häufig mit einem Klick im Hosting-Panel (cPanel, Plesk). Bei eigenen Servern installieren Sie den Certbot-Client, der die Zertifikatsausstellung und -erneuerung automatisch übernimmt. Let's-Encrypt-Zertifikate sind derzeit 90 Tage gültig und werden automatisch 30 Tage vor Ablauf erneuert. Beachten Sie die offiziell angekündigte Verkürzung: Ab Februar 2027 stellt Let's Encrypt im Standard-Profil Zertifikate mit 64 Tagen Laufzeit aus, ab Februar 2028 mit 45 Tagen – eine funktionierende automatische Erneuerung auf dem neuen Server wird damit noch wichtiger. Wichtig: Das SSL-Zertifikat kann erst ausgestellt werden, wenn die Domain bereits auf den neuen Server zeigt – Let's Encrypt prüft bei der Ausstellung, ob die Domain von der IP des Servers erreichbar ist. Planen Sie deshalb eine kurze Phase ein, in der Ihre Website ohne SSL auf dem neuen Server läuft. Mehr Details dazu finden Sie in meinem Artikel Let's Encrypt automatisch verlängern.

Mixed-Content-Probleme vermeiden. Nach dem Umzug und der SSL-Einrichtung kann es vorkommen, dass Ihre Website zwar per HTTPS erreichbar ist, aber einzelne Ressourcen (Bilder, Stylesheets, Skripte) noch über HTTP geladen werden. Das führt zu Mixed-Content-Warnungen im Browser und einem teilweise gebrochenen Schloss-Symbol. Prüfen Sie nach dem Umzug alle Seiten auf Mixed Content. Häufige Ursachen sind: fest eingetragene HTTP-URLs in der Datenbank (bei WordPress: Suchen-und-Ersetzen mit dem Tool WP-CLI oder dem Plugin Better Search Replace), HTTP-URLs in der Konfigurationsdatei oder in Theme-/Template-Dateien. Eine ausführliche Anleitung zur Behebung finden Sie in meinem Artikel Mixed Content HTTPS beheben.

Redirect von HTTP auf HTTPS einrichten. Stellen Sie sicher, dass alle HTTP-Aufrufe dauerhaft auf HTTPS umgeleitet werden. Bei Apache-Servern fügen Sie die passende RewriteRule in die .htaccess-Datei ein. Bei Nginx konfigurieren Sie einen Server-Block, der Port 80 auf 443 umleitet. Verwenden Sie immer einen 301-Redirect (permanente Weiterleitung), damit Suchmaschinen die HTTPS-Version als kanonische URL erkennen.

Nach der DNS-Umstellung prüfen Sie systematisch alle Seiten, Formulare, Bilder, das SSL-Zertifikat und den E-Mail-Empfang – und lassen den alten Vertrag noch 2 bis 4 Wochen als Sicherheitsnetz weiterlaufen. Aus meiner Erfahrung passieren die meisten Fehler nicht während der Migration, sondern in den Tagen danach, wenn die Aufmerksamkeit nachlässt.

Google Search Console nach dem Umzug. Wenn sich nur die Server-IP ändert, aber die Domain gleich bleibt, brauchen Sie in der Google Search Console grundsätzlich nichts zu tun – Google erkennt den neuen Server automatisch. Überprüfen Sie dennoch den Abdeckungsbericht in den Tagen nach dem Umzug auf neue Crawl-Fehler. Wenn Sie gleichzeitig die Domain gewechselt haben, nutzen Sie das "Adressänderung"-Tool in der Search Console, um Google den Domainwechsel mitzuteilen. Reichen Sie außerdem eine aktualisierte Sitemap ein. Und wenn der Umzug ohnehin Teil eines größeren Umbaus ist, trennen Sie beides sauber – meine Website-Relaunch-Checkliste zeigt, welche Schritte dann zusätzlich anstehen.

Häufige Fehler nach dem Umzug. Die drei häufigsten Probleme, die ich bei Website-Umzügen sehe: Erstens, der alte Server wird zu früh gekündigt – E-Mails gehen verloren, Backups sind nicht mehr verfügbar. Zweitens, Redirect-Schleifen durch doppelte .htaccess-Regeln (alte Regeln plus Hoster-automatische Regeln). Drittens, Datenbankverbindungsfehler, weil die Zugangsdaten in der CMS-Konfiguration nicht aktualisiert wurden. Ein vierter Klassiker aus der Praxis: .htaccess-Direktiven, die der neue Server nicht kennt. Eine einzige php_value-Zeile aus dem alten Hosting reicht, um auf dem neuen Server einen 500-Fehler auszulösen – kommentarloses Weißbild inklusive. Prüfen Sie die übernommene .htaccess deshalb Zeile für Zeile gegen die Dokumentation des neuen Hosters. Wenn Sie nach dem Umzug auf Probleme stoßen, die Sie nicht selbst lösen können, schauen Sie auf meine Website-Reparatur-Seite oder kontaktieren Sie mich direkt.

Ein professioneller Website-Umzug kostet marktüblich 100 bis 500 EUR zzgl. MwSt., in Eigenleistung investieren Sie je nach Komplexität 2 bis 8 Stunden Arbeitszeit. Viele Hoster bieten Neukunden zudem einen kostenlosen Umzugsservice an.

Ob Sie Ihre Website selbst umziehen oder den Umzug von einem Profi durchführen lassen, hängt von Ihrem technischen Know-how und der Komplexität Ihrer Website ab. Hier ein realistischer Überblick zu Aufwand und Kosten.

Eigenleistung: 2 bis 8 Stunden Zeitaufwand. Wenn Sie den Umzug selbst durchführen, fallen keine direkten Kosten an – nur Ihre Arbeitszeit. Für eine einfache WordPress-Website mit einer kleinen Datenbank und wenigen E-Mail-Postfächern sollten Sie etwa 2 bis 3 Stunden einplanen. Bei größeren Websites mit mehreren Datenbanken, komplexen Konfigurationen oder umfangreichen E-Mail-Archiven kann der Aufwand auf 6 bis 8 Stunden anwachsen. Rechnen Sie die Testphase nach dem Umzug mit ein.

Professioneller Umzug: 100 bis 500 EUR (zzgl. MwSt.). Die Kosten für einen professionellen Website-Umzug liegen marktüblich zwischen 100 und 500 EUR, abhängig von der Komplexität: Anzahl der Websites und Domains, Datenbankgröße, Anzahl der E-Mail-Postfächer, CMS-Typ und Sonderkonfigurationen. Für eine einzelne WordPress-Website ohne E-Mail-Migration bieten einige Dienstleister Festpreise ab 99 EUR an. Seriöse Anbieter erstellen nach einer Erstanalyse einen verbindlichen Kostenvoranschlag.

Kostenlose Umzugs-Services der Hoster. Viele Hosting-Anbieter bieten für Neukunden einen kostenlosen Umzugsservice an. All-Inkl.com unterstützt beim kompletten Providerwechsel und begleitet den Umzug. IONOS bietet einen kostenlosen Domain-Transfer. Mittwald übernimmt für Neukunden die Migration von WordPress-, TYPO3- und Shopware-Projekten. HostPress bietet einen kostenlosen Umzugsservice für WordPress-Websites. Es lohnt sich, beim neuen Hoster nachzufragen, ob ein solcher Service im Paket enthalten ist – gerade bei einem Wechsel zu einem höherwertigen Tarif. Prüfen Sie die aktuellen Konditionen direkt beim jeweiligen Anbieter, da sich Leistungsumfang und Verfügbarkeit jederzeit ändern können.

Brauchen Sie professionelle Unterstützung? Ich helfe Ihnen beim Umzug Ihrer Website – schnell, sicher und zum Festpreis. Von der Vorbereitung über die Datenmigration bis zur DNS-Umstellung übernehme ich den kompletten Prozess. Mehr dazu auf meiner Website-Reparatur-Seite.

Zuletzt aktualisiert: 6. Juli 2026  ·  Lesezeit: ca. 22 Minuten