Figuring out how to migrate is easy. There are tutorials, official docs, and step-by-step videos for moving products, customers, and orders from one platform to another. What almost nobody answers is the question that comes before that, and it's the one we hear most when someone writes to us: whether you should migrate at all.
Nobody switches platforms because they read a comparison chart. You migrate when the patches pile up. A feature someone had to solve with custom code. A plugin nobody updates anymore. A mobile version that got worse on its own, without anyone touching it. Each fix, on its own, seems reasonable. That's exactly why it's so hard to know when it's time to decide.
These are the five signs that mark the point where the platform stopped being a bargain.
The typical case we see is subscriptions. The platform doesn't handle them natively with the local payment gateway, so someone ends up building a custom solution to make it work. And that makes the product much harder to maintain, update, or edit down the road. It works, sure. But recurring revenue ends up depending on something nobody else on the team understands, that has no official support, and that can break with an update nobody controls.
The diagnostic question is direct: if the person who built that integration left tomorrow, how long would it take the business to notice something stopped charging?
Having hundreds of plugins to choose from is an advantage, but only as long as those plugins keep existing, stay updated, and don't clash with each other. WordPress's own numbers give a sense of the real risk: Patchstack reported 7,966 new security flaws in 2024, 34% more than the year before, and 96% of them were in plugins, not in WordPress's core software. A third of those flaws had no fix available when they were made public, and 1,614 plugins and themes were pulled from the official WordPress store over unresolved issues, without stores that already had them installed getting any warning.
The risk doesn't show up on install day. It shows up two years later, when the plugin running your loyalty program no longer has a maintainer.
When every plugin brings its own visual style and its own code, the mobile version is where it all piles up. Misaligned icons, buttons that get cut off, load times that keep stretching. Nobody redesigned anything to break it: it broke slowly, piece by piece, without anyone noticing. If fixing mobile means touching five different plugins nobody on the team wrote, the problem stopped being about design a while ago.
Uploading a product is easy. But creating a temporary bundle with its own price, launching a category promotion, or changing the structure of a page: if any of those tasks needs an email to a developer, the platform's real cost is higher than what shows up on the invoice. Whether your team can make those changes on its own, without depending on anyone else, matters just as much as the price of hosting when you're choosing where to run your store.
You have to add it all up properly. Annual plugin licenses, hosting, certificates, maintenance hours, development hours for every feature the platform doesn't come with, and everything you didn't get to sell because something was too hard to build. When that total gets close to what a platform like Shopify would cost, plus the cost of migrating spread over two years, the conversation changes.
It's worth saying just as clearly: staying can also be the right decision. WooCommerce is still a solid choice when your catalog works in a very particular way that a platform like Shopify can't replicate well, when your content (blog, articles, guides) matters as much as your product catalog, or when you already have a technical team that keeps all of it running smoothly. We said as much when we compared Webflow and WordPress for businesses: the right platform depends on what your team needs to do with the site, not on which one is trendy. Migrating because it's trendy costs just as much as staying out of pure habit.
A migration is decided by looking closely at your business, not by watching a demo of the new platform.
The goal of a migration isn't to have a new platform. It's to stop paying the tax of keeping features running that the business already considers basic.
At Contra, we've handled Shopify migrations like Beckett Simonon's, a footwear brand that needed a more flexible e-commerce platform for its brand story. If you're weighing this move, let's talk.
It depends on where the business's complexity actually lives. Shopify handles standard store operations better: hosting, security, updates, and payments come built in. WooCommerce handles cases better where the catalog or content has its own logic and there's a technical team to support it. The useful question isn't which one is better in the abstract, it's which of the two costs the business would rather take on.
More than the “free” license makes it look. The real total includes hosting with enough capacity, annual licenses for the plugins that run key features, certificates, maintenance hours, and development hours for everything the platform doesn't come with. That total is the number to compare against a platform like Shopify.
You lose them when the migration doesn't include a one-to-one redirect map for the URLs generating traffic today. With that map done well, you should expect a temporary dip of a few weeks while Google re-reads the new pages, and then recovery. Without it, the drop can be permanent.
Subscriber data, yes. How their cards are stored depends on the payment gateway, and often can't be transferred from one provider to another. This is the piece most worth resolving before committing to a launch date, since it can mean asking every subscriber to re-enter their payment method.
For a catalog of a few hundred products without complicated business rules, the usual range is four to eight weeks, including design, data migration, redirects, and testing. Custom integrations and active subscriptions are what stretch that timeline the most.
Almost always, yes, because the bulk of the cost is in moving the data and rebuilding the templates, and splitting the two projects means paying for that work twice. That's usually how we frame it when someone brings us this question: the exception is when the current site works fine and the urgency is purely technical.
