Migrieren Sie WordPress auf einen anderen Host, ohne Ihre Bestellungen zu verlieren

9 Min. Lesezeit

Bei einer Migration von WordPress auf einen anderen Host mit derselben Domäne müssen Bestellungen, deren Zahlungen und Bestandsaktualisierungen erhalten bleiben. Der entscheidende Punkt ist nicht die Kopie: Es ist der Moment, in dem der alte Server aufhört zu schreiben und der neue zur alleinigen Autorität wird.

Eine Sicherung stellt einen früheren Zustand wieder her. Eine Migration organisiert die Kontinuität zwischen zwei Staaten. Bereiten Sie den neuen Server vor, während der Store geöffnet bleibt, frieren Sie dann die Schreibvorgänge ein, synchronisieren Sie ihn und öffnen Sie ihn erst nach der Validierung.

Berechtigung und Zugriff vor dem Kopieren korrigieren

Kombinieren Sie den Zugriff auf Hosting-, DNS- und Zahlungsdienste. Identifizieren Sie, wer das Einfrieren autorisiert, wer den Wechsel ausführt und wer die Befehle validiert. Der Filialleiter muss die Wiedereröffnung ablehnen können.

Führen Sie eine Bestandsaufnahme der PHP- und WordPress-Versionen, Erweiterungen, Befehlsspeicher, Medien, geplanten Aufgaben, E-Mail-Absender und Logistikverbindungen durch. Fügen Sie eingehende und ausgehende Webhooks, API, die den Bestand ändern, und an anderer Stelle gespeicherte Daten hinzu.

WordPress fordert Sie auf, die Site-Dateien und ihre Datenbank zu speichern, bevor Sie den Server wechseln ^[3]. Für eine komplette Restaurierung sind diese beiden Sets erforderlich ^[2]. Überprüfen Sie auch ihre Wiederherstellung in einer isolierten Umgebung.

Vereinbaren Sie eine Betriebsregel: Nur ein Server kann Schreibvorgänge akzeptieren. Validieren Sie die Datenverarbeitungsbedingungen auf dem neuen Host, beschränken Sie den Zugriff auf Klone und planen Sie deren Löschung nach der Validierung.

Zum Vorbereiten kopieren, ohne einen zweiten Laden zu eröffnen

Das Beispiel ist fiktiv und beschreibt nicht einen Kunden von 4SYSTEM: Ein Ersatzteillager erhält während der vorbereitenden Kopie noch Bestellungen. Die alte Seite bleibt die Referenz. Der Klon wird zur Überprüfung von Hosting, Medien, Warenkorb und Verbindungen verwendet, nicht zur Erstellung tatsächlicher Bestellungen.

Isolieren Sie diesen Klon vor seinem ersten Start: Blockieren Sie den Versand von E-Mails, echte Zahlungen, Logistikanrufe und die Ausführung von Aufgaben. Eine lokale Vorschau mit der üblichen Domain stellt keinen Schutz dar.

Bei WooCommerce-Abonnements löst das Beibehalten derselben Domäne nach dem Kopieren der Datenbank nicht den Staging-Modus aus: Verlängerungen können im Real-Modus verarbeitet werden ^[9]. Lassen Sie sich also nicht vom Wort „Vorproduktion“ im Hosting-Panel täuschen.

Behalten Sie die üblichen öffentlichen URLs bei und passen Sie die Verbindung zur Datenbank an, wenn sich deren Parameter ändern: WordPress unterscheidet zwischen der Pflege der Domäne und der Änderung der Konfiguration ^[3]. Funktionsupdates verschieben: Sie würden Diagnose und Rollback erschweren.

Migration von WordPress auf einen anderen Host: einfrieren und dann synchronisieren

Die vorbereitende Kopie veraltet, sobald eine neue Bestellung eintrifft. Um den Umschaltstatus zu erhalten, befolgen Sie diese Reihenfolge:

1. Schließen Sie den Auftragsdurchlauf und unterbrechen Sie Backoffice-Änderungen, Importe, Synchronisierungen und Schreibaufrufe API. Eine einfache Wartungsseite reicht nicht aus.
2. Gleichen Sie bereits angefallene Zahlungen mit Bestellungen von der alten Website ab. Benachrichtigungen während der Übertragung müssen dort vor dem Schneiden verarbeitet oder für eine getestete Wiedergabe in einer dauerhaften Warteschlange gehalten werden.
3. Überprüfen Sie die Wiederherstellungsoptionen des Zahlungsanbieters. Bestätigen Sie den Empfang eines Webhooks nicht ohne dauerhafte Aufbewahrung. Ohne dokumentierte Wiederholung oder mögliche Abstimmung verschieben Sie den Wechsel.
4. Stoppen Sie WordPress-Aufgaben und hosten Sie Crons und Erweiterungsdateien. Protokollieren Sie den letzten zulässigen Status und noch ausstehende Ereignisse.
5. Erstellen Sie das endgültige Backup, die Basis und dann die Dateien. Stellen Sie die Dateien und dann die Datenbank am isolierten Ziel wieder her, gemäß der von WordPress empfohlenen Reihenfolge. ^[2].

