Shop-Umzug auf neuen Hoster ohne Ausfall

Senke den TTL der DNS-Eintraege 1 bis 2 Tage vor dem Umzug auf 300 Sekunden
Erstelle ein vollstaendiges Backup von Dateien und Datenbank, bevor du etwas anfasst
Starte und teste den Shop zuerst auf einer Subdomain des neuen Hosters
Schalte das DNS im Zeitfenster mit dem geringsten Traffic um, nicht Freitagnachmittag
Aktualisiere nach dem Umschalten die Zahlungs-Webhooks, sonst bleiben Bestellstatus stehen
[/dwb_keytakeaways]

Warum der Shop-Umzug Angst macht und das unnoetig ist

Ein Shop-Umzug auf einen neuen Hoster klingt wie eine Operation am offenen Herzen: ein falscher Schritt und der Verkauf steht, Kunden sehen einen weissen Bildschirm, Bestellungen gehen verloren. In der Praxis ist die Migration planbar und sicher, wenn du sie in der richtigen Reihenfolge durchfuehrst und unterwegs nichts loeschst. Den alten Shop laesst du bis zum Schluss laufen, den neuen baust und testest du daneben auf einer Subdomain. Der Kunde merkt nichts, weil er die ganze Zeit den alten Server nutzt.

Die wichtigste Regel lautet: Du schaltest den alten Server nicht ab, solange der neue nicht zu 100 Prozent laeuft. Ein Umzug ist kein Wohnungswechsel, bei dem man zuerst die alte Wohnung raeumt. Es ist eher der Aufbau einer Kopie am neuen Ort, und das Umschalten des Traffics erfolgt erst, wenn diese Kopie geprueft ist. Den alten Shop loeschst du erst nach einigen Tagen stabilem Betrieb des neuen.

Das echte Risiko ist nicht die Seite oder die Datenbank. Die groesste Gefahr sind Bestellungen, die Kunden im alten Shop waehrend der Kopie aufgeben. Dazu schreibe ich gleich gesondert, denn genau dieses Detail trennt einen sauberen Umzug von einem, nach dem du verschwundene Bestellungen in zwei Datenbanken gleichzeitig suchst.

Vorbereitung: was du klaerst, bevor du etwas anfasst

Ein guter Umzug besteht zu 80 Prozent aus Vorbereitung. Je mehr du vor dem Start klaerst, desto weniger Entscheidungen triffst du unter Druck, wenn der Traffic schon umgeschaltet wird. Bevor du den neuen Server anfasst, geh ein paar Punkte durch.

• Pruefe den neuen Hoster: gleiche oder hoehere PHP-Version (am besten 8.3), gleiche oder groessere Datenbank-Umgebung, Upload-Limit und PHP-Speicher passend zum Shop. Ein Shop auf PHP 8.3 startet auf einem Server mit PHP 7.4 nicht sauber.
• Notiere alle Zugaenge: Panel des alten und neuen Hosters, SFTP, Datenbank, Domain- und DNS-Verwaltung, Dashboards der Zahlungsanbieter. Fehlender DNS-Zugriff im entscheidenden Moment blockiert den ganzen Umzug.
• Mach eine Inventur: Liste der Plugins, Version von WordPress und WooCommerce, Schnittstellen (Versand, Rechnungen, Newsletter), externe Skripte. Was du jetzt vergisst, meldet sich nach dem Umschalten.
• Waehle das Umzugsfenster: die Zeit mit dem geringsten Traffic, meist nachts oder frueh morgens an einem Werktag. Nie Freitagabend, denn wenn etwas schiefgeht, reparierst du am Wochenende ohne Hoster-Support.

Backup von Dateien und Datenbank

Das Herz eines Shops sind zwei Dinge: die Dateien (Theme, Plugins, hochgeladene Produktbilder im Uploads-Ordner) und die Datenbank (Produkte, Bestellungen, Kunden, Einstellungen). Migration heisst, beide Schichten so auf den neuen Server zu bringen, dass nichts verloren geht.

Bei kleinen und mittleren Shops ist ein Migrations-Plugin am einfachsten. Bei groesseren Shops mit schwerer Datenbank und tausenden Bildern eignet sich ein manuelles Backup besser, weil Plugins Groessenlimits fuer das Paket haben, die man schnell ueberschreitet.

