WordPress Migrations-Checkliste: Dateien, Daten und Domänen sicher verschieben

Definieren Sie, was sich bewegt und wer den Cutover kontrolliert

Eine WordPress-Migration verschiebt eine bestehende Anwendung und ihre Daten. Entscheiden Sie, ob Sie nur den Hosting-Server oder auch die Domain, den URL-Pfad oder das HTTPS-Schema ändern. Notieren Sie sich die aktuellen WordPress- und Site-Adresseinstellungen, die Datenbankverbindung, den Upload-Standort und jedes benutzerdefinierte Routing. Ein Server-Move und ein Domain-Wechsel erfordern unterschiedliche Prüfungen.

Weisen Sie eine Person zu, um die endgültige Kopie zu genehmigen und DNS zu ändern. Bestätigen Sie, dass Sie auf die alten Dateien zugreifen, die Datenbank exportieren, das Ziel konfigurieren und die relevanten DNS-Einträge bearbeiten können. Notieren Sie die vorhandenen Aufzeichnungen, bevor Sie sie ändern. Die Auswahl eines Hosting-Plans überträgt nicht selbst Ihre Website; organisieren Sie die Migration mit der für Ihre Bewerbung verantwortlichen Person.

Erstellen Sie ein Matched Files-and-Database Backup

Speichern Sie die WordPress-Dateien und einen Datenbankexport als einen identifizierbaren Backup-Satz. Fügen Sie Uploads, Themes, Plugins und die Konfiguration hinzu, die erforderlich ist, um die Anwendung wieder zu verbinden. Das Herunterladen des WordPress-Verzeichnisses allein erfasst keine Datenbank, die in MySQL oder MariaDB gespeichert ist. Notieren Sie, wann der Export getätigt wurde, und bewahren Sie eine Kopie vom ersetzten Server auf.

Überprüfen Sie den Bestimmungsort PHP Version, erforderliche Erweiterungen, Datenbankkompatibilität und Speicherplatz sowohl für die wiederhergestellte Anwendung als auch für temporäre Archive. Bestätigen Sie, dass Ihr Backup geöffnet und in einer separaten Datenbank wiederhergestellt werden kann. Behandeln Sie Anmeldeinformationen in Konfigurationsdateien als Geheimnisse und entfernen Sie temporäre Exportdateien aus öffentlich zugänglichen Verzeichnissen, sobald ihr Zweck erfüllt ist.

Planen und testen Sie eine vollständige Hosting-Restaurierung

Trennen Sie einen Hosting-Move von einer URL-Änderung

Wenn die Public Domain und die Pfade gleich bleiben, bleiben die vorhandenen Anwendungs-URLs in der Regel gültig. Aktualisieren Sie die Zieldatenbankverbindung, wenn der Host, der Datenbankname oder die Anmeldeinformationen abweichen. Testen Sie mit einer Methode, die den beabsichtigten Hostnamen beibehält, z. B. eine lokale Hosts-Datei-Override, bei der Ihr Operator ihn unterstützt; dies ändert nur das Testgerät, nicht das öffentliche DNS.

Scrollen Sie den Tisch bei Bedarf horizontal.

Behandeln Sie geänderte URLs, ohne serialisierte Daten zu brechen

Themes und Plugins können strukturierte Werte speichern, die sowohl Text als auch dessen Länge enthalten. Ein einfacher SQL-Textersatz kann die serialisierten Daten beschädigen, wenn eine alte URL und eine neue URL unterschiedlich lang sind. Verwenden Sie ein WordPress-fähiges Migrationstool oder WP-CLI-Suchersatz, wenn WP-CLI verfügbar ist, und überprüfen Sie den Umfang, bevor Sie eine Änderung anwenden.

Führen Sie auf einer wiederhergestellten Kopie zuerst einen Trockenlauf durch, inspizieren Sie die gemeldeten Tabellen und bewahren Sie einen Rollback-Export auf. WP-CLI bietet --dry-run und --skip-columns=guid; WordPress post GUIDs identifizieren Inhalte und sollten nicht als gewöhnliche Links umgeschrieben werden. Ein Multisite-Befehl benötigt einen bewussten Netzwerkumfang. Überprüfen Sie Plugin-eigene Tabellen und Konfigurationen separat, anstatt jede passende Zeichenfolge in jeder Datenbank zu ersetzen.