Die endgültige Synchronisierung ersetzt den Vorbereitungsstatus durch den kohärenten Satz eingefrorener Daten, einschließlich der Erweiterungstabellen und aktueller Medien. Kopieren Sie nicht nur Bestellungen: Bestände, Konten, Notizen und zugehörige Status müssen folgen. Fordern Sie einen Nachweis über das Einfrieren und den Abgleich ausstehender Aufträge an, bevor Sie DNS autorisieren.

Schalten Sie DNS um, ohne zwei aktive Sites zu erstellen

Beachten Sie die Datensätze, die tatsächlich den Webverkehr leiten: IPv4, IPv6 und möglicherweise CDN. Stellen Sie sicher, dass die geplante Änderung keine Auswirkungen auf E-Mail-Datensätze hat. Wenn Sie die TTL verringern, tun Sie dies im Voraus und notieren Sie den vorherigen Wert.

Der DNS schaltet nicht alle Besucher gleichzeitig um. Einige Caches führen möglicherweise noch zum alten Server, während andere den neuen erreichen. Wählen Sie also die neue als Schreibautorität, unabhängig davon, was Ihr Browser sieht.

Der alte Server darf weiterhin keine Befehle, Rückrufe oder administrative Änderungen akzeptieren. Behalten Sie die Wartung bei; Eine Weiterleitung an das Ziel ist nur nach technischer Validierung der Routing- und Webhook-Signaturen akzeptabel.

Steuern Sie HTTPS, kanonische Domäne, Verwaltung und Caches über mehrere Zugriffe. Die Anzeige beweist weder, dass die richtige Basis antwortet, noch dass alle Zahlungen dort eingehen. Bewahren Sie den Nachweis der kontaktierten Serveradresse auf.

Erhalten Sie die Wiederherstellung und neutralisieren Sie die alten Automatisierungen

Das Rezept beginnt vor dem Öffnen: Administratorverbindung, Medien, Warenkorb, Lieferung, Steuern und Zahlungsvorgang im Testmodus, ohne echte Sammlung auf dem Klon. Vergleichen Sie anschließend die Musterbestellungen und ausstehenden Zahlungen mit dem endgültigen gespeicherten Status und den Referenzen des Dienstleisters. Überprüfen Sie die zugehörigen Status, Bewertungen und Bestände.

Reaktivieren Sie die Verarbeitung auf dem neuen Server erst nach dieser Validierung. Überprüfen Sie jede Warteschlange vor dem Start, um zu vermeiden, dass eine Aktion wiederholt wird, die bereits ausgeführt wurde. Die Wiedergabe von Webhooks muss ihre Bezeichner kontrollieren, um eine doppelte Verarbeitung zu vermeiden. Öffnen Sie Bestellungen erneut und verfolgen Sie dann eine autorisierte Bestellung durch Benachrichtigung und Logistikabwicklung.

Das alte Hosting behält seine Automatismen, solange Sie diese nicht neutralisieren. Bei Abonnements stoppt der Staging-Modus nicht alle geplanten Ereignisse und andere Erweiterungen können weiterhin E-Mails senden ^[9]. Steuern Sie Action Scheduler, WP-Cron, externe Crons und SMTP-Absender separat. Durch das Stoppen des Action Scheduler-Runners können auch Ereignisse von anderen Erweiterungen blockiert werden, die diese Bibliothek verwenden ^[9].

Dokumentieren Sie wiederkehrende Kontrollen in Ihrem Managementprozess Wartung und Backups. Löschen Sie die alte Umgebung erst, nachdem verzögerte Ereignisse abgeglichen wurden und das Routing sowie das Fehlen verbleibender Schreibvorgänge bestätigt wurde.

Schaltprotokoll: nachvollziehbare Entscheidungen

Das folgende Protokoll enthält abgeschlossene Einträge für den fiktiven Store. Der technische Pilot hält die Beweise; Der Filialleiter unterzeichnet den Eröffnungsbeschluss. Bei den gezeigten Teilen handelt es sich um erwartete Validierungen, nicht um beobachtete Ergebnisse.

Geben Sie für jede Zeile die tatsächliche Zeit, den Sprecher und den sicheren Ort des Beweismittels ein. Notieren Sie sich die für den Abgleich nützlichen Identifikatoren, niemals die Kartendaten.