1. Datei-Backup: lade per SFTP das gesamte WordPress-Verzeichnis herunter, besonders den Ordner wp-content (dort liegen Theme, Plugins und Uploads). Cache und temporaere Dateien laesst du aus.
2. Datenbank-Backup: exportiere die Datenbank ueber phpMyAdmin oder Adminer in eine SQL-Datei. Das ist die vollstaendige Momentaufnahme von Produkten, Bestellungen und Kunden.
3. Sicherungskopie des alten Shops: bevor du etwas aenderst, halte ein funktionierendes Backup bereit, mit dem du zum Ausgangspunkt zurueckkehren kannst. Das ist dein Sicherheitsnetz.

Test auf der Subdomain: der wichtigste Schritt

Diesen Schritt darfst du nicht ueberspringen. Bevor du die Domain auf den neuen Server umschaltest, startest du dort den Shop unter einer technischen Adresse, etwa test.deinedomain.de oder einer vom Hoster bereitgestellten Subdomain. So testest du einen laufenden Shop auf dem Zielserver, waehrend der echte Traffic noch auf den alten geht.

Auf der Subdomain gehst du den ganzen Weg von Kunde und Administrator durch, als waerst du Kaeufer und Inhaber zugleich:

• Startseite, Kategorieliste, Produktseite, Suche, Warenkorb.
• Schritt zur Zahlung (ohne echte Zahlung abzuschliessen, da der Anbieter noch auf die alte Adresse zeigt).
• Login ins Backend, Bestelluebersicht, Produkt bearbeiten, Test-E-Mail versenden.
• Ob Produktbilder laden, ob es keine 404-Fehler gibt und ob die Server-Logs sauber sind.

Wenn der Shop unter der Subdomain laeuft, muss oft die Adresse in der Datenbank angepasst werden (von der Zieldomain auf die Subdomain) und nach dem Umschalten wieder zurueck. Das ist Routine, wird aber leicht vergessen, und dann leitet der Shop auf sich selbst um.

DNS, TTL und SSL: das technische Umschalten

Wenn der Shop auf der Subdomain laeuft, bleibt nur noch das Umschalten des Traffics. Das geschieht ueber die Aenderung der DNS-Eintraege, meist des A-Eintrags (IP-Adresse) und gegebenenfalls des CNAME fuer www. Du zeigst die Domain auf die IP-Adresse des neuen Servers, und ab dann landet neuer Traffic auf dem neuen Hoster.

Hier kommt der TTL zurueck. Hast du ihn vorher auf 300 Sekunden gesenkt, ist die Propagation praktisch sofort: In wenigen Minuten ist der Grossteil des Traffics auf dem neuen Server. Hast du es vergessen und der TTL steht auf 24 Stunden, landet einen Tag lang ein Teil der Kunden noch auf dem alten Shop und ein Teil auf dem neuen. Bei aktivem Verkauf ist das eine Einladung zum Auseinanderlaufen der Bestellungen.

Die zweite Sache ist SSL. Auf dem neuen Server muss das Zertifikat fuer deine Domain ausgestellt sein, bevor du das DNS umschaltest, oder direkt danach. Die meisten Hoster bieten ein kostenloses Let's-Encrypt-Zertifikat, das automatisch ausgestellt wird, sobald die Domain auf den Server zeigt. Achte darauf, dass der Shop nicht einmal kurz ohne gueltiges SSL ist, sonst zeigen Browser eine Warnung und Kunden springen ab.

Umschalt-Fenster ohne Ausfall und Bestellungen im Flug

Das ist der Moment, in dem sich entscheidet, ob der Umzug fehlerfrei war. Die Seite selbst verschwindet nicht, denn der alte Server laeuft bis zum Ablauf des TTL. Das Problem sind Bestellungen, die im alten Shop zwischen dem Datenbank-Backup und dem DNS-Umschalten aufgegeben wurden. Diese Bestellungen liegen in der alten Datenbank, fehlen aber in der neuen.

Es gibt zwei bewaehrte Wege, das zu vermeiden:

1. Wartungsmodus fuer das Fenster: fuer einige Minuten, nachts, blendest du einen kurzen Wartungshinweis ein, machst einen finalen Datenbank-Export, spielst ihn auf den neuen Server und schaltest das DNS um. Keine Bestellungen im Flug, weil der Shop kurz keine neuen annimmt.
2. Finaler Datenbank-Dump direkt vor dem Umschalten: willst du den Shop nicht abschalten, machst du direkt vor der DNS-Aenderung ein zweites, frisches Datenbank-Backup, und dieses landet auf dem neuen Server. So verkuerzt du das Fenster, in dem Bestellungen nur in die alte Datenbank fallen koennten, auf Minuten.