Testen Sie das Ziel, ohne Live-Nebenwirkungen auszulösen

Öffnen Sie die Homepage, einen Post, Suche, Medien, Login und den Verwaltungsbereich am Zielort. Überprüfen Sie Permalinks, fehlende Assets, HTTPS-Weiterleitungen und Anwendungsfehler. Testformulare und Speicherströme unter Verwendung einer geeigneten Testumgebung. Halten Sie eine isolierte Kopie vom Senden echter Kundennachrichten, vom Laden von Zahlungen oder vom Abfeuern von Produktionswebhooks während der Probe.

Überprüfen Sie für WooCommerce Produktvariationen, Warenkorbaktualisierungen, das Checkout-Verhalten und den Bestellverwaltungsbildschirm. Ein erfolgreiches Seitenladen ist nur ein Test. Vergleichen Sie das Ziel mit einer kurzen Liste von Geschäftsfunktionen, die Sie verwenden, und beheben Sie Unterschiede vor der endgültigen Kopie. Notieren Sie alle geänderten Anwendungseinstellungen zum Testen, damit sie vor dem Start überprüft werden können.

Überprüfen Sie WooCommerce Hosting und Store Setup

Schützen Sie Bestellungen und andere Schreibvorgänge während des DNS-Cutovers

Ein Shop kann nach dem Proben-Backup neue Bestellungen erhalten. Planen Sie eine kontrollierte Schreibpause oder eine anwendungsspezifische Endsynchronisation und erstellen Sie dann die endgültige konsistente Kopie. Vergleichen Sie die neuesten Bestelldatensätze und Zahlungsdienstleisterereignisse mit dem genehmigten Cutover-Punkt. Das Wiederherstellen einer älteren Datenbank über Live-Store-Daten kann Transaktionen verwerfen, die danach stattgefunden haben.

DNS Caches können Besucher während des Übergangs an verschiedene Ziele senden. Entscheiden Sie, welche Anwendung für Bestellungen maßgebend ist und wie spät geschrieben wird, bevor Sie die Datensätze wechseln. Halten Sie die vorherige Umgebung für Untersuchungen zur Verfügung, ohne beiläufig zwei beschreibbare Geschäfte wieder zu öffnen. Die DNS Der Leitfaden deckt Rekordänderungen ab; die Migrationsentscheidung benötigt auch einen klaren Eigentümer für Anwendungsdaten.

Überprüfen Sie DNS-Einträge, bevor Sie das Ziel verbinden

Überprüfen Sie den Start und definieren Sie ein verwendbares Rollback

Wiederholen Sie die Funktionsüberprüfungen durch öffentliche DNS, prüfen Sie Anwendungsfehler und überprüfen Sie neue Bestellungen oder Einreichungen am beabsichtigten Zielort. Wenn sich URLs geändert haben, testen Sie wichtige alte Adressen und deren Weiterleitungen. Überprüfen Sie die Indexierungseinstellungen, kanonischen URLs und die Sitemap, damit eine Staging-Beschränkung oder ein temporärer Hostname nicht in Produktion geht.

Legen Sie die Bedingungen fest, die ein Rollback rechtfertigen würden. Für einen Live-Shop verschiebt die Rückführung von DNS allein nicht neu erstellte Bestellungen zurück in die alte Datenbank. Abgleichen Sie neue Daten vor der Rückgabe des Datenverkehrs und führen Sie eine Aufzeichnung der endgültigen Migrationsentscheidung. Ziehen Sie die alte Installation erst zurück, nachdem der Zielort, die Wiederherstellungskopie und die Geschäftsunterlagen überprüft wurden.

• Endgültiges Backup-Set und Zieldatenbank entsprechen dem genehmigten Cutover.
• Öffentliche URLs, HTTPS, Formulare und Speicherfunktionen arbeiten am Zielort.
• Neue Bestellungen und Einreichungen werden in der beabsichtigten Anwendung aufgezeichnet.
• Temporäre Archive und Test-Only-Einstellungen wurden überprüft.

Vergleichen Sie WordPress Zielpläne