WooCommerce preparation must treat the Store as a commerce application inside WordPress. Products and variations share WordPress infrastructure with content, but their business meaning comes from WooCommerce and its extensions. Orders can use High-Performance Order Storage or legacy WordPress post storage. Customers can be registered WordPress users or guest transaction identities. Subscriptions, bookings, bundles, memberships, wholesale pricing, custom checkout fields, and marketplace records may live in extension-specific structures.
The preparation package should explain where each commerce record lives, which Product or transaction relationships it depends on, and which system owns continuing behavior. It should include recoverable backups, current storage settings, extension compatibility evidence, representative records, and a final ready condition for every material commerce area. WordPress CMS content remains connected but is not duplicated inside the WooCommerce scope.
Establish the WooCommerce Boundary, Access, and Source Snapshot
Begin by separating WooCommerce core records from WordPress CMS records, extension-owned commerce records, and external systems. Confirm the source Store URL, WordPress installation or Multisite site, active WooCommerce version, active theme, enabled extensions, custom code, and current authoritative systems for Products, stock, Customers, Orders, pricing, tax, shipping, payment, and fulfillment.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Define the WooCommerce commerce boundary | Store owner and technical lead | Entity list covering Products, variations, Customers, Orders, coupons, reviews, refunds, downloads, extensions, and external systems | Every commerce record has a core, extension, external, archive, or exclusion owner. |
| Confirm administration and hosting access | Store administrator and hosting owner | WordPress/WooCommerce administrator access, database access or export path, uploads/download files, and extension administration access | The team can inspect selected records and recover the source if needed. |
| Capture the WooCommerce System Status Report | Technical owner | Dated report with WooCommerce, WordPress, PHP, database, theme, template overrides, extension, and environment information | The source software and extension context is recorded before changes begin. |
| Create a complete source snapshot | Hosting or database owner | Dated database backup, wp-contentfiles, Product downloads, media, configuration references, and restoration owner |
Backup scope, date, location, restoration procedure, and retention are documented. |
| Record authoritative external systems | Integration owners | ERP, PIM, WMS, CRM, tax, payment, shipping, fulfillment, marketplace, and accounting identifier map | Continuing systems of record and the keys they use are explicit. |
If the source Store continues changing, record a snapshot timestamp and the types of records that may be created or modified afterward. This change ledger preserves the source boundary and identifies records that may need a refreshed source snapshot.
Inventory Product Types, Attributes, Variations, and Sellable Identity
WooCommerce core supports simple, grouped, external/affiliate, variable, virtual, and downloadable Product behavior, while extensions can add subscriptions, bookings, bundles, composite Products, memberships, deposits, Product customization extensions, wholesale rules, and marketplace ownership. Inventory each Product type in actual use and name the component that owns it.
Variable Products require particular care. Global or Product-specific attributes can define variations, and each variation can carry its own SKU, identifiers, enabled state, regular or sale price, cost, downloadable/virtual state, weight, dimensions, shipping class, tax class, image, stock, backorder rule, and low-stock threshold.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Inventory Product types | Catalog owner | Counts and samples by simple, grouped, external, variable, virtual, downloadable, and extension-owned type | Every active type has a target representation or intentional exclusion. |
| Map Product and variation identity | Catalog and integration owners | Parent Product IDs, variation IDs, SKUs, GTIN/UPC/EAN/ISBN where used, external keys, and duplicate-identifier report | Every sellable item can be distinguished and reconciled across connected systems. |
| Document attributes and variation generation | Catalog owner | Global attributes, custom attributes, term values, default attributes, variation combinations, and “Any attribute” patterns | Attribute vocabularies and real sellable combinations are known before mapping. |
| Capture variation-level commercial data | Catalog and inventory owners | Representative variation price, sale price, image, stock, backorder, weight, dimensions, tax, shipping class, and download fields | Commercial values are assigned to the parent or variation level intentionally. |
| Record advanced Product ownership | Extension owner | Extension name/version, Product subtype, custom tables/meta, related Products, and operational behavior | Subscription, booking, bundle, composite, add-on, wholesale, or marketplace data has a defined owner. |
Use representative Product families rather than only aggregate exports. Include a simple Product, a variable Product with several attributes, a virtual or downloadable Product where applicable, and each material extension-defined Product pattern.
Prepare Inventory, Pricing, Taxonomy, Media, and Product Files
Product readiness also depends on classification, stock authority, pricing context, media, and files. Categories, tags, global attributes, shipping classes, tax classes, cross-sells, upsells, grouped Products, and related records should remain distinct. Inventory may be maintained at Product level, variation level, a mixture of both, or by an external warehouse or extension.
| Preparation area | Evidence to prepare | Owner | Ready condition |
|---|---|---|---|
| Inventory authority | Product/variation stock settings, backorders, low-stock values, external warehouse IDs, and synchronization owner | Inventory owner | Each sellable item has one declared authoritative stock path. |
| Prices and promotions | Base/sale prices, schedules, quantity or group pricing, extension owner, and currency context | Commercial owner | Prices are classified as core Product/variation values, extension rules, or external-system values. |
| Categories and Product attributes | Hierarchy, term slugs, Product assignments, attribute use for variations or filtering, and obsolete terms | Catalog owner | Taxonomies remain connected to the intended Products without merging unrelated vocabularies. |
| Product media | Featured image, galleries, variation images, alt text, attachment IDs, remote assets, and missing-file report | Catalog and media owners | Priority Product and variation media are accessible with known parent relationships. |
| Downloadable files | File URLs/paths, access rules, limits, expiry, source availability, and Product/variation links | Digital Product owner | Each retained download has an accessible file and a defined Product or variation owner. |
| Shipping and tax classification | Shipping classes, tax classes, virtual status, dimensions, weight, and special extension rules | Operations owner | Classification evidence is complete without treating current configuration as historical Order data. |
The Product CSV exporter can be useful preparation evidence, but it should be accompanied by Product-type, extension, file, and relationship inventories. A flat CSV cannot fully represent every extension-owned Product structure or external-system dependency.
Prepare Customers, Accounts, Addresses, and Commerce Roles
WooCommerce Customers can be registered WordPress users or guest buyers recorded on Orders. Registered Customers can have billing and shipping addresses, account metadata, Order history, downloadable permissions, and extension relationships. WordPress roles such as Customer or Shop Manager define access, while membership, wholesale, vendor, loyalty, or subscription extensions can add separate profiles and rules.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Separate registered Customers and guest buyers | Customer-service owner | Counts, samples, email/phone quality, account IDs, and Order relationships | Guest Orders are preserved without inventing accounts, and registered Customers remain linkable. |
| Prepare Customer addresses | Customer-service owner | Billing/shipping fields, multiple-address extensions, country/state formats, and representative Customers | Current account addresses are distinguished from historical Order snapshots. |
| Inventory commerce roles and profiles | Store administrator and extension owners | WordPress roles, custom capabilities, wholesale/membership/vendor profiles, and related records | Core access and extension-owned commercial identity have separate owners. |
| Record authentication dependencies | Identity owner | Password-hash context, social login, SSO, MFA, and external identity-provider references | Customer identity remains in scope even when credentials require a different access path. |
| Prepare privacy and consent fields | Privacy and marketing owners | Consent source, timestamps, preferences, retention rules, and marketing-system IDs | Sensitive and consent data has an approved destination, archive, redaction, or exclusion decision. |
Do not merge Customers solely by email when household, shared company, marketplace, guest, or historical identity patterns create ambiguity. Prepare duplicate-candidate evidence and the rule that will govern any consolidation.
Inventory Orders, Refunds, Coupons, Reviews, and Historical Context
Orders preserve transaction history through line items, Product or variation references, selected attributes, quantities, prices, discounts, taxes, shipping, fees, payment references, billing and shipping snapshots, statuses, notes, refunds, downloads, and extension metadata. Prepare samples that show the full Order context, not only Order headers and totals.
Coupons are separate promotional records with discount type, amount, restrictions, usage limits, expiry, and usage relationships. Product reviews may use WordPress comments plus WooCommerce rating or verification metadata. Refunds, returns, subscriptions, bookings, and marketplace Orders may depend on additional extension records.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Inventory Order states and histories | Operations and customer-service owners | Counts and samples for pending, processing, completed, canceled, failed, refunded, and custom statuses | Every retained status has an understood historical meaning and owner. |
| Prepare complex Order samples | Operations owner | Orders with variations, fees, coupons, taxes, split/partial fulfillment, notes, refunds, downloads, and custom fields | The sample set represents the transaction relationships actually used by the Store. |
| Record payment and fulfillment references | Finance and fulfillment owners | Gateway transaction IDs, shipping/tracking IDs, warehouse/export IDs, marketplace origins, and external Order keys | Historical references remain distinguishable from current live configuration. |
| Inventory refunds and after-sale records | Finance and customer-service owners | Partial/full refunds, affected lines, amounts, reasons, return records, and extension owner | Refund and return history has a defined destination or archive. |
| Prepare coupons | Marketing owner | Active/historical coupon rules, usage limits, restrictions, expiry, included/excluded Products/Categories, and usage history requirements | Coupon records are classified as active configuration, historical evidence, or exclusion. |
| Prepare Product reviews | Content/customer-service owner | Rating, author, status, Product relationship, verified-owner meaning, replies, and moderation decision | Commerce reviews are separated from ordinary WordPress comments. |
Order evidence should preserve the state of the historical transaction. Current Product prices, Customer addresses, shipping methods, tax settings, and gateway configuration should not be used to recreate or reinterpret old Orders.
Record HPOS and Order-Storage Readiness
High-Performance Order Storage uses dedicated WooCommerce Order tables rather than relying only on WordPress posts and post metadata. Existing Stores can use HPOS, legacy WordPress post storage, or compatibility mode that synchronizes both stores. Extensions and custom code that read or write Order data directly must be identified because the authoritative storage can differ.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Record the authoritative Order storage | Technical owner | WooCommerce Order data storage setting, HPOS status, compatibility-mode state, and dated System Status evidence | The team knows whether HPOS or WordPress post tables are authoritative. |
| Record synchronization state | Technical owner | Unsynced Order count or equivalent status evidence when compatibility mode is used | No ambiguity remains about which datastore contains the current Order record. |
| Inventory HPOS-sensitive extensions | Extension owners | Compatibility declarations, known direct SQL/post-meta access, custom reports, exports, and Order-editing code | Every important extension has a compatibility or restructuring decision. |
| Map custom Order metadata | Operations and extension owners | Key names, purpose, sample values, Order/line owner, storage location, and search/report use | Important fields can be identified independently of the source storage implementation. |
| Capture custom Order tables | Database and extension owners | Table schema, row counts, parent keys, statuses, dates, and external identifiers | Business-critical Order records outside WooCommerce core have a destination or archive decision. |
HPOS is not merely a version note. It affects where authoritative Orders and metadata reside and whether custom code can interpret them. Preparation should resolve storage and extension ownership before Order extracts are treated as complete.
Prepare Checkout Fields and Operational Configuration Evidence
Checkout, payment, tax, shipping, fulfillment, email, account, and notification settings control future Store behavior. They should be inventoried because they explain source data and dependencies, but live configuration should not be treated as ordinary migrated records.
| Preparation area | Evidence to prepare | Owner | Ready condition |
|---|---|---|---|
| Checkout fields | Field name, type, location, required state, storage owner, historical use, and extension/custom-code owner | Checkout owner | Required historical fields and future configuration fields are separated. |
| Payment methods | Gateway list, transaction references, token/vault ownership, subscription dependency, and historical labels | Finance owner | Historical payment evidence is in scope without assuming reusable live credentials or tokens. |
| Shipping and fulfillment | Zones, methods, classes, carrier/warehouse integrations, tracking fields, pickup/delivery extensions, and Order references | Fulfillment owner | Configuration dependencies and historical shipment data are separately classified. |
| Taxes | Rates/classes, external tax service, exemptions, historical Order tax values, and jurisdiction ownership | Tax owner | Historical tax evidence remains distinct from current tax configuration. |
| Notifications and webhooks | Email templates, status triggers, webhook endpoints, queue processes, and external listeners | Operations/technical owner | Automated processes that create or update commerce records are known. |
| Account and privacy settings | Guest checkout, account creation, data retention, downloads, and privacy tools | Store administrator and privacy owner | Account behavior and retained Customer data have documented owners. |
The preparation goal is to identify source behavior, the records it produces, and the owner of each continuing dependency.
Inventory Extensions, Custom Code, Tables, and External Integrations
WooCommerce Stores often depend on extensions for subscriptions, bookings, memberships, bundles, composite Products, Product customization extensions, deposits, wholesale pricing, marketplaces, loyalty, points, returns, invoicing, tax, shipping, and payment. Build an extension ledger rather than relying on the active-plugin screen alone.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Build an extension ledger | Technical owner | Name, version, purpose, active state, owned entities, tables/meta, scheduled actions, and external services | Every business-critical extension has an identified data and behavior owner. |
| Identify custom code | Development owner | Custom plugin, theme functions, snippets, direct SQL, REST/webhook handlers, and altered WooCommerce templates | Custom behavior that creates or interprets records is documented. |
| Map external identifiers | Integration owners | Product, variation, Customer, Order, subscription, shipment, invoice, and marketplace keys | Each retained key is attached to the destination entity representing the same business object. |
| Classify generated or temporary data | Extension owner | Caches, logs, sessions, transient tables, queues, indexes, and abandoned records | Non-authoritative technical data is excluded deliberately. |
| Record cross-entity dependencies | Business and technical owners | Product–subscription, Customer–membership, Order–booking, vendor–Product, and similar relationship examples | Related records will not be migrated as disconnected tables. |
Plugin files are not substitutes for the data ledger. An extension can be inactive while its records remain operationally important, or active while storing no data that belongs in migration scope.
Prepare WordPress Content, Media, URLs, and Commerce Routes
WooCommerce depends on WordPress for site content, media, users, menus, and routes. The WooCommerce checklist should capture commerce-facing dependencies without duplicating the full WordPress CMS inventory.
| Preparation area | Evidence to prepare | Owner | Ready condition |
|---|---|---|---|
| Product and Product Category URLs | Priority routes, slugs, Category hierarchy, breadcrumbs, canonical data, and destination intent | SEO and catalog owners | Every priority commerce route has a keep, change, consolidate, retire, or redirect decision. |
| Shop, cart, checkout, account, and endpoint routes | Current Page assignments, endpoint slugs, language/site scope, and plugin dependencies | Store administrator and technical owner | Application routes are distinguished from ordinary CMS Pages. |
| Product media and downloads | Attachment/file relationships, remote assets, galleries, variation images, and file access | Catalog/media owners | Priority commerce files and references are available. |
| Connected CMS content | Buying guides, Blog Posts, landing Pages, internal links, Product blocks/shortcodes, and campaign content | Content owner | Commerce-linked content has known WordPress ownership and route dependencies. |
| SEO and redirects | Metadata owner, sitemap source, existing redirect rules, structured-data inputs, and high-value URLs | SEO owner | Commerce SEO data and route continuity have explicit owners. |
| Languages or Multisite | Store/site/language ownership, translation relationships, domain/path scope, and shared users | Localization/technical owner | Product and content records will not be merged across distinct site or language scopes. |
The broader preparation of Posts, CMS Pages, custom post types, users, builders, and WordPress plugin applications belongs to the WordPress CMS scope. This section captures only the WordPress records that materially affect WooCommerce commerce continuity.
Select Representative Migration Test Samples
Select samples that expose the Store’s real commerce relationships. The sample ledger should record source IDs, SKUs, public URLs, parent/child relationships, extension owners, external keys, and the reason each sample was chosen.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Simple Product | Price, stock, tax/shipping classes, media, Categories, and external key | Establishes the core Product baseline. |
| Variable Product | Global/custom attributes, variations, SKUs, prices, stock, images, backorders, and default values | Represents parent–variation structure and sellable identity. |
| Virtual or downloadable Product | File, access limit/expiry, shipping state, and relevant Orders | Represents non-physical fulfillment and file ownership. |
| Extension-owned Product pattern | Subscription, booking, bundle, composite, add-on, wholesale, marketplace, or similar records | Exposes extension tables and cross-record relationships. |
| Registered Customer and guest Order | Addresses, account/guest identity, roles, Order links, and external IDs | Represents both Customer identity models. |
| Complex historical Order | Variation lines, coupon, fee, tax, shipping, payment reference, notes, refund, and custom fields | Represents historical commercial context. |
| HPOS-sensitive Order | Storage status, custom metadata, extension dependencies, and external reporting use | Exposes Order-storage and compatibility assumptions. |
| Commerce URL/content sample | Product, Category, endpoint, media, SEO, redirect, and linked CMS content | Represents WordPress–WooCommerce route dependencies. |
The sample set should include edge cases actually used by the Store, not hypothetical complexity. Each selected sample should have source evidence, related extension records, linked files, and a named reviewer.
Complete the Final WooCommerce Readiness Gate
Consolidate the evidence into a readiness register before execution. Any unresolved dependency must have an owner, a required decision, and a scope consequence.
| Readiness area | Ready condition |
|---|---|
| Source and recovery | Access, System Status Report, full backup, software inventory, snapshot time, and restoration owner are recorded. |
| Products and inventory | Product types, variations, attributes, identifiers, stock authority, prices, media, files, Categories, tax, and shipping classes are documented. |
| Customers and identity | Registered/guest identities, addresses, roles, extension profiles, privacy fields, and authentication dependencies are classified. |
| Orders and history | Order states, lines, totals, taxes, coupons, fees, refunds, reviews, payment/shipping references, and external IDs have source evidence. |
| HPOS | Authoritative Order storage, synchronization state, custom metadata, direct-data access, and extension compatibility are known. |
| Operations | Checkout fields, payment, shipping, tax, fulfillment, notifications, and generated records have named owners. |
| Extensions and integrations | Business-critical extensions, custom code, custom tables, external systems, and cross-record relationships are inventoried. |
| WordPress dependencies | Commerce routes, media, SEO, redirects, connected CMS content, language, and site scope are documented. |
| Samples | The sample ledger covers every material Product, Customer, Order, HPOS, extension, and route pattern. |
The WooCommerce scope is ready when the team can trace each selected commerce record to its source storage, business owner, related records, target or retained system owner, and supporting evidence.
Conclusion
WooCommerce preparation requires coordinated evidence across Products, variations, attributes, inventory, Customers, Orders, HPOS, coupons, reviews, refunds, checkout fields, operations, extensions, WordPress routes, and external systems. A Product export or plugin list alone cannot explain the relationships that make the Store commercially usable.
A strong preparation package establishes authoritative storage, preserves recoverable backups, identifies core and extension-owned records, separates historical transactions from current configuration, selects representative samples, and resolves each material dependency before migration execution begins.
Common Questions
What should be prepared first for a WooCommerce migration?
Define the WooCommerce commerce boundary and capture a recoverable source snapshot. Record the authoritative systems for Products, stock, Customers, Orders, pricing, tax, shipping, payment, and fulfillment before detailed mapping begins.
Why do variable Products require separate preparation?
Each variation can own its SKU, identifiers, price, image, stock, backorder setting, weight, dimensions, shipping class, tax class, and download fields. Parent-only evidence can therefore hide the records that are actually purchased and fulfilled.
What HPOS evidence should be collected?
Record the authoritative Order storage, compatibility-mode state, synchronization status, custom Order metadata, direct database access, custom Order tables, and extension compatibility. This shows where current Orders live and which components depend on the storage model.
Should WooCommerce extensions be inventoried even when they are inactive?
Yes, when they created records that remain commercially or historically important. Active state alone does not prove whether an extension owns Products, Customer profiles, Orders, subscriptions, bookings, vendor records, or custom tables that remain in scope.
How should WordPress and WooCommerce preparation be divided?
WordPress preparation owns general CMS Posts, CMS Pages, custom post types, taxonomies, users, builders, media, and plugin application boundaries. WooCommerce preparation owns commerce Products, variations, Customers, Orders, HPOS, coupons, reviews, and commerce extensions, while documenting only the WordPress dependencies needed by those records.
Which records should be selected for representative migration test?
Select real examples that represent simple and variable Products, non-physical Products, extension-owned Product patterns, registered and guest identities, complex Orders, HPOS-sensitive metadata, and commerce routes. Each sample should include its related records and reason for selection.