A WooCommerce migration is easier to prepare when the team can explain both the commerce records being moved and the systems that keep them usable. A Product export can show prices and SKUs while leaving shared stock, Order storage, extension records, and recurring processes unexplained.
Treat the intended WooCommerce 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. Inventory the actual Source in its own terms, then record the intended WooCommerce representation rather than assuming that both sides use the same storage or extensions.
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.
Source scope and destination requirements
Separate selected commerce records from general CMS content, extension-owned records, and external systems. If the Source is WooCommerce, record its Store URL, WordPress installation or Multisite site, WooCommerce version, theme, extensions, custom code, and authoritative systems for Products, stock, Customers, Orders, pricing, tax, shipping, payment, and fulfillment. For another Source, collect equivalent evidence from its actual owners. Record the intended destination version and required components separately; their availability does not establish that the selected migration path transfers their records.
Source access, evidence and recovery
| Preparation action | Owner | Evidence to prepare | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| 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. | Actual Source scope and intended WooCommerce representation |
| Confirm administration and hosting access | Actual Source administrator and data/recovery owner; for a WooCommerce Source, Store administrator and hosting owner | For a WooCommerce Source: WordPress/WooCommerce administrator access, database access or export path, uploads/download files, and extension administration access. For another Source: available administration, supported export/API access, source files, and platform-managed recovery evidence. | The team can inspect and retrieve selected records; the recovery method and its limits are known, and any required rollback gap holds the affected scope. | Actual Source; WordPress/hosting requirements only for a WooCommerce Source |
| Capture the WooCommerce System Status Report | Technical owner | For a WooCommerce Source: Dated report with WooCommerce, WordPress, PHP, database, theme, template overrides, extension, and environment information. For another Source: its actual platform, app, software, and access evidence; record the intended WooCommerce environment separately. | The source software and extension context is recorded before changes begin. | WooCommerce Source report only; another Source uses its own evidence |
| Create a complete source snapshot | Actual Source recovery owner; for a WooCommerce Source, Hosting or database owner | For a WooCommerce Source: Dated database backup, wp-content files, Product downloads, media, configuration references, and restoration owner. For another Source: supported exports, accessible files, and the available recovery method and limits. |
Backup scope, date, location, restoration procedure, and retention are documented. Where the Source only permits exports or platform-managed recovery, state that limit instead of claiming a complete database restore. | Actual Source; database/wp-content backup only when available for a WooCommerce Source |
| 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. | Source and continuing Target/external systems |
Keep a protected original snapshot before cleanup, with its timestamp, software context, files, retrieval access, restoration owner, and retention period. Record later creations, updates, deletions, and structural changes in a change ledger. Approved normalized inputs should remain traceable to original IDs and values so a preparation decision can be reversed or explained.
A hosted Source may provide exports and platform-managed recovery rather than database or filesystem access. Record what can actually be recovered, preserve the original identifiers and files, and resolve that limitation before irreversible cleanup; do not label a partial export a full WordPress backup.
Prepare catalog and selling relationships
Collect the actual Source’s Product records and relationships in its native terms, then document the intended WooCommerce representation. WooCommerce-specific fields, flags and extension evidence below apply when the Source already uses them; another Source needs its corresponding native evidence and an explicit destination decision. An absent Source field is not permission to invent a value.
Product types, attributes and sellable identity
WooCommerce core supports simple, grouped, external/affiliate, and variable Product types. Virtual and Downloadable are behavior settings that can apply to a Product or variation, while extensions can add subscriptions, bookings, bundles, composite Products, memberships, deposits, Product customization extensions, wholesale rules, and marketplace ownership. Inventory the actual Product type separately from Virtual/Downloadable behavior and name the component that owns any extension-defined commercial structure.
For variable Products, capture attribute definitions, actual enabled combinations, default choices, and the parent-to-variation map. A variation can have its own SKU, identifiers, price, image, stock, backorder setting, fulfillment flags, weight, dimensions, shipping class, tax class, and download fields; some blank values use parent defaults. Record the fields and inherited values actually used by the installed version or extension. Shared parent stock and independently managed variation stock must be distinguishable in the input evidence.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Inventory Product types and behavior flags | Catalog owner | Counts and samples by simple, grouped, external/affiliate, variable, and extension-owned type, plus Virtual and Downloadable states where used | Every active type and fulfillment/file-delivery behavior 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.
Stock, pricing and fulfillment classification
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-management flags, parent stock pool, independently managed quantities, backorders, low-stock values, external warehouse IDs, snapshot time, 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. |
| 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. |
Prepare organization and discovery
Prepare the source groupings and the customer paths that use them separately. A Category, attribute vocabulary, menu entry and landing page can refer to related Products while having different owners. Keep identifiers, hierarchy and assignments with the catalog evidence, and give the intended WooCommerce navigation, archive or filter behavior a destination owner.
| Preparation area | Evidence to prepare | Owner | Ready condition |
|---|---|---|---|
| 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. |
| Navigation and public discovery | Source menus, landing destinations, filters, search inputs, and site or language assignments | Catalog, site, and SEO owners | Source classification is separated from the intended WooCommerce menus, archives, and discovery implementation. |
Prepare customer identity and access
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. |
Preserve original account and Order identifiers before resolving duplicate candidates. Email alone is insufficient when household, shared company, marketplace, guest, or historical identities create ambiguity. Record the approved consolidation rule and the identity owner. Separately confirm whether the exact Source-to-Target path supports usable password-verification continuity or requires reset, activation, or first-login handling; social login, SSO, and other identity services need their own continuation decision.
Prepare transactions and continuing obligations
Orders, refunds, coupons and reviews
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. |
Keep each historical Order as evidence of the original transaction. Current Product prices, Customer addresses, shipping methods, taxes, and gateway settings cannot substitute for Order-time values. Prepare the history snapshot alongside a separate decision for future payment, fulfillment, refund, download, and notification behavior; historical references do not authorize a live charge or action.
HPOS when the Source already uses WooCommerce
For a WooCommerce Source, record its actual storage before extracting Orders. 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 | Source / Target applicability |
|---|---|---|---|---|
| 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. | WooCommerce Source only; another Source uses its own authoritative Order model. Intended Target HPOS is recorded separately. |
| 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. | WooCommerce Source only; another Source uses its own authoritative Order model. Intended Target HPOS is recorded separately. |
| 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. | WooCommerce Source only; another Source uses its own authoritative Order model. Intended Target HPOS is recorded separately. |
| 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. | WooCommerce Source only; another Source uses its own authoritative Order model. Intended Target HPOS is recorded separately. |
| 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. | WooCommerce Source only; another Source uses its own authoritative Order model. Intended Target HPOS is recorded separately. |
Resolve authoritative Order storage before accepting an extract as complete. Compatibility synchronization copies changes from the authoritative datastore to its backup; two populated stores are not automatically two independent sets of Orders. Record synchronization status at the snapshot time and which datastore the retrieval path reads. Extensions and custom reports must have an owner for the actual storage contract, including custom metadata and tables.
For a non-WooCommerce Source, preserve the current Order model, extraction contract and related extension or external records without asking it for HPOS settings. Separately record the intended WooCommerce Order-storage and component compatibility in the destination prerequisites. Two different storage models need an explicit translation decision, not a claim that both Stores already use WordPress tables.
Prepare media, content, URLs and SEO
| Preparation area | Evidence to prepare | Owner | Ready condition |
|---|---|---|---|
| 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. |
Treat the Product CSV as one catalog artifact, accompanied by Product-type, extension, file, and relationship inventories. Record its selected fields and filters, including whether custom metadata was included. Preserve media metadata separately: the native Product CSV importer does not maintain image alt text. Neither a flat export nor native import support establishes coverage for Orders, accounts, extension tables, or the selected migration path.
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. |
Include the WordPress records that materially affect WooCommerce commerce continuity, while also accounting for related Posts, CMS Pages, custom post types, users, builders, and plugin applications when they participate in the Store experience or operational workflow.
Inventory extensions, integrations and custom data
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. |
Keep plugin files and record inventories as separate evidence. An inactive extension can retain important history; an active extension can contain temporary data that should be excluded. For required destination behavior, record the intended compatible component, record schema, account or service dependency, and owner. Where subscriptions are retained, distinguish historical subscription relationships from the gateway and schedule responsible for future billing.
Confirm target implementation prerequisites
The destination must be able to use the selected records before execution begins. The technical owner should confirm the intended WordPress/WooCommerce environment, required components, Order-storage choice, media locations, account model and continuing integration owners. These are Target prerequisites; they do not establish the Source’s software or prove that every extension record is covered by the selected path.
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. |
Preparation should identify source behavior, the records it produces, and the owner of each continuing dependency. Include a containment plan for test environments: payments, subscription jobs, notifications, webhooks, and external stock or fulfillment writes need explicit owners and intended test behavior. A historical Order or schedule should not become permission to repeat its action.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm intended Target environment and access | Target technical owner | WordPress/WooCommerce environment, administration, required components, media/files, and recovery responsibility | The selected destination and responsible access owner are explicit. |
| Confirm Target Order-storage and extension compatibility | Target technical and extension owners | Intended HPOS/Order-storage model, component compatibility, custom metadata and continuing consumers | The Target can use the agreed Order representation without treating another Source as an HPOS installation. |
| Prepare containment and continuing-operation decisions | Operations and integration owners | Payments, subscriptions, jobs, notifications, webhooks, stock and fulfillment write responsibilities | Historical/test records are separated from live actions, with a declared owner for each continuing process. |
Select representative migration 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. |
Use edge cases actually present in the Source. Each sample should include the original record and values, related extension records, linked files, the intended destination representation, accepted exclusions, and a named reviewer. A sample is ready for testing when its dependencies can be retrieved and its intended meaning can be explained, without claiming that preparation itself proves successful execution.
Final preparation readiness gate
Consolidate evidence into a readiness register before execution. Every unresolved dependency needs an owner, required decision, due date, and scope consequence. A required access, file, identity, stock, Order-storage, or extension gap must be resolved, explicitly excluded with approval, or hold the affected scope; an assigned owner alone does not make it ready.
| Readiness area | Ready condition |
|---|---|
| Source and recovery | For a WooCommerce Source: Access, System Status Report, full backup, software inventory, snapshot time, and restoration owner are recorded. For another Source: its available access, native evidence, exports/files and recovery limits are explicit. |
| 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 | For a WooCommerce Source: Authoritative Order storage, synchronization state, custom metadata, direct-data access, and extension compatibility are known. For another Source: its native Order model is recorded; intended WooCommerce Target storage and compatibility are confirmed separately. |
| 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. |
| Target prerequisites | The intended WordPress/WooCommerce environment, access, components, Order-storage choice, media, integration owners, and test/live containment decisions are confirmed. |
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.
The readiness decision also includes the intended Target environment, Order-storage choice, required components and containment owners. A complete Source export cannot resolve a missing destination prerequisite, and a configured Target cannot compensate for missing Source evidence. Hold the affected scope until both sides can support the agreed representation.
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.
Carry the completed evidence and any held scope into WooCommerce Validation Priorities so the later review tests the intended outcomes rather than assuming that preparation proves successful transfer.
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?
When the Source uses WooCommerce, 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. For another Source, capture its native Order evidence instead. Record the intended WooCommerce Target storage and component compatibility separately; a destination choice does not prove that the Source already uses HPOS.
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.
How should shared parent stock be prepared for variable Products?
Record the parent stock pool and each variation’s stock-management flag. Variations with their own stock use that quantity; others can share enabled parent stock. Preserve the original settings and snapshot time instead of adding the same inherited quantity once for every variation. Name any external inventory owner separately.
Is a Product CSV enough for the WooCommerce preparation package?
No. Record its field and filter coverage, then add evidence for accounts, Orders, extension records, files, and relationships that the catalog file does not explain. Image alt text also needs a separate destination decision because the native Product CSV importer does not maintain it. Qualify coverage against the actual migration path.
Does a cloned Store automatically provide a safe subscription test environment?
No. WooCommerce Subscriptions uses URL-based staging detection, and first activation on a test URL can still designate that site as live. Even detected staging mode can trigger scheduled renewal events and create records while payments and related emails are suppressed. Prepare an explicit billing, job, notification, and integration containment owner before testing.