Executive Summary:
Bei parallelem Betrieb von Entwicklungs- und Live-Systemen in WooCommerce entstehen zwei unterschiedliche Datenstände: ein technisch optimierter Dev-Stand und ein fortlaufend wachsender Live-Stand mit neuen Bestellungen.
Ein sicherer Go-Live erfordert daher keinen Komplett-Overwrite, sondern einen kollisionsfreien Delta-Abgleich, bei dem ausschließlich neue Daten seit einem Stichtag übernommen werden, während technische Optimierungen erhalten bleiben.
Wenn zwei Systeme parallel arbeiten:
Häufig haben wir als WordPress Agentur die Aufgabe, bestehende WordPress Systeme zu überarbeiten. Entweder im Rahmen einer technischen Überarbeitung (z. B. Ladezeitoptimierung) oder bei der Zusammenlegung von zwei Websites zu einem harmonischen Gesamtsystem.
Wenn man verschiedene WordPress Systeme zusammenführt, dann kommt es beim Einsatz eines WooCommerce System häufig dazu, dass die technischen Arbeiten parallel zum laufenden Betrieb des existierenden Onlineshops durchführt. Die Arbeiten werden natürlich im Hintergrund auf einem vor Suchmaschinen abgeschirmten Schattenserver durchgeführt. Dabei wird der aktuelle Stand des bestehenden Systems zum Zeitpunkt der Kopie “eingefroren”.
Arbeits-System (Dev-Server*):
Die höchste Bestellnummer sei im Beispiel die Nummer 20.465. Diese ist und bleibt im kopierten Arbeitssystem auch bestehen. Normal ändert sich die Anzahl der Bestellungen (Bestell-IDs) nicht. Ebenso ändern sich auch die Anzahlen der Seiten (Seiten-IDs), oder die Anzahlen der Blogeinträge (Blog-IDs) nicht. Diese werden jeweils nur dann +1 hochgezählt, wenn man zu Test-Zwecken eine Testbestellung ausführt. Nehmen wir an, im Zuge der Arbeiten werden noch vier Test-Bestellungen ausgeführt, um die optimierte Funktionsweise zu testen. Die höchste Bestellnummer wird am Ende also die 20.465 + 4 also Bestell-ID 20.469 sein.
* Dev-Server steht für “Development-Server”, also den Entwicklungs-Server, auf dem die Arbeiten durchgeführt werden (abgeschirmt vor Google, damit es keine duplizierten Inhalte in der Suchmaschine gibt).
Produktiv-System (Live-Server):
Anders als am Dev-Server wird am Live-Server der Shop natürlich produktiv weiter betrieben. Beitrags-IDs für neue Blogbeiträge, Seiten-IDs für neue Inhaltsseiten und natürlich auch Bestell-IDs für neue Bestellungen werden munter weiter hochgezählt. Der Rubel muss rollen, daher lässt man den Shop typischerweise normal weiter laufen, ohne den Shop in einen Wartungsmodus zu versetzen — dann könnten nämlich keine Bestellungen mehr angeommen werden. Der Zähler für die eindeutigen IDs wird daher mit jeder neuen Bestellung und jedem Arbeiten an der Website beim Speichern eines Zwischenstandes inkrementiert.
Nehmen wir also im Beispiel an, dass einige Blogartikel veröffentlicht werden, Seitenüberarbeitungen erfolgen und diverse Bestellungen eingehen, dann kann die neueste Bestell-ID gut und gerne +200 Nummern weiter sein, also bei 20.465 + 200, also Bestell-ID 20.665 liegen.
Zusammenführen der beiden Welten:
Nachdem die Arbeiten am Dev-Server abgeschlossen sind, soll der technisch neue und überarbeitete Stand auf den Live-Server überführt werden. Dabei ist es wichtig, dass die neu eingegangenen Bestellungen seit dem Zeitpunkt des Erstellens der Arbeitskopie nicht verloren gehen. Eine Zusammenführung unter Beibehaltung der Bestellungen ist das Ziel. Eingegangene Bestellungen, stornierte Bestellungen, Retouren, genutzte Rabattcodes, Affiliate-Bestellungen, telefonisch platzierte Orders oder auch Wiederkäufe dürfen nicht verloren gehen. Die Zusammenführung muss daher technisch sauber und kontrolliert erfolgen.
Wir teilen unser Wissen und zeigen daher die wichtigsten Schritte für eine Migration von WooCommerce zwischen Dev-Server und Live-Server.
Falsch wäre: Überspielen Dev-Server → Live-Server:
Bei einem einfachen Überspielen des Dev-Servers auf den Live-Server ist klar, dass die zwischenzeitlich eingegangenen Bestellungen verloren gehen würden. Die neueste ID wäre in diesem Fall die Nummer 20.469, sodass die letzten 200 Änderungen entfallen würden.
Falsch wäre ebenso: Einfaches Überspielen Live-Server → Dev-Server:
Bei Überspielen des Live-Servers auf den Dev-Server würde man natürlich jegliche Änderungen, das technische Upgrade oder die Optimierungen am Dev-Server wieder hinfällig machen. Zwar wären dann die Bestellungen auf dem Stand, doch alle technischen Anpassungen wären dahin. Auch dies ist kein funktionsfähiger Weg.
Einzig richtiger Weg: Delta-Abgleich vom Live-Server → Dev-Server → dann komplett zum Live-Server:
Puh, diese Überschrift hat’s in sich! Wir benötigen also sowohl die aktuellen Bestellungen und Änderungen, welche seit dem Erstellen der Arbeitskopie (=Stichdatum) angefallen sind. Dies können wir über die Datenbank erfahren. Es gibt das Stichdatum, ab dem wir also neue Datenbankinhalte beziehen wollen.
Zugleich wollen wir die technisch optimierte Version des Dev-Servers beibehalten. Der erste Schritt ist also ein Delta-Abgleich aus der Datenbank des Live-Servers zum Dev-Server. Dabei kann es allerdings zu Problemen kommen, denn wenn wir das Delta direkt einspielen würden, würde es zu ID-Konflikten kommen. Ein großes Problem wären also Kollisionen im ID-Bereich. Daher ist ein „1:1‑Import mit festen IDs“ riskant bzw. schlägt spätestens beim Abgleichz zwischen Live-wp_posts.ID zu Dev-wp_posts.ID fehl. Somit ist das Hochzählen der Post-IDs grundsätzlich richtig. Doch bitte nicht per Suchen/Ersetzen in den Datenbank-Dumps, weil man dabei sehr leicht Zahlen innerhalb von meta_value (Serialisierungen, Texte, JSON) kaputt macht.
Die kollisionssichere, saubere Lösung ist:
Import in temporäre Tabellen und dann per SQL mit Offsets in die echten Tabellen kopieren. So werden nur die ID-Spalten arithmetisch verschoben, ohne meta_value anzufassen. Dies umgeht mögliche ID-Konflikte. Damit wir die Lösung nicht nur ankündigen, sondern auch liefern, folgen nun die notwendigen Datenbank-Snippets. Es wird angenommen, dass folgende vier Datenbank-Statements ausgeführt wurden, um die Daten ab dem Stichtag zu sichern.
Wichtiger Hinweis: Arbeiten Sie niemals in der Datenbank, wenn Sie sich damit nicht auskennen. Bitte fertigen Sie immer vollständige Sicherungen an, damit Sie im Fall eines technischen Problems zurückstellen können.
SQL-Statement 1:
SELECT *
FROM wp_posts
WHERE post_type = 'shop_order'
AND post_date > '2025-12-05 11:55:15';
SQL-Statement 2:
SELECT pm.*
FROM wp_postmeta pm
JOIN wp_posts p ON p.ID = pm.post_id
WHERE p.post_type = 'shop_order'
AND p.post_date > '2025-12-05 11:55:15';
SQL-Statement 3:
SELECT oi.*
FROM wp_woocommerce_order_items oi
JOIN wp_posts p ON p.ID = oi.order_id
WHERE p.post_type = 'shop_order'
AND p.post_date > '2025-12-05 11:55:15';
SQL-Statement 4:
SELECT oim.*
FROM wp_woocommerce_order_itemmeta oim
JOIN wp_woocommerce_order_items oi ON oi.order_item_id = oim.order_item_id
JOIN wp_posts p ON p.ID = oi.order_id
WHERE p.post_type = 'shop_order'
AND p.post_date > '2025-12-05 11:55:15';
Delta-Abgleich: Live eingegangene Bestellungen in temporäre Tabelle schreiben:
Die Ziel-Tabelle hat in. unserem Beispiel ein anderes Präfix, nämlich “dss_” statt “wp_”. Bitte achten Sie daher darauf, welches Präfix in Ihrer Datenbank-Installation verwendet wird. Adaptieren Sie daher bitte basierend auf Ihrem Zielsystem.
Schritt 1: Temp-Tabellen anlegen (Struktur 1:1 wie Original)
DROP TABLE IF EXISTS dss_tmp_posts;
DROP TABLE IF EXISTS dss_tmp_postmeta;
DROP TABLE IF EXISTS dss_tmp_order_items;
DROP TABLE IF EXISTS dss_tmp_order_itemmeta;
CREATE TABLE dss_tmp_posts LIKE dss_posts;
CREATE TABLE dss_tmp_postmeta LIKE dss_postmeta;
CREATE TABLE dss_tmp_order_items LIKE dss_woocommerce_order_items;
CREATE TABLE dss_tmp_order_itemmeta LIKE dss_woocommerce_order_itemmeta;
Schritt 2: die 4 Dump-Dateien für den Import anpassen
15 SQL-Abfragen erfolgreich ausgeführt. (0.019 s)
19 SQL-Abfragen erfolgreich ausgeführt. (0.175 s)
15 SQL-Abfragen erfolgreich ausgeführt. (0.012 s)
15 SQL-Abfragen erfolgreich ausgeführt. (0.036 s)
Schritt 3: Offsets berechnen und in echte Tabelle überführen
Dieser Befehl ist etwas länger und daher sauber kommentiert. Sie können die einzelnen Segmente auch nacheinander ausführen. Stellen Sie vorher sicher, dass die von Ihnen gerade importierten Tabellen angelegt wurden. Bei uns haben die eben das oben genannte Präfix “dss_”, das kann bei Ihnen anders lauten. Es ist übrigens “Best Practice”, nicht “wp_” zu verwenden, wie in jeder Standardinstallation. Daher nutzen wir ein randomisiertes und spezifiziertes Datenbank-Präfix in WordPress und WooCommerce für jede/n unserer Kund:innen.
-- Offsets so wählen, dass alles oberhalb der aktuellen Dev-Maxima landet
SET @posts_offset :=
(SELECT IFNULL(MAX(ID),0) FROM dss_posts) + 1
- (SELECT MIN(ID) FROM dss_tmp_posts);
SET @pm_offset :=
(SELECT IFNULL(MAX(meta_id),0) FROM dss_postmeta) + 1
- (SELECT MIN(meta_id) FROM dss_tmp_postmeta);
SET @oi_offset :=
(SELECT IFNULL(MAX(order_item_id),0) FROM dss_woocommerce_order_items) + 1
- (SELECT MIN(order_item_id) FROM dss_tmp_order_items);
SET @oim_offset :=
(SELECT IFNULL(MAX(meta_id),0) FROM dss_woocommerce_order_itemmeta) + 1
- (SELECT MIN(meta_id) FROM dss_tmp_order_itemmeta);
-- optional: Offsets anzeigen
SELECT @posts_offset AS posts_offset, @pm_offset AS postmeta_offset,
@oi_offset AS order_items_offset, @oim_offset AS order_itemmeta_offset;
-- 1) posts (Bestellungen)
-- Wichtig: post_parent bei Refunds/Child-Posts mitverschieben, falls > 0
INSERT INTO dss_posts (
ID, post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt,
post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged,
post_modified, post_modified_gmt, post_content_filtered, post_parent, guid,
menu_order, post_type, post_mime_type, comment_count
)
SELECT
ID + @posts_offset,
post_author, post_date, post_date_gmt, post_content, post_title, post_excerpt,
post_status, comment_status, ping_status, post_password, post_name, to_ping, pinged,
post_modified, post_modified_gmt, post_content_filtered,
CASE WHEN post_parent > 0 THEN post_parent + @posts_offset ELSE 0 END,
guid,
menu_order, post_type, post_mime_type, comment_count
FROM dss_tmp_posts;
-- 2) postmeta (Order-Metadaten)
INSERT INTO dss_postmeta (meta_id, post_id, meta_key, meta_value)
SELECT
meta_id + @pm_offset,
post_id + @posts_offset,
meta_key,
meta_value
FROM dss_tmp_postmeta;
-- 3) order_items (Positionen)
INSERT INTO dss_woocommerce_order_items (order_item_id, order_item_name, order_item_type, order_id)
SELECT
order_item_id + @oi_offset,
order_item_name,
order_item_type,
order_id + @posts_offset
FROM dss_tmp_order_items;
-- 4) order_itemmeta (Position-Metadaten)
INSERT INTO dss_woocommerce_order_itemmeta (meta_id, order_item_id, meta_key, meta_value)
SELECT
meta_id + @oim_offset,
order_item_id + @oi_offset,
meta_key,
meta_value
FROM dss_tmp_order_itemmeta;
Auch hier gibt es wieder Erfolgsmeldungen, nach jedem Block wie folgt mit einer erstaunlich kurzen Ausführungszeit:
Abfrage ausgeführt, 43 Datensätze betroffen. (0.006 s)
Abfrage ausgeführt, 2 115 Datensätze betroffen. (0.184 s)
Abfrage ausgeführt, 87 Datensätze betroffen. (0.001 s)
Abfrage ausgeführt, 832 Datensätze betroffen. (0.020 s)
DROP TABLE IF EXISTS dss_tmp_posts;
DROP TABLE IF EXISTS dss_tmp_postmeta;
DROP TABLE IF EXISTS dss_tmp_order_items;
DROP TABLE IF EXISTS dss_tmp_order_itemmeta;
DELETE FROM dss_options WHERE option_name LIKE '_transient_wc_%';
DELETE FROM dss_options WHERE option_name LIKE '_site_transient_wc_%';
Dies wird mit der finalen SQL-Erfolgs-Rückmeldung quittiert:
Abfrage ausgeführt, 23 Datensätze betroffen. (0.017 s)
Finaler Check nach so viel Datenbank-Arbeiten:
Damit wir sicherstellen können, dass der Delta-Abgleich korrekt funktioniert hat, prüfen wir das in unserer WordPress Agentur für WooCommerce Systeme mit dem folgenden SQL-Befehl. Das gesamte Vorgehen arbeitet kollisionsfrei, denn wir verschieben nur echte ID-Felder (numerische Spalten). Das Feld meta_value bleibt bitgenau unangetastet (das ist enorm wichtig bei serialisierten Daten). Man braucht kein manuelles Mapping. Kollisionen sind ausgeschlossen, weil alles oberhalb der aktuellen Maxima landet. Das wird somit nur höhere Werte einspielen. Daher nutzen wir das selbe Stichdatum, um die Daten “vor und nach dem Erstellen des Entwicklungsservers” abzugleichen.
-- Wie viele Orders sind neu dazugekommen?
SELECT COUNT(*) FROM dss_posts WHERE post_type='shop_order' AND post_date > '2025-12-05 11:55:15';
-- Stimmt die Referenzierung? (Items müssen auf existierende Orders zeigen)
SELECT COUNT(*) AS orphan_items
FROM dss_woocommerce_order_items oi
LEFT JOIN dss_posts p ON p.ID = oi.order_id
WHERE p.ID IS NULL;
Im SQL-Ergebnis sollte orphan_items nun 0 sein.
Sollten Sie auch bei Ihrem WordPress System mit WooCommerce Shop einen sauberen Transfer und Delta-Abgleich Ihrer Daten benötigen, kontaktieren Sie uns jederzeit gerne. Wir helfen Ihnen gerne weiter und freuen uns auf Ihre Anfrage.
Persönliches Gespräch gefällig?
Autor
Prof. Dr. Alexander Lutz, Professor für Big Data und KI an der FOM München, Doktor der Humangenetik und Anthropologie, ehemaliger Onlinespiele-Designer und natürlich Gründer und Inhaber der Agentur Die NEOs. Neben den Themen der künstlichen Intelligenz und deren Einsatzmöglichkeiten in der Praxis konzentriert sich Alexander auf die Kundenkommunikation. Neue Problemfelder oder technische Innovationen bereitet er so auf, dass der Nutzen für unsere Kunden deutlich wird. Er schläft zeitverantwortlich und agiert schnell, sein Motto: “Tue es, oder tue es nicht. Es gibt kein Versuchen.”
