Wenn WooCommerce als mögliche Zielplattform bewertet wird, ist die Datenmigration als Übertragung in eine Commerce-Ebene zu verstehen, die innerhalb von WordPress arbeitet. Vertraute Datensätze wie Products, Customers, Orders, Coupons, Reviews, CMS Pages, Blog Posts, Medien und URLs stehen nicht für sich allein. Ihre Bedeutung kann von WooCommerce Product Types, WordPress Posts und Users, Taxonomien, Metadaten, plugin-eigenen Tabellen, Checkout-Feldern, der Order-Speicherarchitektur, Permalink-Regeln sowie Theme- oder Block-Ausgabe abhängen.
Die zentrale Entscheidung im Datenmodell lautet deshalb nicht, ob ein Quellfeld ein ähnlich benanntes Zielfeld besitzt. Entscheidend ist, ob die Quellbeziehung so dargestellt werden kann, dass WooCommerce und die umgebende WordPress-Website sie weiterhin interpretieren können. Ein Product muss kaufbar bleiben, eine Variation ihre Parent-Beziehung und Attribute-Kombination behalten, eine Order ihren Line-Item- und Customer-Kontext bewahren und ein plugin-eigener Wert einen definierten Zielnutzer haben, statt nur als ungenutzte Metadaten bestehen zu bleiben.
Die Datenbedeutung von WooCommerce reicht über Commerce und WordPress
WooCommerce erweitert WordPress, anstatt es durch eine isolierte Commerce-Datenbank zu ersetzen. Ein Product gehört gleichzeitig zu mehreren Ebenen: Es ist ein verkaufbares Objekt, ein WordPress-Content-Objekt, Mitglied von Produkttaxonomien, Träger von Metadaten, Teil von Medienbeziehungen, URL-Endpunkt und möglicher Anknüpfungspunkt für Plugins oder individuellen Code.
Diese mehrschichtige Architektur erklärt, weshalb zwei Datensätze, die in einem Export gleich aussehen, nach der Migration unterschiedlich funktionieren können. Ein in Post Meta gespeicherter Wert kann ein harmloses Anzeigeetikett, eine Variation-Kennung, ein ERP-Schlüssel, eine Checkout-Anweisung oder ein von einer Pricing-Extension verwendeter Input sein. Der Speicherort allein verrät nicht seine geschäftliche Rolle.
| Datenebene | WooCommerce-Interpretation | Entscheidung zur Zielbeziehung |
|---|---|---|
| Commerce-Datensätze | Products, Variations, Orders, Customers, Coupons, Steuern, Shipping Lines, Fees und Reviews | Beziehungen bewahren, die für Kauf, Support, Reporting und historische Interpretation benötigt werden. |
| WordPress-Datensätze | Posts, Pages, Users, Medien, Menüs, Blocks und wiederverwendbare Inhalte | Entscheiden, welche Datensätze zur Commerce Journey gehören und welche Teil eines separaten Website-Rebuilds sind. |
| Taxonomien | Product Categories, Tags, globale Attributes, Brands und Custom Taxonomies | Hierarchie, Filterung, Variation-Input und lockere Merchandising-Labels unterscheiden. |
| Metadaten | Core Fields, Custom Fields, Post Meta, User Meta und Order Meta | Jeden wichtigen Wert zum Objekt und Prozess zurückverfolgen, der ihn verwendet. |
| Plugins und Integrationen | Subscription-, Booking-, Membership-, Bundle-, Checkout-, Fulfillment- und externe Systemdatensätze | Übertragbare Daten von aktivem Verhalten trennen, das eine Ziel-Extension oder Integration benötigt. |
| Darstellung | Themes, Templates, Blocks, Shortcodes, Widgets und Page-Builder-Strukturen | Inhaltsbedeutung bewahren, ohne anzunehmen, dass die Darstellungsarchitektur der Quellplattform übertragbar ist. |
Ein sinnvolles Zielmodell macht diese Ebenen ausdrücklich sichtbar. Es vermeidet sowohl die Gleichsetzung aller WordPress-Daten mit Commerce-Daten als auch den umgekehrten Fehler, Products und Orders ohne die Website-Strukturen zu migrieren, die sie nutzbar machen.
Product Types definieren unterschiedliche geschäftliche Beziehungen
WooCommerce Product Types beschreiben, wie ein Artikel verkauft wird, nicht nur wie er dargestellt wird. Ein Simple Product steht für eine kaufbare Konfiguration. Ein Variable Product dient als Parent für Variations, die aus Attributes entstehen. Grouped Products behalten eigenständige Product-Identitäten und werden gemeinsam präsentiert. External oder Affiliate Products führen die Kaufhandlung aus dem Store heraus. Virtual- und Downloadable-Einstellungen verändern Versand- und Bereitstellungsbedeutung.
Extensions können zusätzliche Geschäftsstrukturen hinzufügen, etwa Subscriptions, Bookings, Memberships, Bundles, Composites, Deposits, zusätzliche Product-Eingabefelder oder Wholesale-Regeln. Solche Strukturen können auf der Product Page sichtbar sein, gehören aber nicht automatisch zum Core-WooCommerce-Product-Modell.
| Quellmuster | Wahrscheinliche WooCommerce-Abbildung | Beziehung, die klar bleiben muss |
|---|---|---|
| Eine SKU mit einem Preis und einer Bestandsposition | Simple Product | Product-Identität, Preis, Inventory, Tax, Bild, Category und URL. |
| Ein Product mit auswählbarer Größe, Farbe, Kapazität oder Oberfläche | Variable Product mit Variations | Parent Product, Variation Attributes, Variation SKU, Preis, Bestand, Bild und Verfügbarkeit. |
| Mehrere eigenständige Products werden gemeinsam beworben | Grouped Products oder Merchandising-Beziehung | Jedes Product behält eigene Identität und Kaufbarkeit. |
| Product wird auf einer anderen Website oder über einen anderen Prozess gekauft | External/Affiliate Product oder anderer Zielworkflow | Link und Call-to-Action behalten ihre beabsichtigte Bedeutung. |
| Personalisierung, Bundles, wiederkehrende Abrechnung, Bookings oder Memberships | Extension-eigene Product-Beziehung | Core Product Data bleiben von Extension-Datensätzen und aktiven Geschäftsregeln getrennt. |
Ein besonders schädlicher Übersetzungsfehler im Datenmodell wäre, jede Quelloption als Variation zu behandeln. Eine Variation ist ein kaufbares Child mit definierter Attribute-Kombination und kann eigenen Preis, SKU, Bestand, Bild, Abmessungen, Shipping Class, Tax Class oder Download-Einstellungen besitzen. Eine beschreibende Spezifikation, ein Filterwert, Texteingabefeld, Garantieauswahl, eine Geschenknotiz oder Plugin-Option benötigt möglicherweise ein anderes Ziel.
Auch der umgekehrte Fehler ist gravierend. Werden echte Quellvarianten zu einem Product mit lediglich beschreibenden Attributes abgeflacht, bleiben sichtbare Labels vielleicht erhalten, während kaufbare Identität, Bestandsverantwortung und Bedeutung der Order Lines verloren gehen.
Attributes, Categories, Tags und Taxonomien erfüllen unterschiedliche Aufgaben
WooCommerce verwendet Taxonomien, um Products und gemeinsame Werte zu organisieren. Product Categories tragen typischerweise die Haupt-Hierarchie und Landing-Page-Struktur. Product Tags schaffen lockerere Verbindungen. Globale Attributes erzeugen wiederverwendbare Terms, die Variation-Erstellung und Katalogfilter unterstützen können. Produktspezifische Attributes können ein einzelnes Product beschreiben, ohne zu gemeinsamen Taxonomie-Terms zu werden. Brands und andere Gruppierungen können je nach Store durch native Taxonomie, Extension, Custom Taxonomy oder Metadaten repräsentiert werden.
Eine Quellplattform kann ein Feld für mehrere dieser Zwecke verwenden. „Material“ kann bei einem Product eine auswählbare Variation, im gesamten Katalog eine filterbare Spezifikation und bei einem anderen Product nur beschreibender Text sein. Wird der Wert kopiert, ohne die passende WooCommerce-Rolle festzulegen, entstehen inkonsistente Administration und Produktsuche.
| Bedeutung auf der Quellplattform | Geeigneteres WooCommerce-Ziel | Warum die Unterscheidung wichtig ist |
|---|---|---|
| Hierarchische Produktfamilie | Product Category | Unterstützt Browse-Pfade, Landing Pages, Product-Zuordnung und URL-Struktur. |
| Wiederverwendbare Spezifikation für Filter | Global Attribute oder andere gesteuerte Taxonomie | Hält Terms über Products hinweg konsistent und für Katalogfunktionen verfügbar. |
| Merkmal, das kaufbare Versionen erzeugt | Variation-fähiges Attribute plus Variations | Verbindet die Auswahl mit den korrekten Child-Product-Daten. |
| Produktspezifische beschreibende Eigenschaft | Product-Level Attribute oder strukturierte Metadaten | Verhindert unnötige globale Terms. |
| Temporäres Kampagnenlabel | Tag, Merchandising-Regel oder Content-Beziehung | Verhindert, dass saisonale Logik zu dauerhafter Kataloghierarchie wird. |
| Brand, Kompatibilität, Branche oder Use Case | Brand/Custom Taxonomy, Attribute, Category oder Custom Structure | Das Ziel richtet sich danach, wie Customers und Mitarbeitende den Wert verwenden. |
Das Zielmodell sollte auch doppelte Term-Identitäten normalisieren. Werte wie „Blue“, „blue“ und „Navy Blue“ können unterschiedliche geschäftliche Auswahlmöglichkeiten, inkonsistente Quellerfassung oder eine bewusste Merchandising-Unterscheidung darstellen. Sie sollten weder zusammengeführt noch vervielfacht werden, ohne ihre Product- und Variation-Beziehungen zu verstehen.
Customers, Orders, Line Items und HPOS tragen historischen Kontext
WooCommerce-Customers können als WordPress Users, Billing-/Shipping-Identitäten, Guest Buyers oder durch Plugins und Integrationen erweiterte Datensätze auftreten. Orders verbinden diese Identitäten mit Line Items, Steuern, Fees, Coupons, Shipping Methods, Payment Labels, Refunds, Notes, Downloads und Metadaten. Historische Bedeutung verteilt sich somit über die Order und ihre Child-Datensätze, statt in einer einzigen Summary Row zu liegen.
High-Performance Order Storage speichert WooCommerce-Orders in eigenen Order-Tabellen, statt sich ausschließlich auf die traditionelle WordPress-Posts-/Post-Meta-Struktur zu stützen. Daraus folgt nicht, dass jedes Projekt andere Geschäftsfelder benötigt. Relevant ist, dass Order-bezogene Extensions und Custom Code unterschiedliche Speicherorte lesen oder schreiben können. Der vorgesehene Zielkontext und die Extension-Kompatibilität müssen daher verstanden sein, wenn individuelle Order-Daten erhalten werden sollen.
| Datensatzbeziehung | Zu bewahrende Bedeutung |
|---|---|
| Customer zu Order | Registrierter Account, Guest Identity, E-Mail-Historie, Billing-/Shipping-Kontext und Account-Suche. |
| Order zu Line Item | Product- oder Variation-Identität, Quantity, gekaufter Name, SKU, Preis, Tax, Discount und ausgewählte Options. |
| Order zu Totals | Subtotal, Fees, Coupons, Shipping, Taxes, Refunds und Interpretation der Gesamtsumme. |
| Order zu Status-Historie | Historisches Workflow-Label und Support-Kontext, ohne einen identischen zukünftigen Prozess zu unterstellen. |
| Order zu Metadaten | Gateway-Referenz, Fulfillment-ID, ERP-Schlüssel, Subscription-Referenz, Custom Checkout Value oder Admin Note. |
| Order zu Refund | Erstatteter Betrag, betroffene Items, Grund und soweit vorhanden Beziehung zur Originaltransaktion. |
Historische Payment- und Shipping-Labels dokumentieren, was im Quellshop passiert ist; sie sind keine Live-Konfiguration für Gateways oder Carrier. Ebenso stellt eine importierte Subscription-Referenz keinen wiederkehrenden Abrechnungsplan wieder her, und eine alte Fulfillment-ID implementiert keine Fulfillment-Integration. Die Datensätze bleiben nur dann nützlich, wenn ihre historische und betriebliche Bedeutung getrennt behandelt wird.
Coupons, Reviews, Medien und Content hängen von ihren Parent-Beziehungen ab
Unterstützende Datensätze gewinnen ihren Wert häufig stärker aus ihren Beziehungen als aus ihren Einzelwerten. Ein Review benötigt die richtige Product-Verknüpfung, Autor-Kontext, Rating, Datum und Moderationsstatus. Ein Bild benötigt die korrekte Product-, Variation-, Gallery-, Content-Block- oder Featured-Media-Beziehung. Ein Coupon kann in historischen Orders vorkommen und gleichzeitig eine für die Zukunft vorgesehene Regel darstellen. Ein Blog Post oder eine CMS Page kann Product-Links, eingebettete Blocks, Shortcodes, Medien und interne Navigationspfade enthalten.
| Unterstützender Datensatz | Beziehungsfrage |
|---|---|
| Reviews | Welchem Product gehört das Review, und welcher Autor, welches Rating, Datum und welcher Status bleiben relevant? |
| Medien | Ist das Asset Product Image, Variation Image, Gallery Item, Downloadable File, Featured Image oder eingebettetes Content Asset? |
| Coupons | Wird der Datensatz als historischer Order-Kontext, als aktive Promotion Rule oder für beides benötigt? |
| CMS Pages | Gehört der Inhalt zu Policy, Landing Page, Checkout Journey, Account Area oder einem Zielseiten-Rebuild? |
| Blog Posts | Welche Categories, Tags, Authors, Medien, internen Links und Product-Beziehungen benötigen Kontinuität? |
| Menüs und Blocks | Sind sie übertragbare Content-Beziehungen oder Präsentationsstrukturen, die neu aufgebaut werden sollten? |
Datei oder Text ohne Parent-Beziehung zu übertragen erzeugt verwaiste Daten. Ein Product Image in der Media Library ist nutzlos, wenn es nicht mehr dem Product oder der Variation zugeordnet ist, die es anzeigen soll. Ein Review ohne zuverlässige Product-Identität wird zu irreführendem Social Proof. Eine CMS Page kann vorhanden sein und dennoch aus der Customer Journey verschwinden, wenn Menü- und interne Links nicht Teil desselben Content-Modells waren.
Plugin- und Custom Data benötigen einen definierten Zielnutzer
WooCommerce-Stores sammeln häufig Custom Post Meta, User Meta, Order Meta, Custom Database Tables, Custom Taxonomies und plugin-eigene Entities an. Die richtige Behandlung beginnt mit Ownership: Welches Plugin, welcher Prozess, welches Team oder externe System erzeugt den Wert, und welche Zielkomponente wird ihn nach der Migration lesen?
| Custom-Data-Muster | Frage für das Zielmodell | Passende Datenentscheidung |
|---|---|---|
| Zusätzliches Feld an Core Product, Customer oder Order | Gibt es ein natives Feld, ein gesteuertes Metadatenfeld oder eine Ziel-Extension, die es verwendet? | Nur mappen, wenn Ziel und dauerhafte Zuständigkeit definiert sind. |
| Subscription-, Booking-, Membership- oder Bundle-Datensatz | Welche Parent-Product-, Customer-, Schedule-, Status- und Transaction-Beziehungen sind erforderlich? | Datensatzbeziehungen getrennt vom künftigen Extension-Verhalten erhalten. |
| Custom Checkout Field | Wird der Wert für Fulfillment, Support, Compliance oder Reporting benötigt? | Im Order- oder Customer-Kontext halten, den der Zielprozess verwendet. |
| Custom Table | Repräsentiert sie Entity, Beziehung, Log, Cache-Ausgabe oder veralteten Rest? | Bedeutungsvolle Entities übertragen und technischen Rest ohne Zielnutzer ausschließen. |
| ERP-, CRM-, PIM-, WMS-, Marketplace- oder Accounting-ID | Welches System bleibt autoritativ und wo lebt der systemübergreifende Schlüssel? | Stabile Identifikatoren als Integrationsdaten statt Storefront-Content bewahren. |
| Theme- oder Builder-Feld | Ist der Wert wiederverwendbarer Content oder quellenspezifisches Präsentations-Markup? | Dauerhaften Content extrahieren; Darstellung neu aufbauen, wenn die Quellstruktur kein Zieläquivalent hat. |
Ein Feld sollte nicht zu permanenten Zielmetadaten werden, nur weil es kopierbar ist. Ungenutzte Metadaten schaffen Mehrdeutigkeit und erschweren spätere Integrationsarbeit, weil nicht klar ist, welche Werte noch autoritativ sind. Umgekehrt dürfen geschäftskritische externe Identifikatoren nicht verworfen werden, nur weil sie in der Storefront unsichtbar sind.
URLs und Content-Pfade verbinden WordPress-Struktur mit Commerce
WooCommerce übernimmt WordPress-Verhalten für Permalinks, Slugs, Taxonomien, Medien und Content. Product URLs, Category Archives, Tag Archives, Brand Pages, CMS Pages, Blog Posts, Account Routes, Checkout Paths, Media URLs, Canonical Fields, Index Controls und strukturierte Metadaten können zusätzlich von Themes und SEO-Plugins beeinflusst werden.
Die Datenmodellfrage betrifft die Identität hinter jedem Pfad. Eine Quell-URL kann ein Product, eine Product Category, ein Brand Archive, eine Page, einen Post, eine Campaign Landing Page oder einen plugin-generierten Endpoint identifizieren. Die Ziel-URL sollte zu dem Datensatz oder Customer Intent führen, der diese Identität ersetzt. Nur Slugs zu kopieren, ohne die richtige Objektbeziehung zu erhalten, kann Kollisionen oder irreführende Pfade erzeugen.
Dasselbe gilt für interne Links. Blog Posts und Pages können auf Products, Categories, Cart Actions, Downloads oder Account Pages verweisen. Eine Content-Migration, die HTML bewahrt, aber alte Source Routes darin stehen lässt, erhält die Beziehung zwischen Content und Commerce nicht.
Beziehungsentscheidungen müssen dem Field Mapping vorausgehen
Ein WooCommerce-Mapping wird belastbar, wenn jeder wichtige Quellwert einem von vier Ergebnissen zugeordnet werden kann:
- Native WooCommerce-Beziehung: Der Wert gehört zu einer Core-Struktur für Product, Variation, Customer, Order, Taxonomy, Review, Coupon, Content oder Medien.
- Gesteuerte Metadaten: Der Wert bleibt als eindeutig verantwortetes Custom Field an einem bekannten Objekt nützlich.
- Externe oder Extension-eigene Beziehung: Der Wert gehört zu Plugin, Integration oder System, das ihn weiterhin verwenden muss.
- Präsentations- oder Legacy-Rest: Der Wert sollte neu aufgebaut, archiviert oder ausgeschlossen werden, weil er keine dauerhafte Zielbedeutung hat.
| Entscheidungsbereich | Starke Frage für das Zielmodell |
|---|---|
| Products und Variations | Welcher Datensatz besitzt kaufbare Identität, Preis, Bestand, SKU, Medien und ausgewählte Attributes? |
| Taxonomien | Welche Strukturen stehen für Hierarchie, Filterung, Variation Terms, Brands oder temporäres Merchandising? |
| Customers und Orders | Welche Identitäten, Line-Item-Beziehungen, Totals, Notes und externen Referenzen bleiben betrieblich nützlich? |
| Plugin-Daten | Welche Ziel-Extension, welcher Prozess oder welches System liest den migrierten Wert? |
| Content und Medien | Welches Commerce-Objekt, welcher Pfad oder welche Customer Journey gibt dem Asset seine Bedeutung? |
| URLs | Welches Zielobjekt oder welcher Intent ersetzt jede wichtige Source Route? |
Dieser Ansatz verhindert, dass Datenvolumen mit struktureller Vollständigkeit verwechselt wird. Der WooCommerce-Zielshop kann anschließend aus einem kohärenten Beziehungsmodell arbeiten statt aus einer Sammlung kopierter Felder.
Fazit
Die Unterschiede im WooCommerce-Datenmodell entstehen aus dem Zusammenspiel von Commerce-Datensätzen und WordPress-Architektur. Product Types, Variations, Attributes, Taxonomien, Customers, Orders, HPOS, Coupons, Reviews, Medien, Content, URLs, Plugins, Custom Tables und externe Identifikatoren bestimmen mit, was ein migrierter Wert bedeutet.
Ein starkes Zielmodell erhält Parent-Child-Beziehungen, gibt jedem Taxonomie- und Metadatenwert eine klare Aufgabe, trennt historische Datensätze von Live-Konfiguration und weist jedem Custom Field oder Plugin-Datensatz einen dauerhaften Verantwortlichen zu. So entsteht ein WooCommerce-Store, dessen Daten für Customers, Mitarbeitende, Extensions und verbundene Systeme verständlich bleiben.
Häufige Fragen
Warum werden WooCommerce-Products nicht wie generische Product-Datensätze behandelt?
Ein WooCommerce-Product ist zugleich WordPress-Content-Objekt, Teilnehmer an Taxonomien, Metadatenträger, Medienbeziehung, URL-Endpunkt und möglicher Plugin-Anknüpfungspunkt. Seine Bedeutung hängt von diesen verbundenen Ebenen ab, nicht nur von Product-Feldern.
Was ist der Unterschied zwischen einem WooCommerce-Attribute und einer Variation?
Ein Attribute beschreibt eine Eigenschaft oder stellt wiederverwendbare Terms bereit. Eine Variation ist ein kaufbares Child, das aus einer definierten Attribute-Kombination entsteht und eigene SKU, Preis, Bestand, Bild, Tax Class, Shipping-Daten oder Download-Einstellungen besitzen kann.
Warum ist HPOS für migrierte Orders wichtig?
HPOS verändert die Speicherarchitektur für WooCommerce-Orders. Die geschäftliche historische Bedeutung kann gleich bleiben, aber individuelle Order-Metadaten und Extensions müssen im Speicher-Kontext verstanden werden, den der Zielshop verwendet.
Sollte jedes Feld eines WooCommerce-Plugins migriert werden?
Nein. Ein Plugin-Feld sollte nur erhalten werden, wenn Parent-Datensatz, geschäftliche Bedeutung, Ziel und dauerhafter Nutzer bekannt sind. Cache-Ausgaben, veraltete Einstellungen und technischer Rest sollten nicht zu permanenten Zieldaten werden.
Wie sollten WooCommerce-Content und Medien mit Products verbunden werden?
Erhalten werden sollten die Beziehungen, die den Content nutzbar machen: Product- und Variation-Galleries, Featured Images, Downloadable Files, eingebettete Product Blocks, interne Links, Blog-Post-Referenzen und Pfadverantwortung. Assets ohne diese Links werden zu verwaistem Content.
Wie sollten Identifikatoren externer Systeme dargestellt werden?
Stabile ERP-, CRM-, PIM-, WMS-, Marketplace-, Accounting- oder Fulfillment-IDs sollten als gesteuerte Integrationsdaten am richtigen Product, an der richtigen Variation, am Customer oder an der Order erhalten werden. Sie dürfen nicht mit WooCommerce-Entity-IDs verwechselt oder ohne geschäftlichen Grund als Storefront-Content dargestellt werden.