Gehen Sie zurück, ohne neue Einträge zu löschen

Rollback hängt von Schreibvorgängen ab, nicht nur vom Serverbetrieb. Wenden Sie diesen Entscheidungsbaum an:

• Keine neuen Einträge zum Ziel? Halten Sie beide Standorte geschlossen, bestätigen Sie diese Abwesenheit und stellen Sie dann den alten als Autorität wieder her, bevor Sie DNS ändern und seine Verarbeitung erneut aktivieren.
• Haben sich Bestellungen, Zahlungen, Konten oder Bestände geändert? Den neuen Zustand sofort beibehalten. Priorisieren Sie eine Korrektur auf dem neuen Server. Ein altes Backup würde diese Änderungen löschen.
• Ist die Rückgabe der Unterkunft weiterhin notwendig? Frieren Sie das Ziel ein, speichern Sie seinen vollständigen Status und stellen Sie diesen aktuellen Status auf dem alten isolierten Server wieder her. Validieren Sie ausstehende Integrationen und Ereignisse erneut, bevor Sie ihnen die Autorität zurückgeben.
• Beide Server haben geschrieben? Frieren Sie alle Schreibvorgänge auf beiden Servern gemäß dem oben beschriebenen Verfahren ein und behalten Sie dann deren Status separat bei. Lassen Sie Bestellungen, Zahlungen und Logistikmaßnahmen vor einer Wiederherstellung abgleichen. Keine improvisierte SQL-Zusammenführung garantiert ihre Konsistenz.

Eine bereits ausgelöste Rückerstattung, E-Mail oder Sendung wird durch die Wiederherstellung nicht storniert. Gleichen Sie Dienstleisterreferenzen und Logistikprotokolle ab, um zu entscheiden, welche Ereignisse fortgesetzt werden sollen. Wenn das Fehlen neuer Einträge nicht nachweisbar ist, behandeln Sie den Fall als Erholung nach Einträgen.

Häufige Fragen

Nach dem Öffnen kommt ein Webhook auf dem alten Server an: Was tun?

Versuchen Sie nicht, den Store erneut zu aktivieren, um dieses Ereignis allein zu verarbeiten. Überprüfen Sie, ob der Anbieter einen erneuten Versuch plant und ob sich die Benachrichtigung in Ihrer dauerhaften Warteschlange befindet. Gleichen Sie die Referenz mit der auf der neuen Website erfassten Zahlung ab und wenden Sie dann den getesteten Wiederherstellungsmechanismus an. Wenn keine ausreichenden Beweise vorliegen, lassen Sie den Fall manuell prüfen.

Können wir das alte Hosting nur für E-Mails beibehalten?

Ja, wenn die Boxen und ihre DNS-Datensätze freiwillig bei diesem Dienstleister verbleiben. Trennen Sie dann die Wartung des Messagings von der von WordPress: Die alte Anwendung, ihre Aufgaben und ihr automatischer Versand müssen neutralisiert bleiben. Überprüfen Sie vor der Kündigung die Vertragsabhängigkeiten und testen Sie Empfang, Versand und Authentifizierung vom ausgewählten Dienst.

Kann ein vor Frost geöffneter Korb garantiert werden?

Nicht durch einfaches Kopieren der Befehle. Ein Warenkorb kann von Sitzungen, Cookies oder externen Speichern abhängen, deren Wiederaufnahme überprüft werden muss. Warnen Sie Käufer vor dem Einfrieren und testen Sie diesen Fall am Bestimmungsort. Verwechseln Sie nicht den abgebrochenen Warenkorb mit der bestätigten Zahlung: Letzteres erfordert einen Abgleich, bevor der Kunde aufgefordert wird, erneut zu beginnen.

Bereiten Sie den nächsten Schalter vor

Beginnen Sie mit der Vervollständigung des Eintragsinventars und der Zuweisung von Journalentscheidungen. Planen Sie das Einfrieren dann nur, wenn isoliertes Kopieren und Wiederaufnahme von Benachrichtigungen aktiviert sind. Wenn niemand die alleinige Autorität bestätigen oder die nach der Eröffnung ergangenen Anordnungen wahren kann, verschieben Sie den Wechsel. Um diese Vorbereitung zu gestalten, können Sie die konsultieren Webdienste von 4SYSTEM.

Quellen

• Backups : Advanced Administration Handbook | Developer.WordPress.org (abgerufen 2026-10-08)
• Migrating WordPress : Advanced Administration Handbook | Developer.WordPress.org (abgerufen 2026-10-08)
• How Subscriptions Handles Staging Sites and Migrations Documentation - WooCommerce (abgerufen 2026-10-08)