Migrating from WooCommerce to Shopify: what actually breaks
Most migration guides focus on what goes right. Here's what actually breaks — the parts that project managers don't mention and developers discover at midnight.
WooCommerce-to-Shopify migrations are the most common migration type we run. After enough of them, the failure modes become predictable. Here's where the surprises tend to land.
The variant data problem
This is the one that causes the most trouble, and it's rarely scoped properly.
WooCommerce stores product variants as attribute combinations. Shopify uses a flat variant model with up to three options and 100 variants per product. If your WooCommerce catalogue has products with more than three variable attributes (colour, size, material, finish — four attributes) or more than 100 combinations, you have a data mapping problem before you even write a line of migration code.
The naive solution — collapse attributes, create workarounds, or use a variant metafield hack — creates downstream problems with inventory management, fulfilment, and any apps that expect the standard Shopify variant model.
The right solution requires a catalogue audit before scoping the migration. Products that exceed Shopify's variant model need a structural decision: can the catalogue be restructured? Should certain product types use a different presentation approach? This is a commercial and product question, not just a technical one.
We've seen migrations scoped without this audit, then delayed by 4-6 weeks when the variant data reality emerged mid-project.
Order history and customer accounts
WooCommerce order history migrates reasonably well. The tricky parts are:
Guest checkout orders. WooCommerce associates many orders with guest accounts (no login). Shopify can store these but they won't be accessible to customers via account login — the customer never had an account. This is usually acceptable but needs to be communicated; support teams get confused when a customer calls about an old order and the history doesn't appear in their account.
Serialised meta on orders. WooCommerce order meta is often a serialised PHP array. Extracting useful data (custom fields, fulfilment notes, subscription references) from serialised meta requires PHP unserialisation in your migration script. This is tedious but doable. The risk is custom meta fields that were added by plugins that are no longer installed — you may not know what the serialised data represents without the original plugin to decode it.
Customer passwords. These do not migrate. WooCommerce uses bcrypt hashes; Shopify doesn't accept imported password hashes. Customers have to reset their password on first login. Build a post-launch email sequence for this — it reduces support volume significantly.
Redirects: the SEO work that gets rushed
Redirect mapping is where migrations go wrong most consistently. The damage is slow and shows up 3-6 months later as organic traffic decline.
WooCommerce URL structures vary by installation age and plugin history:
/product/product-slug/(default)/shop/product-slug/(common alternative)/category-slug/product-slug/(sometimes)- Old versions without the
/product/base
Shopify's product URL structure is /products/product-handle. Category pages (collections) use /collections/collection-handle. The two structures rarely align without mapping.
A proper redirect audit maps every significant URL (every product page with any backlink equity, every category page, every blog post) to its Shopify equivalent. "Significant" means: appeared in Search Console as a click source in the last 12 months, has at least one external link, or has ranking for a keyword you care about.
The URLs that get missed are usually the edge cases: old sale pages, discontinued products that have backlinks, category pages that don't map cleanly to Shopify collections. Each unmapped URL that had equity is a small leak. Enough small leaks add up.
Plugin-to-app parity
Most WooCommerce stores run 15-40 plugins. Not all of them have a Shopify equivalent, and the ones that do don't always behave the same way.
The areas most likely to require custom development rather than a drop-in Shopify app:
B2B pricing. WooCommerce B2B plugins often support complex rule sets (customer group pricing, quantity breaks, conditional discounts by SKU). Shopify Plus B2B has improved significantly but may not replicate every rule permutation without custom work.
Complex subscriptions. Recharge handles most subscription scenarios well. Where it struggles: bundles with variable contents, "curated box" models with per-subscriber selection, subscriptions that include a mix of subscription and one-time products in a single checkout. If your WooCommerce subscription model is at all non-standard, audit Recharge's capabilities before assuming it will replicate it.
Custom checkout fields. WooCommerce allows arbitrary checkout field additions via plugins. Shopify checkout extensibility (Plus only) supports this, but the implementation is different and the field data lives in order attributes. Post-launch support workflows that read custom checkout data need to know where to look.
Product builders/configurators. If your WooCommerce site uses a configurator plugin (jewellery engraving, print customisation, kits), the Shopify equivalent will almost certainly be a custom build. Budget for it.
Post-migration reality check
Conversion rate will likely drop for the first 4-8 weeks after migration, even if everything is done correctly. Customers who have shopped with you before have muscle memory — they know where to find things on your current site. The new layout disrupts that. This is normal and temporary, but brief your team on it before launch so no one panics and decides to roll back.
Page speed should improve post-migration if the Shopify theme is built properly. A WooCommerce site with 30 plugins is typically slower than a well-built Shopify store. Monitor Core Web Vitals in the first two weeks to confirm the improvement.
Search traffic typically dips 2-4 weeks post-launch (Google re-crawling, processing redirects) then recovers. If it doesn't recover to baseline within 6-8 weeks, there's a redirect or canonical issue to investigate.
What a good migration timeline looks like
- Week 1-2: Data audit (catalogue, variants, customer data, order history, redirect mapping)
- Week 3-6: Theme build and app stack configuration in staging
- Week 7-8: Data migration to staging, testing, redirect validation
- Week 9: Staging sign-off, cutover rehearsal
- Week 10: Go-live
Anything substantially faster than this either cuts corners on the audit phase or runs the migration in parallel with the build (risky). The audit phase is where problems are cheaper to fix than after go-live.