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.
WooCommerce runs inside WordPress, but commerce records need their own interpretation:
- Products and variations depend on selling relationships, not only shared WordPress storage.
- Orders need an identified authoritative datastore.
- Registered accounts, guest history and extension-owned behavior have different owners.
Inventory the actual Source in its own terms before choosing the WooCommerce representation. Do not assume matching software, storage or extensions on both sides.
Build a preparation package that connects each selected record to its storage, related records, continuing owner and readiness evidence. Include recoverable Source material, current storage settings, extension compatibility and representative samples.
Keep general WordPress CMS work under its own scope; document the dependencies commerce actually needs.
Define Source and WooCommerce Scope
Use the agreed migration scope to separate commerce, CMS content, extension records and external systems.
- WooCommerce Source: record Store URL, installation or Multisite site, versions, theme, extensions, custom code and authoritative systems.
- Other Source: collect equivalent evidence from its actual record owners and extraction path.
- WooCommerce Target: record the intended version and required components independently.
Native availability does not establish transfer coverage.
Secure Source 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 | Each selected record has a qualified core, extension, external or archive path, or an approved exclusion; required ownership gaps remain held. | 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. |
Required recovery coverage is verified, with scope, date, location, restoration owner/method and retention recorded. State export or platform-managed limits honestly; hold unresolved required recovery gaps. | 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 |
Protect the original snapshot before cleanup. Record its timestamp, software context, files, retrieval access, recovery owner and retention.
Keep later activity traceable:
- Creations, updates and deletions.
- Structural changes.
- Original IDs/values and approved normalization decisions.
The evidence should let an owner explain or reverse a preparation decision.
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 Product and Stock 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
Classify the actual Product model:
- Core types: simple, grouped, external/affiliate and variable.
- Behavior flags: Virtual and Downloadable, applied to the Product or variation where supported.
- Extension structures: subscriptions, bookings, bundles, composites, memberships, deposits, Product customization, wholesale or marketplace ownership.
Name the component governing each structure. The WooCommerce constraints help distinguish native capability from the selected data path.
For a variable Product, preserve definitions, enabled combinations, defaults and the parent-to-variation map. Record actual variation values and inherited defaults for:
- Identity and selling: SKU, other identifiers and prices.
- Presentation and stock: image, quantity, stock owner and backorders.
- Fulfillment: flags, weight, dimensions, shipping/tax classes and download fields.
Use the installed version or extension’s inheritance rules. Distinguish a shared parent stock pool from independently managed variation stock; copying one inherited quantity to every variation would overstate availability.
| 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 retained type, including required historical patterns, has qualified representation or archive handling; fulfillment/file-delivery requirements have a path or approved 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
Keep classification and relationships distinct:
- Categories, tags and global attributes.
- Shipping and tax classes.
- Cross-sells, upsells, grouped Products and related records.
Record stock at its actual authority: Product, variation, shared/mixed pools, external warehouse or extension. Pricing, media and file evidence must use the same intended sellable identity.
| 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. |
Separate Classification From Discovery
Separate catalog classification from the customer paths that use it. Categories, attribute vocabularies, menus and landing pages may refer to the same Products while retaining different owners.
Preserve identifiers, hierarchy and assignments. Use URL and redirect planning for the intended menus, archives, filters and routes; catalog grouping does not implement navigation.
| 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 Identity and Account Access
Separate identity contexts:
- Registered Customer: WordPress account, current addresses, account metadata and linked Orders.
- Guest buyer: historical transaction identity without an invented account.
- Access and entitlements: effective WordPress capabilities, download permissions and extension profiles.
Customer and Shop Manager role labels do not by themselves prove effective access. Membership, wholesale, vendor, loyalty and subscription relationships need their actual owners.
| 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 IDs before duplicate resolution. Household, company, marketplace, guest and historical records can share an email; record the approved consolidation rule and identity owner.
Prepare authentication separately:
- Qualify usable password continuity on the exact Source-to-Target path.
- Otherwise define reset, activation or first-login handling.
- Give social login, SSO and other identity services their own continuation decision.
Preserve History and Continuing Obligations
Orders, refunds, coupons and reviews
Prepare complete historical Orders, not headers and totals alone:
- Purchased configuration: lines, Product/variation references, attributes and quantities.
- Amounts: prices, discounts, taxes, shipping and fees.
- Context: payment references, address snapshots, statuses and notes.
- Related evidence: refunds, downloads and extension metadata.
Keep related commerce records distinct:
- Coupons have their own type, amount, restrictions, usage limits, expiry and usage relationships.
- Product reviews may use WordPress comments with WooCommerce rating or verification metadata.
- Refunds, returns, subscriptions, bookings and marketplace Orders may need 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. |
Preserve each Order’s transaction-time values. Current Product prices, account addresses, shipping methods, tax or gateway settings cannot replace them.
Prepare future payment, fulfillment, refund, download and notification behavior separately. A historical reference or retained schedule does not authorize a new charge or operational action.
Record Actual Source Order Storage
For a WooCommerce Source, identify the authoritative Order store before extraction: HPOS dedicated tables or legacy WordPress post storage. Compatibility mode can synchronize a secondary copy; it is not a third independent set of Orders.
Inventory extensions and custom code that read or write Orders directly. Their storage assumptions must match the authoritative model.
| 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. |
Before accepting an extract as complete, record:
- The authoritative datastore and the one the retrieval path reads.
- Synchronization status at the snapshot time.
- Extension/report consumers, custom metadata and tables.
Compatibility synchronization copies authoritative changes to the backup. Two populated stores do not prove two independent Order sets or that the chosen extract is current.
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 Files, Content and Routes
| 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 Product CSV as one catalog artifact. Record selected fields, filters and custom-metadata coverage alongside Product-type, extension, file and relationship inventories.
The core Product CSV importer cannot maintain image alt text; preserve it with a separate qualified destination decision. A different importer may have different capabilities. Neither proves coverage for Orders, accounts, extension tables or the selected migration path.
Use WordPress preparation for the broader CMS inventory. WooCommerce needs the commerce-facing content, media, user, menu and route dependencies below.
| 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.
Assign Extension and Integration Owners
Group extension evidence by business purpose:
- Catalog and pricing: bundles, composites, Product customization, deposits, wholesale and marketplaces.
- Customers and obligations: subscriptions, bookings, memberships, loyalty, points and returns.
- Operations: invoicing, tax, shipping and payment.
Use a record ledger; the active-plugin screen alone cannot establish data ownership.
| 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 critical extension has data/behavior owners, qualified handling and resolved required prerequisites or a scope hold. |
| 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 separate from record evidence:
- Inactive code can leave important history.
- Active code can generate temporary data that should be excluded.
For continuing behavior, qualify the component, schema, account/service dependency and owner. Use the integration ownership model to separate historical subscription relationships from future billing gateways and schedules.
Resolve Target Prerequisites
Before execution, qualify the destination’s ability to use the agreed representation:
- WordPress/WooCommerce environment and required components.
- Order-storage choice and extension compatibility.
- Media locations, account model and integration ownership.
Resolve required prerequisites now; prove produced outcomes after migration. Target readiness neither establishes the Source’s software nor expands transfer coverage.
Inventory future checkout, payment, tax, shipping, fulfillment, email, account and notification settings because they explain Source behavior and continuing dependencies. Their configuration is a separate responsibility from ordinary record transfer.
| 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. |
Give test containment explicit ownership for:
- Payments and subscription billing.
- Scheduled jobs and notifications.
- Webhooks, stock writes and fulfillment integrations.
A clone is not proof of isolation. WooCommerce Subscriptions can treat first activation on a test URL as live; detected staging can still run scheduled events while suppressing its automatic payments and subscription emails. Other mail or integrations need their own controls.
| 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 environment and required access are available to responsible owners; unresolved prerequisites hold the affected scope. |
| Confirm Target Order-storage and extension compatibility | Target technical and extension owners | Intended HPOS/Order-storage model, component compatibility, custom metadata and continuing consumers | Target storage and components are qualified for the agreed representation, with critical compatibility gaps resolved; another Source is not assumed to use HPOS. |
| Prepare containment and continuing-operation decisions | Operations and integration owners | Payments, subscriptions, jobs, notifications, webhooks, stock and fulfillment write responsibilities | Historical/test records and live actions are separated by defined containment, responsible owners and resolved critical test prerequisites. |
Choose Representative Commerce Samples
Choose real commerce relationships, then record:
- Source IDs, SKUs, relevant public URLs and parent/child links.
- Extension owners and external keys.
- Business reason and reviewer for each sample.
| 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. |
For each actual Source case, preserve original values, related extension records and files. Record the intended destination representation, approved exclusions and reviewer.
Define acceptance criteria before testing. A sample is ready when dependencies are retrievable and its expected meaning is clear; it is not yet proof of a successful transfer.
Complete the WooCommerce 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, software, snapshot time and verified required backup/recovery coverage are recorded with the recovery owner and limits. Another Source uses its actual native access, exports/files and recovery contract. Required gaps remain held. |
| 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, payment, shipping, tax, fulfillment, notifications and generated records have owners, defined containment and resolved required prerequisites or an affected-scope hold. |
| Extensions and integrations | Critical extensions, custom code/tables, external systems and relationships have evidence, qualified handling and resolved prerequisites, approved exclusion or a hold. |
| 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 connects actual Source evidence to a usable destination model. Record storage authority, selling relationships, account and file rights, extension consumers and the WordPress dependencies commerce needs.
Readiness requires recoverable material, qualified handling and resolved critical prerequisites. Preserve separate Source and Target evidence, historical and live responsibilities, and clear expectations for representative tests.
Carry the evidence and clearly marked held scope into WooCommerce Validation Priorities. Test only the authorized scope against its expected outcomes; preparation does not establish transfer success.
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.