Migrate
WooCommerce to Shopify Migration
Advanced Custom Fields has no runtime on Shopify, your customers are WordPress users, and the product URL base is one of four settings — so the redirect map has to be read off the live site rather than assumed.
Migrating from WooCommerce
What breaks
What does not come with you is the WordPress machinery around WooCommerce, and the biggest piece of it is Advanced Custom Fields. With over two million active installs it is how most WooCommerce stores attach structured product data — spec tables, compatibility charts, conditional layouts. None of it transfers. Shopify metafields are a different system: every value needs a definition created before it can exist, and then hand-written Liquid to render it. That is a rebuild of both the data structure and the templates that read it, not an import.
Second: functions.php and the woocommerce_* action and filter hooks. There is no equivalent. Shopify Functions are sandboxed, specific extension points — not a general-purpose hook system you can attach arbitrary code to. Every behaviour the store has bolted on with an add_filter call has to be re-solved individually as theme code, an app, or a Function, and some of them cannot be re-solved at all.
Yoast SEO usually owns two things nobody thinks about until they are gone. On a site with more than ten million installs of it, the redirect map and the schema markup are typically both Yoast’s, and both are re-created natively on the other side: redirects in Shopify’s URL redirects table, structured data in the theme.
Page builder output has nowhere to go. Elementor and Divi both store their layouts in their own format, and no builder-to-Liquid path exists. Shopify themes are JSON templates plus Liquid sections, so every page a marketer assembled by dragging blocks gets rebuilt as sections — which is usually an improvement, and is always work nobody costed.
WooCommerce customers are WordPress users. They share wp_users and wp_usermeta with your site admins, your authors, and every other plugin that writes to user meta. Shopify customers are a separate system with no CMS-user crossover at all, so the migration has to decide, per role, what happens to accounts that exist for a reason other than buying something.
And two WooCommerce product types have no Shopify equivalent whatsoever: Grouped, and External/Affiliate. Shopify has no link-out product listing, so an affiliate catalogue has to become a different kind of object — content pages, a curated collection of links, or nothing.
Data model differences
WooCommerce documents no cap on attributes or variations. The only limit in its own documentation is a user-interface note that above 30 variations the variation drop-downs become static rather than dynamic. Shopify’s ceiling is hard and low by comparison: 3 options per product, 2,048 variants. (The "100 variants" figure still circulating is stale and reads as an error to anyone checking current docs.) A WooCommerce product carrying size, colour, material and finish is four attributes against a three-option ceiling — it cannot be one Shopify product, and the fix is either demoting an attribute to a metafield, where it stops driving price and inventory, or splitting the product and stitching the pieces back together with Combined Listings.
WooCommerce product categories are a real WordPress taxonomy: arbitrary nesting, one parent per term, with tags and attributes as separate taxonomies alongside them. Shopify collections do not model that. Nested collections shipped in 2026, but they combine the contents of existing collections by rule — set-combination, not taxonomy. There is still no /collections/parent/child URL, no parent_id on a collection, and no breadcrumb inherited from a parent. A three-level WooCommerce tree flattens, and the hierarchy has to be re-expressed in navigation, filtering and internal linking rather than held in the data.
The practical consequence is that two mapping passes have to happen before a single product is imported: which attribute becomes which of the three options, and which category level survives as a collection. Both are merchandising decisions rather than technical ones, which means they land on your team, not ours.
URL structure changes
This is the part of a WooCommerce migration most often estimated wrong, and the reason is specific: it cannot be estimated from how WooCommerce normally works. WooCommerce offers four selectable product permalink bases — the default /product/{slug}, the shop base /shop/{slug}, the shop base with category /shop/{category}/{slug}, or a custom base entirely. The category base (product-category), the tag base (product-tag) and the attribute base (empty by default) are each independently configurable on top of that. And all of it sits on WordPress’s own six permalink structures.
So the redirect map is not derivable from the platform. It has to be read out of the live site’s Settings → Permalinks screen and then verified against a crawl. Teams that assume /product/name/ because that is the default, and discover afterwards that the store was running shop-base-with-category, find out from the 404 log.
On the Shopify side the target is fixed rather than chosen. /products/, /collections/, /pages/ and /blogs/ are not redirectable prefixes — only the handle after them is editable. Whatever shape your WooCommerce URLs took, every one of them lands on one of those four, which is why the mapping has to be enumerated rather than expressed as a rule.
Common apps
| App | Shopify equivalent |
|---|---|
| Advanced Custom Fields | Metafields — but a definition per field plus new Liquid to render it. A rebuild, not an import. |
| Yoast SEO | Native: the URL redirects table, plus structured data in the theme |
| Elementor / Divi | Rebuilt as Liquid sections. No builder-to-Liquid path exists. |
| WooCommerce Subscriptions (paid extension) | Shopify Subscriptions — free and first-party. One of the few places Shopify’s native answer is strictly better. |
| WooCommerce Bookings (paid extension) | No native equivalent — Shopify has no built-in appointment feature |
| WooCommerce Memberships (paid extension) | No native equivalent |
| WooCommerce Product Bundles | App required — Shopify’s own documentation states you must have a bundles app installed |
Questions
Questions we get asked
Will our Advanced Custom Fields data come across?
The values can be exported, but there is nothing on the Shopify side that renders them until it is built. Each ACF field group becomes one or more metafield definitions, and every place a template read an ACF value becomes new Liquid. Budget it as a rebuild of your product content layer rather than a data transfer, and expect the field-by-field mapping to surface fields nobody has used in three years.
Our products use four or five attributes. What actually happens to them?
Shopify allows three options per product. One or two of your attributes stop being options: either they move into metafields, where they can be displayed but cannot drive price or inventory, or the product splits into several Shopify products joined with Combined Listings — which is manual configuration, not something an importer does. Which attribute gets demoted is a merchandising decision, and it is worth making before the import rather than during it.
What happens to customer accounts?
Customer records move; the WordPress user layer underneath them does not, because Shopify has no notion of a CMS user. Accounts that exist for editorial, membership or plugin reasons rather than for buying have no destination on Shopify, and each role needs a decision.
Is there anything we will genuinely be worse off for?
Yes, and it is a short specific list rather than a vague one. You lose unlimited attributes for a three-option ceiling. You lose a general-purpose hook system for a set of narrow extension points. Bookings and Memberships are paid first-party WooCommerce extensions with no Shopify-native answer at all, so those become apps or they become gaps. And you stop owning the code. Going the other way, Subscriptions goes from a paid extension to free and first-party, and you stop running the infrastructure. It is a trade with a direction, not a straight upgrade, and if what makes your store good is the ACF and functions.php layer working exactly as it does, moving it costs more than it looks.
Why is there no timeline on this page?
Because the two things that decide it are properties of your specific install rather than of WooCommerce: how much behaviour lives in functions.php and ACF, and which of the four product permalink bases the store is on. Both are readable in an afternoon and neither is guessable from outside. We scope after reading them, and we would rather publish nothing than a number that flatters us.
Moving from WooCommerce?
We’ve mapped what breaks and what doesn’t — tell us about your store and we’ll scope the actual work.