Choose a Next-Cart migration approach for WooCommerce by qualifying the records and relationships the exact Source-to-Target path supports, then deciding who executes the agreed work. Product structure, Order storage and extension ownership matter more than a familiar field name or a record count.
A clear catalog and ordinary Order history may fit supported standard handling. Subscriptions, bookings, memberships, wholesale rules, custom checkout fields, plugin records, custom tables and external systems need closer classification; they do not all imply Custom Migration.
WooCommerce commerce data, WordPress content and URLs, and extension-owned behavior can have different support boundaries. Qualify each required outcome before selecting execution responsibility.
For example:
- A variation may own a SKU, price and stock; a Product Add-Ons personalization input is not automatically an inventory variation.
- HPOS uses dedicated Order tables, with possible synchronized copies elsewhere. Qualify the intended Target storage; review actual Source storage separately if the Source also uses WooCommerce.
Neither a native field nor the HPOS label establishes migration coverage or a Custom Migration requirement.
The customer supplies business meaning, retains manual access and verifies the final result even with expert execution. Use the Next-Cart migration services guide for the scope/execution distinction, or the migration service overview to navigate the available services.
What WooCommerce Approach Choice Should Decide
Make four decisions:
- Supported scope: which records and relationships the selected path covers.
- Execution: who performs the agreed Migration Actions.
- Bounded enhancement: which eligible adjustments are required.
- Separate scope: which requirements need tailored handling or target implementation.
Demo Migration supplies limited standard evidence. Enhanced or tailored output needs proof through the agreed paid scope.
| Decision layer | What it answers | WooCommerce-specific signal |
|---|---|---|
| Standard Migration | Can supported source and target data be migrated with ordinary configuration? | Required Products, Customers, Orders, Coupons, Categories, tags, CMS Pages, Blog Posts, media and URL values fit the exact selected path; no native data type is assumed supported from its name alone. |
| Managed Migration | Should an expert perform the agreed Migration Actions within supported capability? | The scope is supported, but the team wants expert execution while retaining business decisions and final verification. |
| Add-ons | Are there bounded supported requirements beyond default migration behavior? | data-type-specific record conditions, expression-based field-value changes, or compatible target destinations for supported source fields are needed. |
| Custom Migration | Does a required result exceed supported extraction, relationships or handling? | Subscriptions, bookings, memberships, wholesale rules, checkout values, external IDs or HPOS metadata need tailored handling only where extraction, relationships or logic exceed supported behavior. |
| Migration Actions | How should later migration activity be handled? | New products, customers, orders, Blog Posts, coupons, media, or plugin fields may appear after the first migration run. |
Record the chosen path, its responsible owners and the assumptions still needing evidence before Full Migration. That makes the service decision usable throughout preparation and acceptance.
When Standard Migration Fits Supported Scope
Standard Migration fits when the exact path supports the required records and relationships, and the customer can execute and validate the agreed result. Clear variation logic, readable Orders and limited extension dependencies simplify that work; common WooCommerce structures alone do not prove coverage.
| Standard Migration signal | Why it supports Standard Migration | Demo Migration proof |
|---|---|---|
| Products use supported simple, variable, grouped or external structures, with virtual/downloadable settings where applicable | The exact path supports the required structures and relationships; native capability alone is insufficient. | Inspect available supported name, SKU, price, image, stock, Category, tag and attribute fields. |
| Variable products have clean attribute logic | Parent-child product relationships are understandable. | Available standard samples preserve supported variation relationships; purchasing and choice display also need target checks. |
| Orders use standard WooCommerce fields | Historical order readability is easier to confirm. | Inspect available supported status, Customer, line items, totals, coupon lines, tax, shipping and payment labels. Confirm whether refunds and notes are supported on the exact path. |
| Customer accounts are not controlled by complex membership or wholesale rules | Customer migration can focus on identity, addresses, and order history. | Inspect supported profile, address and Order links. Authentication and extension entitlements need separate qualified proof. |
| WordPress content scope is limited and clean | CMS Pages, Blog Posts, media, and URLs can be sampled without extensive custom interpretation. | Inspect supported page, post, image and URL values; verify links, redirect operation and presentation in the prepared target. |
| Plugin impact is limited | Fewer records depend on custom fields, custom tables, or external workflows. | Check representative required plugin relationships against agreed scope; admin visibility alone does not establish completeness. |
Review two kinds of evidence:
- Standard Demo samples: supported Product relationships, historical Orders, Customer profiles, media and WordPress content.
- Prepared target behavior: purchasing, authentication, redirects and extensions.
A transferred profile or readable Order does not prove live operation.
When Managed Migration Fits the Execution Workload
Managed Migration fits supported scope when an expert should perform the agreed Migration Actions. The customer still decides Product and variation meaning, historical Order interpretation and content relationships, then verifies the result.
Assign sample planning, plugin classification, project coordination and launch work explicitly. Managed Migration does not automatically include those responsibilities.
| Managed Migration signal | Why Managed Migration helps | Typical support need |
|---|---|---|
| Store has many products, variations, categories, images, and reviews | Data may be supported, but review workload is high. | Agreed expert execution; the customer defines samples and verifies the result. |
| Orders include refunds, notes, custom checkout fields, or external references | Historical order readability needs careful interpretation. | Execute the agreed scope; business owners interpret historical Order meaning. |
| WordPress content affects commerce traffic | Product discovery depends on pages, posts, menus, SEO fields, and redirects. | Execute supported content handling; editorial and SEO owners verify continuity. |
| Plugin list is long but not every plugin requires data migration | Scope must be separated from configuration, exclusions, and custom work. | Execute the agreed supported scope after plugin requirements are classified. |
| Team needs launch support around Full Migration and later activity | New records may appear while the target store is being prepared. | Execute agreed later Migration Actions; the customer owns timing decisions and revalidation. |
Managed Migration does not turn unsupported plugin behavior into supported migration scope. Its included value is expert handling of the agreed Migration Actions within the same supported capability. Keep target implementation, wider coordination and final acceptance assigned separately.
Where Add-ons Fit WooCommerce Scope
Use Add-ons for specific, bounded supported adjustments beyond default behavior. They do not replace Custom Migration, plugin setup, development or target-store build work.
Standard Add-ons process in this order: Data Filter → Data Transformation → Advanced Data Mapping → Advanced Database Mapping.
- Filtering selects records.
- Transformation changes supported values.
- Mapping routes the source value, or an already transformed value, without changing it during mapping.
Combining supported Add-ons does not itself require Custom Migration. Tax is excluded from both mapping Add-ons.
| Add-on use case | WooCommerce example | Boundary to confirm |
|---|---|---|
| Data Filter | Apply supported Order, Customer, Product, Category, CMS Page, or Blog Post field conditions so only matching records migrate. | Filtering changes scope but does not rebuild extension workflows. |
| Data Transformation | Apply expressions to transform supported field values during migration. | Expressions are not live gateway, tax, shipping, or plugin setup. |
| Advanced Data Mapping | Remap supported standard source fields to different supported WooCommerce attribute, metadata, Customer, Order, or Product target fields while keeping the values unchanged. | Mapping requires clear source and destination meaning. |
| Advanced Database Mapping | Map a supported source database column to a compatible WooCommerce database column while keeping the value unchanged. | WooCommerce is a supported Target for Advanced Database Mapping, but the exact selected Source setup must also support it. The requested Data Type, table, field or column and semantic/Value Type compatibility must pass; Tax is excluded. Database storage does not recreate extension behavior. |
| Tailored or Custom Add-on need | A Standard Add-on function needs project-specific modification, or bespoke Add-on functionality is required. | This work is reviewed and quoted through Custom Migration rather than treated as Standard Add-on scope. |
Define potential Add-on needs before the first paid run. Demo may expose a missing standard value or unsuitable destination, but Add-ons are not available in Demo. Confirm eligibility and acceptance criteria, then test enhanced output through the agreed paid scope before broader reliance.
When Custom Migration Should Be Reviewed
Review Custom Migration when a required result exceeds the supported path and eligible Add-ons, after separating target configuration from data handling. Unsupported extraction, relationships or bespoke transformation need defined scope; store size, a custom field, an external ID or HPOS alone is not the trigger.
| Custom Migration trigger | Why it changes the approach | Review evidence |
|---|---|---|
| Subscription, booking, membership, wholesale, bundle, composite or add-on behavior needs handling beyond supported capability | Product meaning is not only name, SKU, price, stock, and image. | Product examples, extension ownership, order examples, expected target behavior. |
| Custom checkout fields need handling beyond supported configuration or mapping | Historical orders may depend on field values; live checkout may require separate setup. | Orders with populated fields, field definitions, conditional rules, reporting needs. |
| Order metadata depends on HPOS, extensions, or custom tables | Qualify actual authoritative Order storage and extension compatibility; tailored handling is needed only beyond supported extraction or mapping. | Order-storage mode, metadata examples, extension compatibility notes. |
| Customer account meaning depends on roles, memberships, external IDs, or plugin records | A compatible supported value may be mapped; memberships, role logic or unsupported relationships need separate qualification. | Customer samples, roles, membership data, external references. |
| Product pricing or availability depends on code, customer roles, external systems, or plugin rules | Check compatible mapping first. Required rule or relationship handling beyond support needs tailored review; live pricing setup remains separate. | Price examples, customer-role examples, integration references. |
| External systems own fulfillment, accounting, CRM, WMS, marketplace, or ERP references | A supported compatible identifier may fit mapping; unsupported extraction, changed relationships or live integration behavior need distinct scope. | IDs, reports, sample records, downstream system requirements. |
Custom Migration does not automatically mean the entire store build, plugin configuration, live integration setup, or custom development work is included. It means the migration requirement needs individual review because standard supported behavior is not enough.
Custom Migration can use Self-Execute or Expert Handle for its agreed Migration Actions. Prepare actual Source samples, the intended WooCommerce representation and acceptance evidence using the Custom Migration requirements guide.
Selecting CSV, XLS or XML as the Source Platform requires Custom Migration. Its included file workflow covers Products only; other Data Types need explicit agreement. A supported platform’s File Upload connection method is a different setup. A Product export alone does not establish complete WooCommerce scope.
Entity Points and WooCommerce Volume Planning
Plan Entity Points for the eligible records expected before launch, including new activity while the store remains open. Capacity is separate from plugin, subscription, custom-table and checkout complexity.
| Scope area | Entity Points consideration | Planning implication |
|---|---|---|
| Products | New Product records may consume Entity Points when migrated for the first time. | Track new products created after the first migration run. |
| Customers | New Customer records may consume Entity Points when migrated for the first time. | Review registered customers, guest-order context, and duplicate emails. |
| Orders | New Order records may consume Entity Points when migrated for the first time. | Plan around active sales before Full Migration. |
| Blog Posts | New Blog Posts may consume Entity Points when migrated for the first time. | Include commerce-supporting posts in scope review. |
| Repeated migration activity | Previously counted records should not be counted again only because another migration action occurs. | Separate records already counted within the purchased migration from newly eligible records. |
Keep three rules separate:
- A new eligible record consumes Entity Points after its first successful migration.
- A previously counted record remains counted once within the same purchased migration and fixed Source-to-Target path, including later supported runs.
- Variations, Coupons, media, plugin records, custom fields and supporting objects do not become additional counted Data Types.
Capacity does not establish support for extension or checkout behavior.
Demo Migration as the Approach Decision Point
Demo Migration tests a limited representative sample on the active supported path. Add-ons and Customization are unavailable, and Reviews and Coupons are excluded.
Use standard samples to identify gaps. Prove enhanced or tailored output through the agreed paid scope; assign storefront, extension and live-operation checks to target implementation.
| Demo Migration sample | What it should prove | Approach signal |
|---|---|---|
| Simple product | Inspect available supported basic Product fields. | Supports Standard Migration when the whole required scope is qualified and the customer can execute and verify it. |
| Variable product | Inspect supported attributes, variation SKUs, prices, images and stock relationships; verify purchasability in the prepared target. | Confirms whether product complexity remains manageable. |
| Product with extension logic | Available standard Product values may be inspected; extension-owned behavior and enhanced or tailored handling need separate agreed proof. | Classify scope first; test agreed Add-on/custom output in the paid scope and live behavior through target implementation. |
| Order with custom fields whose required handling exceeds supported mapping scope | Inspect supported historical line items, totals and labels in available standard samples; beyond-scope checkout values or metadata need agreed paid proof. | Unsupported handling needs Custom Migration review. Expert execution of supported work is a separate Managed Migration decision. |
| Customer with history | Inspect supported profile, address and Order relationships; roles, memberships and authentication have separate path and implementation boundaries. | Supports profile and relationship decisions; authentication and membership behavior require separate qualified proof. |
| Content and URL sample | Inspect supported content and URL values in the sample; confirm rendering, redirect operation and internal links in the prepared target environment. | Confirms WordPress-connected commerce continuity. |
A successful Demo supports a bounded next decision:
- Retain qualified standard scope.
- Define an eligible Add-on.
- Choose expert execution.
- Request tailored review.
- Accept an explicit exclusion.
It does not approve untested enhancements or extension behavior. Keep agreed paid proof and target implementation evidence explicit before Full Migration.
How Migration Actions Affect Approach Planning
After an earlier paid result, new Products, Customers, Orders, Blog Posts, Coupons, media or plugin values may arrive while the Target Store is reviewed. Choose the next action from the validity of the saved configuration and whether the earlier migrated result should continue.
Demo findings inform the first paid configuration; they do not create a paid continuation baseline. Confirm the supported action and record window for the selected setup before another run.
| Current action | Best-fit WooCommerce situation | Required revalidation |
|---|---|---|
| Continue the Migration with Last Saved Configuration | Reuse approved Product, Customer, Order and content handling when the saved configuration remains valid; choose the source-data window separately. | Check new variations, categories, images, Customer links, Order totals, URLs, and representative regression samples. |
| Continue the Migration with a New Configuration | Record conditions, value expressions, field destinations, field handling, or scope decisions must change after an earlier paid result. | Recheck every affected Product type, custom field, Order field, content rule, and Add-on assumption. |
| Perform a New Migration | The customer needs a distinct migrated result and the previous result should no longer be the basis of the project. | Repeat broader acceptance checks and agree how new output coexists with existing target records; protected target data is not automatically erased. |
Before another paid action:
- Reassess scope if new requirements introduce unsupported plugin tables, subscription relationships, bespoke transformation or external-system behavior.
- Check a supported new field or identifier against eligible mapping before escalating simply because it is new.
The paid baseline determines which actions are available:
- The first paid run uses Perform a New Migration.
- Continuation requires an earlier paid migration; Demo alone is insufficient.
The purchased Source-to-Target path and actual Store identities stay fixed. A different Source Platform, Target Platform, actual Source Store or actual Target Store requires a separate purchased Migration Service.
Choose the source-data window separately from the action. Confirm what the selected Source setup supports:
- Does the next activity process only newly added records, or also revisit existing records that changed?
- Does it carry applicable previous migration state, and how will later records connect to earlier data?
Do not infer those behaviors from an action name. If configuration changes, check the combined earlier and later output; a new action does not automatically erase protected target data.
WooCommerce Approach Decision Matrix
| Store condition | Best-fit approach | Why |
|---|---|---|
| Simple catalog, ordinary products, clean customers/orders, limited plugins | Standard Migration | The exact path supports the required records and relationships, and the customer can execute and verify the agreed result. |
| Supported scope but large review workload or limited internal migration experience | Managed Migration | An expert performs agreed Migration Actions; customer and implementation owners retain scope decisions and final verification. |
| Supported data type conditions, value expressions, or field-destination requirements | Data Filter, Data Transformation, Advanced Data Mapping, or eligible Advanced Database Mapping with Standard or Managed Migration | The need is bounded and can be handled through supported Add-on scope. |
| Plugin-owned data, custom checkout fields, custom tables, complex Order metadata or extension workflows exceed supported handling | Custom Migration review | Custom applies where required extraction, relationship handling or behavior exceeds supported capability; field names alone do not establish that need. |
| Active store with new products, orders, customers, and content before launch | Approach plus Migration Actions planning | Later migration activity must be scoped, counted, and revalidated correctly. |
| Theme, checkout, payment, shipping, tax, or plugin setup is unfinished | Migration approach plus target setup plan | Migration can move data, but live operation requires configuration outside record transfer. |
Conclusion
Match the approach to the actual Product and Order model:
- Standard Migration: qualified supported scope with customer-led execution.
- Managed Migration: expert execution of agreed Migration Actions within supported capability.
- Eligible Add-ons: bounded record selection, value changes or compatible destinations.
- Custom Migration: a specific unsupported extraction, relationship or handling requirement needing individual agreement.
Document the evidence still needed after the approach decision: standard Demo findings, agreed enhanced or tailored proof, capacity for new records and later paid actions. Use WooCommerce validation priorities to connect transferred data with the operating outcomes required at launch.
Common Questions
Is Standard Migration enough for WooCommerce migration?
Standard Migration may fit when the exact path supports the required Products, variations, Customers, Orders, Coupons, Categories, content and media relationships, and the customer can execute and verify the result. A native product type or familiar field is not automatic coverage. Qualify extension behavior and unsupported structures separately.
When should a WooCommerce migration use Managed Migration?
Use Managed Migration when the WooCommerce scope is supported and an expert should execute the agreed Migration Actions. It does not automatically include sample planning, project management, target setup or launch validation. The customer retains manual access, supplies business decisions and verifies the final result.
When does WooCommerce require Custom Migration review?
Request review when required subscription, booking, membership, checkout or integration meaning needs extraction, relationships or logic beyond supported behavior. A custom field, external ID or HPOS storage mode alone is insufficient: a supported compatible value may fit mapping. Target extension setup and live behavior remain separate unless expressly agreed.
Do Add-ons replace Custom Migration for WooCommerce?
No. Add-ons support bounded extended requirements such as record filtering, field-value transformation, or field remapping. Custom Migration is for requirements that need individual review because data meaning depends on extension behavior, custom logic, unsupported structures, or nonstandard workflows.
How should Migration Actions be planned for WooCommerce?
The first paid run uses Perform a New Migration. Continuation actions require an earlier paid result; choose unchanged or revised configuration separately from the source-data window. Newly added records differ from edits to existing records. Previously counted eligible records remain counted once within the same purchased migration and fixed actual Store path; new eligible records consume points after first success.
What evidence should be prepared for Custom Migration review in a WooCommerce migration?
Provide actual Source samples and the intended WooCommerce representation for the requirements under review:
- Subscriptions, bookings, memberships and wholesale rules.
- Bundles, composites, Product add-ons and custom checkout fields.
- Extension tables and required Order metadata.
If the Source also uses WooCommerce, identify its actual Order storage, including HPOS where used. Qualify the intended Target storage separately. Connect each example to its business behavior, responsible plugin or system owner, target representation and Custom Migration acceptance evidence.
Should Product Add-Ons choices become stock-bearing variations?
Decide from the selling meaning. A size or color variation may carry its own SKU, price and stock, while a personalization choice from an extension may collect input without owning inventory. Qualify the supported target representation before choosing mapping or tailored handling. Migrating a value does not install or recreate the extension’s buying logic.
Does HPOS automatically require Custom Migration?
No. HPOS identifies an Order-storage model, not a service entitlement or a custom-work category. Qualify the actual authoritative storage, selected path and required extension fields. Supported historical Orders or compatible values may fit the agreed path; unsupported extraction, relationships or bespoke interpretation need tailored review.
Can a Product CSV cover the entire WooCommerce migration?
Selecting CSV, XLS or XML as the Source Platform uses Custom Migration with a Products-only included standard workflow. Customers, Orders, Blog Posts and any other required Data Types must be agreed separately. A supported platform’s File Upload connection method is a different setup and should be judged against its own path coverage.