Full database access makes the export easy. The work is in the plugins holding product logic, the attribute structures, and a WordPress URL map that has to survive the move.
WooCommerce gives up its data readily. What it does not give up is its plugins.
A WooCommerce store usually comes with full database access, a working REST API and a functioning CSV export. Compared with most source platforms that is a good position, and it is why the difficulty sits somewhere else.
WooCommerce stores products as WordPress posts with the commercially interesting parts held in post metadata. Anything a plugin added lives in that metadata too, or in its own tables, and it does not come out of a product export. Custom fields, product add-ons, bundles, role-based pricing, booking logic and delivery-date rules all behave like part of the product until you try to move them.
Variable products are the second theme. WooCommerce lets attributes and variations grow without limit, so ranges routinely arrive with more option dimensions than Shopify’s product structure holds. Resolving that is a business decision about how the range should be shopped, not a mapping exercise, and it is made before the import rather than during it.
The third is that the site is a WordPress site as well as a shop. Pages, posts, categories, tags, author archives and uploaded media all carry links and search visibility, and a plan that only accounts for the products will lose the rest.
Confirmed against your export, not assumed from this table.
| Entity | Normally transfers | Where a decision is needed |
|---|---|---|
| Simple products | Yes, including images, descriptions, SKUs and prices | Which meta fields become Shopify metafields rather than being dropped |
| Variable products | Usually, where the attribute set fits Shopify’s option structure | Ranges with more option dimensions than Shopify holds: split, combine or model as metafields |
| Categories and tags | Yes, as collections | Nested category trees flatten, so hierarchy has to be rebuilt in navigation and linking |
| Customers | Yes, without passwords, which cannot move from any platform | How and when customers are told they need to reactivate an account |
| Orders | Usually, as historical records | How far back to import, and whether refunds and partial fulfilments need to be represented |
| Pages and posts | Yes, though formatting from page builders often needs rework | Which content is worth keeping, and what was only ever there for search |
| Coupons | Rules that map to Shopify discounts | Conditions with no equivalent, which need a different mechanism or a decision to drop |
| Reviews | Through a review application’s import, not through the platform | Which review app, and whether historical ratings must be preserved |
Yoast or Rank Math titles and descriptions can usually be carried across into Shopify’s SEO fields, which is worth doing while the mapping is already open.
Identified in discovery and priced as build work, not as data.
These are the WooCommerce features that behave like data and are actually functionality. Each one is a build decision.
Product add-ons, configurators, custom fields and bundle rules are held by the plugin that created them. On Shopify they become metafields, metaobjects, a comparable application or bespoke storefront work, and the choice affects both the build cost and the ongoing licence cost.
WooCommerce stores often run trade pricing through a plugin that reads a WordPress user role. Shopify handles that through a different mechanism entirely, and the right one depends on whether the business is on Shopify Plus and how the trade accounts actually work.
Subscription plans can be recreated, but stored payment methods cannot be transferred between platforms and payment providers. Existing subscribers have to re-authorise, so the communication plan matters more than the data mapping.
Content assembled in Elementor, Divi or a similar builder exports as markup that means nothing outside its plugin. Those pages are rebuilt as Shopify templates and sections, which is usually a chance to reduce their number.
Nothing on this list is a surprise if it is found in week one.
The most valuable thing in the migration is often the link profile.
WooCommerce sites carry a wider variety of routes than most source platforms, and each family needs a deliberate rule rather than a best guess.
The map is built from a crawl of the live site and, where available, an export of the landing pages that actually receive search traffic. Routes with no traffic and no links are retired deliberately rather than forgotten.
A migration is a trading change. Four parts of it are not about data at all.
Swipe the parts
Design
A migration is a reasonable moment to change the storefront, and a bad moment to change everything at once. Most WooCommerce moves suit a restrained theme implementation, with the design budget spent on the templates that sell.
Systems
The plugins that talk to accounting, despatch, stock and email are part of the migration scope. So is anything holding data the shop reads but does not own.
Proof
A sample migration first, checked field by field on a representative set including the awkward products. Then a full run reconciled against source counts.
Switch
A delta run for everything that changed during the build, a planned switch at a quiet trading hour, and the old site kept available and reachable until the new one is proven.
None of it is the product count on its own.
A WooCommerce migration is priced from what the source contains, not from what the platform is called.
The estimator uses platform, data volume, design requirement and special requirements to return a band. A fixed price follows source access, a sample export and a look at the integrations.
Published starting figures in GBP and USD, excluding VAT.
From-price or scoped after source review
Data only
From £1,000From $1,300
Products, customers, orders and content mapped into a Shopify store that already exists or is priced separately. Fixed once source access and a sample migration are reviewed.
Starting price · scoped after discovery
Migration and build
From £5,000From $6,500
Moving to Shopify and building the store in one project, so the data and the storefront land together rather than in two disconnected pieces of work.
Starting price
Plus, B2B, multi-market
From £8,000From $10,500
Shopify Plus, B2B, multi-market, multi-language, custom integrations or headless work. These configurations are sized after discovery, not instant-priced.
Starting price · scoped after discovery
Third-party platform, application and migration-tool fees are separate unless listed. Estimator output is indicative and non-contractual.
Usually, but not always as a single product. Where a range has more option dimensions than Shopify’s product structure holds, it is split, combined or modelled with metafields, and that decision is made with you before the import because it changes how the range is shopped.
Yes, with the caveat that content built in a page builder exports as markup that only means something inside that plugin. Those pages are rebuilt as Shopify templates, which is usually an opportunity to reduce how many of them there are.
It does not move. Shopify handles trade pricing through different mechanisms, and which one fits depends on your plan and on how the accounts actually work. It is scoped as build work rather than treated as data.
Yes. Password hashes cannot be transferred between platforms, on any migration. Accounts move with their addresses and order history, and customers reactivate on first use. The message that goes out is planned before cutover.
The active plugins tell us more about the real scope of a migration than the product count does.
