Case study

WordPress to Shopify: A Composite Migration Case Study

· 8 min read · By the Replatform Radar team

Illustrative, anonymized composite. Drawn from real migrations with identifying details removed and specifics generalized. The lessons are real, the names and numbers are not any one client.

Quick disclaimer before you get invested in this company: it doesn't exist. This is a composite, stitched together from the patterns we watch play out over and over on ecommerce replatforming projects (the same mistakes, the same three-week panic, different logos). The numbers are typical ranges, not one company's actual books. Nobody's quarterly report was harmed in the making of this case study.

Log into a WooCommerce store that's been humming along for a few years and count the little orange update badges stacked up in the corner of the dashboard. Plugin, theme, core, payment gateway, the security add-on you installed and forgot about. Every one of those is a Saturday afternoon nobody volunteered for, and somewhere in the building there's a person who has quietly become the WooCommerce janitor without ever applying for the job.

That's the itch behind most WordPress-to-Shopify moves: leadership is tired of babysitting a stack, and Shopify promises to take the mop away. Fair enough. But here's the part I kept watching teams get wrong, and the reason this case study exists at all. They treated the move like copying files from one folder to another, and Shopify is not a folder. It's an opinionated platform with firm rules, and the friction shows up exactly where WordPress used to let you do whatever you wanted. So let's walk through what actually broke, and what the team did to keep it from breaking.

Context

Picture a growing merchant running WordPress with WooCommerce — a content-rich site with a blog, landing pages, and a catalog of a few thousand products. The store worked, but keeping WooCommerce, its plugins, hosting, and security patched had become a part-time job nobody wanted. Leadership wanted managed commerce: a reliable checkout, less maintenance, and room to scale during peak sales. Shopify was the target.

Moving from an open, do-anything WordPress stack to Shopify’s opinionated platform trades flexibility for reliability — and the friction shows up in the places WordPress let you do whatever you wanted. The projects that struggle are the ones that treat it as a straight content copy rather than a re-platform onto a system with firm rules.

What broke

Shopify’s forced URL structure

This is the big one. Shopify mandates URL prefixes — products live under /products/, categories under /collections/, static pages under /pages/, and blog posts under /blogs/…. WordPress’s clean, custom permalinks almost never match, so every URL changes. Without a complete 301 map covering products, categories, pages, and posts, the store would have lost hard-won product rankings and paid-traffic landing pages overnight.

Catalog and customer data

Products, variants, images, and inventory had to be exported from WooCommerce and imported into Shopify via CSV and a migration app — a mapping exercise where variant structures and custom product fields rarely line up one-to-one. Customer accounts, order history, and product reviews needed their own migration paths, each with caveats (passwords never transfer; reviews depend on the app on each side).

Theme and content rebuild

WordPress themes and page-builder layouts do not run on Shopify, which uses its own Liquid templating. The storefront was rebuilt as a Shopify theme, and content pages were re-created within Shopify’s more limited page and blog model.

Plugins become apps — with monthly costs

WooCommerce plugins map to Shopify apps, but not one-to-one: some features have no equivalent, and many apps carry recurring monthly fees that change the total cost of ownership. Each critical plugin needed an app equivalent identified and priced before commitment, not after.

What worked

The migration succeeded because the team respected Shopify’s rules instead of fighting them. They exported and cleaned the WooCommerce catalog before import, so they were not migrating junk data. They built the redirect map around Shopify’s forced prefixes early and loaded it into Shopify’s URL-redirect tool at launch. They rebuilt the theme in Liquid rather than trying to reproduce the WordPress design exactly, and they selected and priced the replacement apps up front so there were no surprises in the monthly bill.

Lessons

  • Plan for total URL change. Shopify’s forced prefixes mean every product, collection, page, and post URL moves — the 301 map is the make-or-break SEO task.
  • Catalog migration is a mapping job. Export, clean, and map WooCommerce products and variants; do not assume a clean one-to-one import.
  • Migrate customers and orders deliberately. Each has its own path and caveats; passwords never transfer and reviews depend on the apps involved.
  • Rebuild the theme in Liquid. WordPress themes and builders do not port; treat the storefront as a rebuild.
  • Price the apps before you commit. Plugin-to-app is not one-to-one, and recurring app fees reshape total cost of ownership.

Before you make this move

  • Crawl the current store and build a full 301 map to Shopify’s /products/, /collections/, /pages/, and /blogs/ paths.
  • Export and clean the WooCommerce catalog, and map variants and custom fields to Shopify’s model.
  • Decide how customer accounts, orders, and reviews will migrate — and accept what cannot.
  • Identify and price the Shopify apps that replace your critical plugins.
  • Rebuild the theme in Liquid and carry SEO titles and descriptions across explicitly.

So, what do I actually think? Make the move. If patching WooCommerce has turned into a part-time job, managed commerce is worth the trade, and the merchant in this story came out the other side in one piece. But go in clear-eyed about the one thing that will decide whether you keep the traffic you already earned: Shopify's forced URL prefixes mean every product, collection, page, and post moves, and the 301 map is the make-or-break task. Everything else is a mapping exercise you can plan around. That one is a cliff.

My honest lean: build the redirect map first, before you touch a theme or price a single app, because it's the piece with no do-over. Do that, and the morning after go-live looks like a quieter dashboard instead of a fresh pile of red badges you didn't see coming. That's the whole point of leaving WordPress. Don't let a URL you forgot to redirect become the new thing nobody volunteered to fix.

Questions and discussion

Have a question about this article, or a migration you’re planning? Ask below. We read and answer every one.

Loading discussion…

Want this analysis for your exact site before you migrate?

Request a scan →