A WooCommerce to Shopify migration moves the easy things reliably. Products, customers, orders and images all have equivalents on both sides and the tooling handles them. What breaks is everything built on top of those — and it breaks quietly, because the export succeeds and the problem only appears when someone tries to use the store.
This is the list, in roughly the order it causes trouble.
Product types with no equivalent
WooCommerce has product types that Shopify simply does not model. Grouped products, external or affiliate products, and the more elaborate variable products with dependencies between attributes.
The elaborate variable products are the common one. If your options interact — this finish only in these sizes, that material only for those models — Woo will let you express it and Shopify's variant model will not, at least not without an app or a rebuild of how the product is structured. This is the single most likely thing to turn a two-week migration into a two-month one, and it is knowable on day one by looking at your three most complicated products.
Shopify also caps how many options a product may have. Most catalogues never approach it. Configurable products routinely do, and it is better to discover that during planning than during import.
Coupon logic
WooCommerce coupons are rule engines, and stores accumulate rules over years. Spend thresholds that exclude sale items, per-user limits, category restrictions, stacking behaviour, free shipping conditions.
Shopify's native discounts cover the common cases well and do not cover all of that. Some rules become apps, some become a simpler policy, and some quietly do not come across at all — which is how a store ends up honouring a discount it did not intend to.
Export your active coupons before the project starts and go through them one at a time. It is a dull hour that prevents an expensive month.
Custom fields and everything reading them
WordPress stores arbitrary metadata against products, and any store of a certain age has years of it: specification tables, delivery estimates, supplier codes, compatibility data, fields a plugin added and nobody documented.
Shopify has metafields, so the data can move. What does not move is anything that reads it. Every template, shortcode and plugin displaying those fields has to be rebuilt on the Shopify side, and this work is invisible in a migration quote unless someone has looked at your templates.
The test is to open your most detailed product page and list everything on it that is not the title, description, price or image. All of it is custom-field work.
Page-builder content
If your content pages were built with a page builder, the content is stored as the builder's own markup rather than as portable content. Exporting gives you a wall of shortcodes or nested markup that means nothing outside the builder.
In practice those pages are rebuilt rather than migrated. That is fine and it is often an improvement — but it is a line in the budget, and the number of pages is usually larger than anyone remembers. Count them early.
Subscriptions, and anything with a payment token
This is the hardest one and it deserves its own consideration before the project is agreed.
Active subscriptions cannot simply be moved. The stored payment authorisations belong to the old gateway and the old platform, and they cannot be handed over. The realistic options are running both systems until the old subscriptions age out, or asking customers to re-subscribe — which will lose some of them, and the honest planning assumption is that it will lose more than you hope.
If subscriptions are a meaningful part of your revenue, the migration decision should be made with that number in front of you, not as an afterthought.
The SEO plugin data, which is the one people forget
Years of hand-written titles and meta descriptions live in your SEO plugin's tables, not in the product data. Nobody thinks about it, the export does not include it, and a store arrives on Shopify with auto-generated titles replacing copy that had been tuned for years.
It is extractable and it is worth extracting. This is also where your redirect history lives if you have been managing redirects there, and that history is part of the map described in the order of operations for the move itself.
When you should not move
If your catalogue depends on product structures Shopify does not model, moving means changing your merchandising to suit the platform. Sometimes that is a good outcome. Sometimes it is the tail wagging the dog, and the honest answer is to stay and fix the hosting and maintenance instead.
If the shop hangs off a content operation that works, moving the shop can mean splitting the site in two or rebuilding the content as well — a much larger project than the one being quoted.
And if the current store is simply neglected rather than structurally wrong, a migration will feel like a fix because everything is new, while the underlying problem was that nobody was maintaining it. That problem travels. We build on both platforms and say this often enough that it is worth writing down: a well-maintained WordPress store beats a badly-run Shopify one, and the reverse is equally true.
