Wenn WooCommerce als mögliche Zielplattform in Betracht gezogen wird, beschreibt die Vorbereitung, welche Nachweise, Entscheidungen und Zielkonfigurationen vor der Migration geklärt werden müssen.
Wenn WooCommerce als Zielplattform ausgewählt werden soll, muss die Vorbereitung den künftigen Store als Commerce-Anwendung innerhalb von WordPress behandeln. Products und Variationen nutzen WordPress-Infrastruktur gemeinsam mit Content, ihre geschäftliche Bedeutung stammt jedoch aus WooCommerce und dessen Erweiterungen. Orders können High-Performance Order Storage oder Legacy-WordPress-Post-Speicherung verwenden. Customers können registrierte WordPress Users oder Guest-Transaktionsidentitäten sein. Subscriptions, Bookings, Bundles, Memberships, Wholesale Pricing, Custom Checkout Fields und Marketplace Datensätze können in extension-spezifischen Strukturen liegen.
Das Vorbereitungspaket sollte erklären, wo jeder Commerce-Datensatz liegt, von welchen Product- oder Transaktionsbeziehungen er abhängt und welches System das fortbestehende Verhalten verantwortet. Es sollte wiederherstellbare Backups, aktuelle Speichereinstellungen, Nachweise zur Erweiterungskompatibilität, repräsentative Datensätze und eine eindeutige Freigabebedingung für jeden wesentlichen Commerce-Bereich enthalten. WordPress-CMS-Content bleibt verbunden, wird aber nicht innerhalb des WooCommerce-Scopes dupliziert.
WooCommerce-Grenze, Zugriff und Source Snapshot festlegen
Trennen Sie zunächst WooCommerce-Core-Datensätze von WordPress-CMS-Datensätzen, erweiterungseigenen Commerce-Datensätzen und externen Systemen. Bestätigen Sie Quellshop URL, WordPress-Installation beziehungsweise Multisite Site, aktive WooCommerce-Version, aktives Theme, aktivierte Erweiterungen, Custom Code und aktuelle autoritative Systeme für Products, Stock, Customers, Orders, Pricing, Tax, Shipping, Payment und Auftragsabwicklung.
| Vorbereitung | Verantwortlicher | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|---|
| WooCommerce-Commerce-Grenze definieren | Store Verantwortlicher und Technical Lead | Entity-Liste für Products, Variationen, Customers, Orders, Coupons, Reviews, Refunds, Downloads, Erweiterungen und externe Systeme | Jeder Commerce-Datensatz besitzt einen Core-, Erweiterung-, External-, Archive- oder Exclusion-Verantwortlicher. |
| Administrations- und Hosting-Zugriff bestätigen | Store Administrator und Hosting Verantwortlicher | WordPress-/WooCommerce-Adminzugriff, Datenbankzugriff oder Exportpfad, Upload-/Download-Dateien und Erweiterung-Administration | Das Team kann ausgewählte Datensätze prüfen und die Source bei Bedarf wiederherstellen. |
| WooCommerce System Status Report sichern | technisch Verantwortlicher | Datierter Bericht mit WooCommerce, WordPress, PHP, Datenbank, Theme, Template Overrides, Erweiterungen und Environment | Software- und Erweiterung-Kontext der Source ist vor Änderungen dokumentiert. |
| Vollständigen Source Snapshot erstellen | Hosting- oder Database Verantwortlicher | Datiertes Datenbank-Backup, wp-content, Product Downloads, Medien, Konfigurationsreferenzen und Restoration Verantwortlicher |
Backup-Umfang, Datum, Speicherort, Wiederherstellungsprozess und Aufbewahrung sind dokumentiert. |
| Autoritative externe Systeme erfassen | Integration Verantwortliche | Zuordnung von ERP-, PIM-, WMS-, CRM-, Tax-, Payment-, Shipping-, Auftragsabwicklung-, Marketplace- und Accounting-IDs | Fortbestehende Systems of Datensatz und verwendete Schlüssel sind eindeutig. |
Wenn sich der Quellshop weiter verändert, dokumentieren Sie Snapshot-Zeitpunkt und Datensatztypen, die danach entstehen oder geändert werden können. Dieses Änderungsprotokoll hält die Source-Grenze fest und zeigt, welche Datensätze einen aktualisierten Source Snapshot benötigen können.
Product Types, Attribut, Variationen und verkaufbare Identität inventarisieren
WooCommerce Core unterstützt Simple, Grouped, External/Affiliate, Variable, Virtual und Downloadable Product-Verhalten. Erweiterungen können Subscriptions, Bookings, Bundles, Composite Products, Memberships, Deposits, Product Customization, Wholesale-Regeln und Marketplace Ownership ergänzen. Inventarisieren Sie jeden tatsächlich verwendeten Product Type und benennen Sie die Komponente, der er gehört.
Variable Products erfordern besondere Sorgfalt. Globale oder produktspezifische Attribut können Variationen definieren; jede Variation kann eigene SKU, Identifikatoren, Enabled State, Regular/Sale Price, Cost, Downloadable/Virtual State, Weight, Dimensions, Shipping Class, Tax Class, Image, Stock, Backorder Rule und Low-Stock Threshold besitzen.
| Vorbereitung | Verantwortlicher | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|---|
| Product Types inventarisieren | Catalog Verantwortlicher | Anzahl und Beispiele für Simple, Grouped, External, Variable, Virtual, Downloadable und erweiterungseigene Types | Jeder aktive Type hat eine Zielabbildung oder bewusste Exclusion. |
| Product- und Variation-Identität mappen | Catalog und Integration Verantwortliche | Parent Product IDs, Variation IDs, SKUs, GTIN/UPC/EAN/ISBN soweit genutzt, externe Keys und Duplicate-Identifier-Report | Jede verkaufbare Einheit lässt sich in verbundenen Systemen eindeutig unterscheiden und abgleichen. |
| Attribut und Variation-Erzeugung dokumentieren | Catalog Verantwortlicher | Global Attribut, Custom Attribut, Terms, Default Attribut, Variation-Kombinationen und „Any attribute“-Muster | Attribut-Vokabular und reale verkaufbare Kombinationen sind vor dem Mapping bekannt. |
| Kommerzielle Variation-Daten erfassen | Catalog und Bestand Verantwortliche | Repräsentative Variation-Daten für Preis, Sale Price, Image, Stock, Backorder, Weight, Dimensions, Tax, Shipping Class und Downloads | Geschäftliche Werte sind bewusst dem Parent- oder Variation-Level zugewiesen. |
| Erweiterte Product Ownership erfassen | Erweiterungsverantwortlicher | Erweiterung Name/Version, Product Subtype, Custom Tables/Meta, Related Products und Betriebsverhalten | Subscription-, Booking-, Bundle-, Composite-, Add-on-, Wholesale- oder Marketplace-Daten haben einen definierten Verantwortlicher. |
Verwenden Sie repräsentative Product-Familien statt nur Gesamt-Exports: mindestens ein Simple Product, ein Variable Product mit mehreren Attribut, gegebenenfalls ein Virtual/Downloadable Product und jedes wesentliche extension-definierte Product-Muster.
Bestand, Pricing, Taxonomien, Medien und Product Files vorbereiten
Product-Bereitschaft hängt außerdem von Classification, Stock Authority, Pricing Context, Media und Files ab. Categories, Tags, globale Attribut, Shipping Classes, Tax Classes, Cross-Sells, Upsells, Grouped Products und verwandte Datensätze müssen getrennt bleiben. Bestand kann auf Product-Level, Variation-Level, gemischt oder durch Warehouse beziehungsweise Erweiterung gepflegt werden.
| Bereich | Vorzubereitender Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|---|
| Bestand Authority | Product-/Variation-Stock-Settings, Backorders, Low-Stock-Werte, externe Warehouse IDs und Synchronization Verantwortlicher | Bestand Verantwortlicher | Jede verkaufbare Einheit hat genau einen erklärten autoritativen Stock-Pfad. |
| Preise und Promotions | Base-/Sale Prices, Schedules, Quantity-/Group Pricing, Erweiterungsverantwortlicher und Currency Context | Commercial Verantwortlicher | Preise sind als Core Product/Variation Values, Erweiterung Rules oder External-System Values klassifiziert. |
| Categories und Product Attribut | Hierarchie, Term Slugs, Product Assignments, Attribut-Nutzung für Variationen/Filter und obsolete Terms | Catalog Verantwortlicher | Taxonomien bleiben mit den richtigen Products verbunden, ohne unabhängige Vokabulare zu vermischen. |
| Product Media | Featured Image, Galleries, Variation Images, Alt Text, Attachment IDs, Remote Assets und Missing-File-Report | Catalog/Media Verantwortliche | Wichtige Product- und Variation-Medien sind zugänglich und ihre Parent-Beziehungen bekannt. |
| Downloadable Files | File URLs/Paths, Access Rules, Limits, Expiry, Source Availability und Product-/Variation-Links | Digital Product Verantwortlicher | Jeder beizubehaltende Download hat eine zugängliche Datei und einen definierten Product-/Variation-Verantwortlicher. |
| Shipping und Tax Classification | Shipping Classes, Tax Classes, Virtual State, Dimensions, Weight und besondere Erweiterung Rules | Operations Verantwortlicher | Klassifizierungsnachweise sind vollständig, ohne aktuelle Konfiguration mit historischen Order-Daten zu verwechseln. |
Der Product CSV Exporter kann als Vorbereitung hilfreich sein, sollte aber durch Product-Type-, Erweiterung-, File- und Relationship-Inventare ergänzt werden. Ein Flat CSV kann nicht jede erweiterungseigene Product-Struktur oder externe Systemabhängigkeit vollständig darstellen.
Customers, Accounts, Addresses und Commerce Roles vorbereiten
WooCommerce-Customers können registrierte WordPress Users oder als Guest Buyers in Orders gespeichert sein. Registrierte Customers können Billing-/Shipping-Adressen, Account Metadata, Order History, Download Permissions und Erweiterungsbeziehungen besitzen. WordPress Roles wie Customer oder Shop Manager bestimmen Zugriff; Membership-, Wholesale-, Vendor-, Loyalty- oder Subscription-Erweiterungen können zusätzliche Profile und Regeln hinzufügen.
| Vorbereitung | Verantwortlicher | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|---|
| Registrierte Customers und Guest Buyers trennen | Customer-Service Verantwortlicher | Anzahlen, Stichproben, E-Mail-/Telefonqualität, Account IDs und Order-Beziehungen | Guest Orders bleiben ohne erfundene Accounts erhalten; registrierte Customers bleiben verknüpfbar. |
| Customer Addresses vorbereiten | Customer-Service Verantwortlicher | Billing-/Shipping-Felder, Multiple-Address-Erweiterungen, Country/State-Formate und repräsentative Customers | Aktuelle Account-Adressen werden von historischen Order Snapshots unterschieden. |
| Commerce Roles und Profiles inventarisieren | Store Administrator und Erweiterungsverantwortliche | WordPress Roles, Custom Capabilities, Wholesale-/Membership-/Vendor-Profile und zugehörige Datensätze | Core Access und erweiterungseigene geschäftliche Identität haben getrennte Verantwortlicher. |
| Authentication-Abhängigkeiten erfassen | Identity Verantwortlicher | Password-Hash-Kontext, Social Login, SSO, MFA und externe Identity-Provider-Referenzen | Customer Identity bleibt im Umfang, auch wenn Credentials einen anderen Zugriffspfad benötigen. |
| Privacy- und Consent-Felder vorbereiten | Privacy/Marketing Verantwortliche | Consent Source, Timestamps, Preferences, Retention Rules und Marketing-System-IDs | Sensitive und Consent Data besitzen eine genehmigte Destination-, Archive-, Redaction- oder Exclusion-Entscheidung. |
Führen Sie Customers nicht allein anhand der E-Mail zusammen, wenn Household-, Shared-Company-, Marketplace-, Guest- oder historische Identitätsmuster Mehrdeutigkeit erzeugen. Bereiten Sie Duplicate Candidates und die Regel für jede Konsolidierung vor.
Orders, Refunds, Coupons, Reviews und historischen Kontext inventarisieren
Orders bewahren Transaktionshistorie über Line Items, Product-/Variation-Referenzen, ausgewählte Attribut, Quantities, Prices, Discounts, Taxes, Shipping, Fees, Payment References, Billing-/Shipping-Snapshots, Status, Notes, Refunds, Downloads und Erweiterung Metadata. Bereiten Sie Beispiele vor, die den vollständigen Order-Kontext zeigen, nicht nur Header und Totals.
Coupons sind eigenständige Promotion Datensätze mit Discount Type, Amount, Restrictions, Usage Limits, Expiry und Usage Relationships. Product Reviews können WordPress Comments plus WooCommerce Rating-/Verification-Metadaten verwenden. Refunds, Returns, Subscriptions, Bookings und Marketplace Orders können zusätzliche Erweiterung Datensätze benötigen.
| Vorbereitung | Verantwortlicher | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|---|
| Order States und Histories inventarisieren | Operations/Customer-Service Verantwortliche | Anzahlen und Stichproben für Pending, Processing, Completed, Canceled, Failed, Refunded und Custom Statuses | Jeder beizubehaltende Status hat eine verstandene historische Bedeutung und einen Verantwortlicher. |
| Komplexe Order Stichproben vorbereiten | Operations Verantwortlicher | Orders mit Variationen, Fees, Coupons, Taxes, Split/Partial Auftragsabwicklung, Notes, Refunds, Downloads und Custom Fields | Sample Set repräsentiert die tatsächlich genutzten Transaktionsbeziehungen. |
| Payment- und Auftragsabwicklung-Referenzen erfassen | Finance/Auftragsabwicklung Verantwortliche | Gateway Transaction IDs, Shipping/Tracking IDs, Warehouse/Export IDs, Marketplace Origins und External Order Keys | Historische Referenzen bleiben von aktueller Live-Konfiguration unterscheidbar. |
| Refunds und After-Sale Datensätze inventarisieren | Finance/Customer-Service Verantwortliche | Partial/Full Refunds, betroffene Lines, Amounts, Reasons, Return Datensätze und Erweiterungsverantwortlicher | Refund-/Return-Historie hat Destination- oder Archive-Entscheidung. |
| Coupons vorbereiten | Marketing Verantwortlicher | Aktive/historische Coupon Rules, Usage Limits, Restrictions, Expiry, Include/Exclude Products/Categories und Anforderungen an Usage History | Coupon-Datensätze sind Active Configuration, Historical Nachweis oder Exclusion zugeordnet. |
| Product Reviews vorbereiten | Content/Customer-Service Verantwortlicher | Rating, Author, Status, Product Relationship, Verified-Verantwortlicher-Bedeutung, Replies und Moderation Decision | Commerce Reviews sind von gewöhnlichen WordPress Comments getrennt. |
Order-Nachweise müssen den Zustand der historischen Transaktion bewahren. Aktuelle Product Prices, Customer Addresses, Shipping Methods, Tax Settings und Gateway Configuration dürfen alte Orders nicht neu interpretieren.
HPOS- und Order-Storage-Bereitschaft dokumentieren
High-Performance Order Storage verwendet dedizierte WooCommerce-Order-Tabellen statt ausschließlich WordPress Posts und Post Metadata. Bestehende Stores können HPOS, Legacy Post Storage oder einen Compatibility Mode verwenden, der beide Speicher synchronisiert. Erweiterungen und Custom Code mit direktem Order-Zugriff müssen identifiziert werden, weil sich der autoritative Speicher unterscheiden kann.
| Vorbereitung | Verantwortlicher | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|---|
| Autoritativen Order Storage erfassen | technisch Verantwortlicher | WooCommerce Order Data Storage Setting, HPOS Status, Compatibility Mode und datierter System Status | Team weiß eindeutig, ob HPOS- oder WordPress-Post-Tabellen autoritativ sind. |
| Synchronisierungsstatus erfassen | technisch Verantwortlicher | Unsynced Order Count oder gleichwertiger Statusnachweis im Compatibility Mode | Keine Unklarheit darüber, welcher Datastore den aktuellen Order Datensatz enthält. |
| HPOS-sensitive Erweiterungen inventarisieren | Erweiterungsverantwortliche | Compatibility Statements, bekannter Direct SQL/Post-Meta Access, Custom Reports, Exports und Order-Editing Code | Jede wichtige Erweiterung hat eine Kompatibilitäts- oder Restructuring-Entscheidung. |
| Custom Order Metadata mappen | Operations/Erweiterungsverantwortliche | Key Names, Purpose, Sample Values, Order/Line Verantwortlicher, Storage Location und Search/Report Use | Wichtige Felder sind unabhängig von der Speicherimplementierung identifizierbar. |
| Custom Order Tables erfassen | Datenbank-/Erweiterungsverantwortliche | Table Schema, Row Anzahlen, Parent Keys, Statuses, Dates und External Identifiers | Geschäftskritische Order Datensätze außerhalb von Core haben Destination- oder Archive-Entscheidung. |
HPOS ist nicht nur eine Versionsnotiz. Es bestimmt, wo autoritative Orders und Metadaten liegen und ob Custom Code sie interpretieren kann. Storage und Erweiterung Ownership müssen geklärt sein, bevor Order Extracts als vollständig gelten.
Checkout Fields und betriebliche Konfigurationsnachweise vorbereiten
Checkout-, Payment-, Tax-, Shipping-, Auftragsabwicklung-, E-Mail-, Account- und Notification-Einstellungen steuern künftiges Store-Verhalten. Sie sollten inventarisiert werden, weil sie Source Data und Abhängigkeiten erklären, dürfen aber nicht wie gewöhnliche migrierte Datensätze behandelt werden.
| Bereich | Vorzubereitender Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|---|
| Checkout Fields | Field Name, Type, Location, Required State, Storage Verantwortlicher, Historical Use und Erweiterung/Custom-Code Verantwortlicher | Checkout-Verantwortlicher | Historisch benötigte Felder und zukünftige Konfigurationsfelder sind getrennt. |
| Payment Methods | Gateway List, Transaction References, Token/Vault Ownership, Subscription Dependency und Historical Labels | Finanzverantwortlicher | Historische Payment Nachweis ist im Umfang, ohne wiederverwendbare Live Credentials/Tokens zu unterstellen. |
| Shipping und Auftragsabwicklung | Zones, Methods, Classes, Carrier/Warehouse Integrations, Tracking Fields, Pickup/Delivery Erweiterungen und Order References | Verantwortlicher für die Auftragsabwicklung | Configuration Dependencies und historische Shipment Data sind getrennt klassifiziert. |
| Taxes | Rates/Classes, External Tax Service, Exemptions, Historical Order Tax Values und Jurisdiction Ownership | Steuerverantwortlicher | Historische Steuerdaten bleiben von aktueller Tax Configuration getrennt. |
| Notifications und Webhooks | Email Templates, Status Triggers, Webhook Endpoints, Queue Processes und External Listeners | Operations/technisch Verantwortlicher | Automatisierte Prozesse, die Commerce Datensätze erzeugen oder aktualisieren, sind bekannt. |
| Account und Privacy Settings | Guest Checkout, Account Creation, Data Retention, Downloads und Privacy Tools | Shop-Administrator/Datenschutzverantwortlicher | Account-Verhalten und aufbewahrte Customer Data haben dokumentierte Verantwortlicher. |
Ziel der Vorbereitung ist, Source-Verhalten, daraus erzeugte Datensätze und den Verantwortlicher jeder fortbestehenden Abhängigkeit sichtbar zu machen.
Erweiterungen, Custom Code, Tables und externe Integrationen inventarisieren
WooCommerce-Stores nutzen häufig Erweiterungen für Subscriptions, Bookings, Memberships, Bundles, Composite Products, Product Customization, Deposits, Wholesale Pricing, Marketplaces, Loyalty, Points, Returns, Invoicing, Tax, Shipping und Payment. Erstellen Sie ein Erweiterung Ledger statt nur die Active-Plugin-Ansicht zu verwenden.
| Vorbereitung | Verantwortlicher | Vorzubereitender Nachweis | Freigabebedingung |
|---|---|---|---|
| Erweiterung Ledger erstellen | technisch Verantwortlicher | Name, Version, Zweck, Active State, Owned Entities, Tables/Meta, Scheduled Actions und External Services | Jede geschäftskritische Erweiterung hat einen identifizierten Verantwortlicher für Daten und Funktionslogik. |
| Custom Code identifizieren | Entwicklungsverantwortlicher | Custom Plugin, Theme Functions, Snippets, Direct SQL, REST/Webhook Handlers und veränderte WooCommerce Templates | individuelle Funktionslogik, das Datensätze erzeugt oder interpretiert, ist dokumentiert. |
| Externe Identifikatoren mappen | Integration Verantwortliche | Product-, Variation-, Customer-, Order-, Subscription-, Shipment-, Invoice- und Marketplace-Keys | Jeder beizubehaltende Key hängt an der Destination Entity, die dasselbe Geschäftsobjekt repräsentiert. |
| Generierte/temporäre Daten klassifizieren | Erweiterungsverantwortlicher | Caches, Logs, Sessions, Transient Tables, Queues, Indexes und Abandoned Datensätze | Nicht autoritative technische Daten werden bewusst ausgeschlossen. |
| Cross-Entity Dependencies erfassen | Fachliche/technische Verantwortliche | Product-Subscription-, Customer-Membership-, Order-Booking-, Vendor-Product- und ähnliche Beispiele | Related Datensätze werden nicht als getrennte Tabellen ohne Beziehungen migriert. |
Plugin-Dateien ersetzen dieses Data Ledger nicht. Eine Erweiterung kann inaktiv sein, obwohl ihre Datensätze weiter geschäftlich wichtig sind, oder aktiv sein, ohne migrationsrelevante Daten zu speichern.
WordPress-Content, Medien, URLs und Commerce Routes vorbereiten
WooCommerce ist für Site Content, Medien, Users, Menus und Routes auf WordPress angewiesen. Die WooCommerce-Checkliste sollte Commerce-bezogene Abhängigkeiten erfassen, ohne das vollständige WordPress-CMS-Inventar zu duplizieren.
| Bereich | Vorzubereitender Nachweis | Verantwortlicher | Freigabebedingung |
|---|---|---|---|
| Product- und Product-Category-URLs | Priority Routes, Slugs, Category Hierarchy, Breadcrumbs, Canonical Data und Destination Intent | SEO/Catalog Verantwortliche | Jede wichtige Commerce Route hat eine Keep-, Change-, Consolidate-, Retire- oder Redirect-Entscheidung. |
| Shop-, Cart-, Checkout-, Account- und Endpoint-Routes | Aktuelle Page Assignments, Endpoint Slugs, Language/Site Umfang und Plugin Dependencies | Store Administrator/technisch Verantwortlicher | Application Routes sind von gewöhnlichen CMS Pages getrennt. |
| Product Media und Downloads | Attachment-/File-Beziehungen, Remote Assets, Galleries, Variation Images und File Access | Catalog/Media Verantwortliche | Wichtige Commerce Files und Referenzen sind verfügbar. |
| Verbundener CMS Content | Buying Guides, Blog Posts, Landing Pages, Internal Links, Product Blocks/Shortcodes und Campaign Content | Content-Verantwortlicher | Commerce-verknüpfter Content hat bekannte WordPress Ownership und Route Dependencies. |
| SEO und Redirects | Metadata Verantwortlicher, Sitemap Source, bestehende Redirect Rules, Structured-Data Inputs und High-Value URLs | SEO-Verantwortlicher | Commerce SEO Data und Route Continuity haben eindeutige Verantwortlicher. |
| Languages oder Multisite | Store/Site/Language Ownership, Translation Relationships, Domain/Path Umfang und Shared Users | Localization/technisch Verantwortlicher | Product- und Content-Datensätze werden nicht zwischen getrennten Site-/Language-Scopes vermischt. |
Die breitere Vorbereitung von Posts, CMS Pages, Custom Post Types, Users, Builders und WordPress Plugin Applications gehört zum WordPress-CMS-Umfang. Hier werden nur WordPress-Datensätze erfasst, die WooCommerce-Commerce-Kontinuität materiell beeinflussen.
Repräsentative Migrationsstichproben auswählen
Wählen Sie Beispiele, die die realen Commerce-Beziehungen des Stores sichtbar machen. Das Sample Ledger sollte Quell-IDs, SKUs, Public URLs, Parent/Child Relationships, Erweiterungsverantwortliche, External Keys und den Auswahlgrund dokumentieren.
| Stichprobe | Vorzubereitender Nachweis | Zweck |
|---|---|---|
| Simple Product | Preis, Stock, Tax/Shipping Classes, Media, Categories und External Key | Core-Product-Baseline. |
| Variable Product | Global/Custom Attribut, Variationen, SKUs, Preise, Stock, Images, Backorders und Default Values | Parent-Variation-Struktur und verkaufbare Identität. |
| Virtual oder Downloadable Product | File, Access Limit/Expiry, Shipping State und relevante Orders | Nicht physisches Auftragsabwicklung und File Ownership. |
| erweiterungseigenes Product-Muster | Subscription, Booking, Bundle, Composite, Add-on, Wholesale, Marketplace oder ähnliche Datensätze | Erweiterung Tables und Cross-Datensatz Relationships. |
| Registered Customer und Guest Order | Addresses, Account/Guest Identity, Roles, Order Links und External IDs | Beide Customer-Identitätsmodelle. |
| Komplexe historische Order | Variation Lines, Coupon, Fee, Tax, Shipping, Payment Reference, Notes, Refund und Custom Fields | Historischer geschäftlicher Kontext. |
| HPOS-sensitive Order | Storage Status, Custom Metadata, Erweiterung Dependencies und External Reporting Use | Order-Storage- und Kompatibilitätsannahmen. |
| Commerce URL/Content Sample | Product, Category, Endpoint, Media, SEO, Redirect und verknüpfter CMS Content | WordPress-WooCommerce-Route Dependencies. |
Nehmen Sie reale Edge Cases des Stores, nicht hypothetische Komplexität. Jede Stichprobe benötigt Source Nachweis, Related Erweiterung Datensätze, Linked Files und einen benannten Reviewer.
Abschließendes WooCommerce-Bereitschaftsprüfung
Führen Sie alle Nachweise vor der Ausführung in einem Freigaberegister zusammen. Jede offene Abhängigkeit benötigt Verantwortlicher, erforderliche Entscheidung und Umfang-Auswirkung.
| Freigabebereich | Freigabebedingung |
|---|---|
| Source und Recovery | Access, System Status Report, Full Backup, Software Bestand, Snapshot Time und Restoration Verantwortlicher sind erfasst. |
| Products und Bestand | Product Types, Variationen, Attribut, Identifiers, Stock Authority, Prices, Media, Files, Categories, Tax und Shipping Classes sind dokumentiert. |
| Customers und Identity | Registered/Guest Identities, Addresses, Roles, Erweiterungsprofile, Privacy Fields und Authentication Dependencies sind klassifiziert. |
| Orders und Historie | Order States, Lines, Totals, Taxes, Coupons, Fees, Refunds, Reviews, Payment/Shipping References und External IDs besitzen Source Nachweis. |
| HPOS | Authoritative Order Storage, Synchronization State, Custom Metadata, Direct Data Access und Erweiterung Compatibility sind bekannt. |
| Operations | Checkout Fields, Payment, Shipping, Tax, Auftragsabwicklung, Notifications und Generated Datensätze haben benannte Verantwortlicher. |
| Erweiterungen und Integrationen | Geschäftskritische Erweiterungen, Custom Code, Custom Tables, externe Systeme und Cross-Datensatz Relationships sind inventarisiert. |
| WordPress-Abhängigkeiten | Commerce Routes, Media, SEO, Redirects, Connected CMS Content, Language und Site Umfang sind dokumentiert. |
| Stichproben | Sample Ledger deckt jedes wesentliche Product-, Customer-, Order-, HPOS-, Erweiterung- und Route-Muster ab. |
Der WooCommerce-Umfang ist bereit, wenn das Team jeden ausgewählten Commerce-Datensatz zu Source Storage, Business Verantwortlicher, Related Datensätze, Target beziehungsweise beibehaltenem System Verantwortlicher und Nachweisen zurückverfolgen kann.
Fazit
WooCommerce-Vorbereitung verlangt koordinierte Nachweise für Products, Variationen, Attribut, Bestand, Customers, Orders, HPOS, Coupons, Reviews, Refunds, Checkout Fields, Operations, Erweiterungen, WordPress Routes und externe Systeme. Ein Product Export oder eine Plugin-Liste allein erklärt nicht die Beziehungen, die den Store geschäftlich nutzbar machen.
Ein starkes Vorbereitungspaket legt autoritative Speicherorte fest, bewahrt wiederherstellbare Backups, identifiziert Core- und erweiterungseigene Datensätze, trennt historische Transaktionen von aktueller Konfiguration, wählt repräsentative Stichproben und löst jede wesentliche Abhängigkeit vor der Migrationsausführung.
Häufige Fragen
Was sollte für eine WooCommerce-Migration zuerst vorbereitet werden?
Definieren Sie die WooCommerce-Commerce-Grenze und erstellen Sie einen wiederherstellbaren Source Snapshot. Erfassen Sie die autoritativen Systeme für Products, Stock, Customers, Orders, Pricing, Tax, Shipping, Payment und Auftragsabwicklung, bevor detailliertes Mapping beginnt.
Warum müssen Variable Products separat vorbereitet werden?
Jede Variation kann eigene SKU, Identifikatoren, Preis, Bild, Stock, Backorder Setting, Gewicht, Abmessungen, Shipping Class, Tax Class und Download Fields besitzen. Parent-only-Nachweise können deshalb genau die Datensätze verbergen, die tatsächlich gekauft und abgewickelt werden.
Welche HPOS-Nachweise sollten gesammelt werden?
Erfassen Sie autoritativen Order Storage, Compatibility Mode, Synchronization Status, Custom Order Metadata, Direct Database Access, Custom Order Tables und Erweiterung Compatibility. So wird sichtbar, wo aktuelle Orders liegen und welche Komponenten vom Storage Model abhängen.
Sollten WooCommerce-Erweiterungen auch inventarisiert werden, wenn sie inaktiv sind?
Ja, sofern sie Datensätze erzeugt haben, die weiterhin geschäftlich oder historisch wichtig sind. Active State allein zeigt nicht, ob eine Erweiterung Products, Customer Profiles, Orders, Subscriptions, Bookings, Vendor Datensätze oder Custom Tables besitzt, die im Umfang bleiben.
Wie sollten WordPress- und WooCommerce-Vorbereitung getrennt werden?
WordPress-Vorbereitung besitzt allgemeine CMS Posts, CMS Pages, Custom Post Types, Taxonomien, Users, Builders, Media und Plugin-Application-Grenzen. WooCommerce-Vorbereitung besitzt Commerce Products, Variationen, Customers, Orders, HPOS, Coupons, Reviews und Commerce Erweiterungen; dokumentiert werden nur die WordPress-Abhängigkeiten, die diese Datensätze benötigen.
Welche Datensätze gehören in die repräsentative Migrationsstichprobe?
Wählen Sie reale Beispiele für Simple und Variable Products, nicht physische Products, erweiterungseigene Product-Muster, Registered und Guest Identities, komplexe Orders, HPOS-sensitive Metadata und Commerce Routes. Jede Stichprobe sollte Related Datensätze und Auswahlgrund enthalten.