Fuer die meisten Shops mit kleinem und mittlerem Traffic reicht ein Umschalten nachts mit finalem Datenbank-Dump. Bei einem grossen Shop mit Dauer-Traffic lohnt sich fuer diese paar Minuten der Wartungsmodus, denn die Gewissheit, dass keine Bestellung verloren geht, ist eine kurze Pause um drei Uhr nachts wert.

Zahlungs-Webhooks und Schnittstellen nach dem Umschalten

Die API-Schluessel der Zahlungsanbieter ziehen mit der Datenbank um, formal funktionieren die Zahlungen nach dem Umzug also. Was nicht automatisch mitkommt, sind die Webhooks, also die Adressen, an die Stripe, PayPal, Klarna oder SEPA-Dienste die Meldung ueber eine verbuchte Zahlung senden. Hat sich Server oder SSL-Zertifikat geaendert, kommen diese Meldungen eventuell nicht mehr an, die Zahlung geht durch, aber der Bestellstatus im Shop aktualisiert sich nicht.

Geh nach dem Umschalten der Domain in das Dashboard jedes Anbieters und pruefe die Webhook-Adresse. Meist genuegt es zu bestaetigen, dass sie auf die korrekte Shop-Adresse mit gueltigem SSL zeigt. Dasselbe gilt fuer andere Schnittstellen, die Daten von aussen empfangen: Versandsysteme, Rechnungsstellung, Anbindungen an Grosshaendler. Alles, was sich ueber eine URL mit dem Shop verbindet, muss geprueft werden.

Checkliste nach dem Umzug

Wenn der Traffic auf dem neuen Server liegt, ist die Arbeit nicht beendet. Die ersten Stunden und der erste Tag sind die Zeit zu pruefen, ob unterwegs nichts liegen geblieben ist. Hier die Liste, die ich bei jedem Umzug durchgehe.

Nach einigen Tagen stabilem Betrieb des neuen Shops kannst du den alten Server in Ruhe abschalten und den TTL wieder auf einen hoeheren Wert anheben. Loesche ihn nicht frueher, denn er ist dein einziges Sicherheitsnetz, falls erst nach laengerer Zeit etwas auffaellt.

Die haeufigsten Fallen beim Umzug

Nach vielen umgezogenen Shops sehe ich, dass sich die Fehler an wenigen Stellen wiederholen. Die meisten lassen sich umgehen, wenn du sie vorher kennst.

• Vergessener TTL: DNS-Umschalten bei TTL 24h bedeutet einen Tag Auseinanderlaufen des Traffics zwischen altem und neuem Server.
• Bestellungen im Flug: Datenbank-Backup morgens, Umschalten nachmittags, und die Bestellungen aus diesen Stunden bleiben nur in der alten Datenbank.
• Alte Adresse in der Datenbank: nach dem Umzug bleiben alte URLs in der Datenbank, der Shop leitet auf sich selbst um oder laedt Ressourcen vom alten Server.
• Webhooks nicht aktualisiert: Zahlungen gehen durch, aber die Bestellstatus stehen, weil der Anbieter Meldungen an die alte Adresse sendet.
• Kurz ohne SSL: das Zertifikat wurde auf dem neuen Server nicht rechtzeitig ausgestellt, Kunden sehen eine Warnung und springen ab.
• Alten Server sofort geloescht: das Loeschen der Quelle einen Tag nach dem Umzug laesst dich ohne Plan B, wenn ein Problem spaeter auftaucht.

Wenn du einen Shop-Umzug planst und das Risiko verlorener Bestellungen vermeiden willst, mache ich solche Migrationen bei DawidWeb regelmaessig: vollstaendiges Backup von Dateien und Datenbank, Test auf der Subdomain, DNS-Umschalten im Zeitfenster mit wenig Traffic, SSL-Pruefung und Aktualisierung der Zahlungs-Webhooks, damit sich Bestellungen ab der ersten Minute von selbst verbuchen. Webseiten und Shops baue und ziehe ich ab 600 Euro um, ich habe ueber 120 Projekte umgesetzt, und ein Angebot fuer deinen konkreten Umzug bekommst du innerhalb von 24 Stunden.