What Breaks First When You Switch Ecommerce Platforms
Most platform migrations don't fail because the products didn't make it across. The products are usually there. The customers are there. The new Shopify store looks right, checkout works, and everyone involved has spent the last few weeks staring at it closely enough to know every section by heart.
Then someone clicks an old Google result and lands on a 404. Or Meta starts reporting fewer purchases than Shopify. Or a customer emails to ask why the shipping rule they've used for the last three years suddenly doesn't apply.
This is the part of an ecommerce platform migration that gets underestimated. The things most likely to break aren't usually the things sitting visibly on the page. They're the rules, connections and history underneath it — the things the old store had quietly been carrying for years. And by the time you notice they're missing, the new store is already live.
The first thing to disappear is usually something you didn't realise had value: the old URL
Say you've been selling the same product for four years. On your old site, it lived at yourstore.com/shop/product-name. On Shopify, it now lives at yourstore.com/products/product-name. To a customer looking at those two URLs, the difference barely matters. To Google, they're two separate pages.
The old URL may have spent years accumulating rankings, backlinks and search history. It may appear in old blog articles, Pinterest pins, emails, affiliate content, social posts and customer bookmarks. If you launch the new store without telling search engines where that page has moved, all of those old paths can suddenly lead nowhere.
And products aren't the only problem. Collection and category pages can change. Blog URLs can change. Pages that don't seem particularly important internally may actually be bringing in organic traffic every month. Campaign landing pages may still have valuable links pointing to them long after the campaign itself ended.
This is why redirect planning shouldn't happen the afternoon before launch. Before anything moves, you need an inventory of the URLs on the current store and a decision about what happens to the important ones on the new store. Where there is an equivalent page, the old URL should generally be redirected to it. If a product has disappeared entirely, don't automatically send everyone to the homepage; point them towards the closest useful alternative.
And test those redirects after launch. A redirect sitting in a spreadsheet isn't a redirect until you've confirmed that it actually works.
A tracking problem can look exactly like a sales problem
This is one of the nastier migration problems because the store itself can look completely fine. Orders are coming through, checkout works and customers aren't reporting anything unusual. Then somebody opens Meta Ads Manager and purchases have dropped. Google Analytics doesn't agree with Shopify. Klaviyo isn't recording the same events it did before. Suddenly everyone is trying to work out what happened to the performance.
Sometimes, nothing happened during the performance. The measurement broke.
A mature ecommerce store is rarely just a website. It has an entire stack sitting around it: Google Analytics, Google Ads, Meta, Klaviyo, review platforms, subscription tools, affiliate software, customer service systems, product feeds, pixels, scripts and apps. Changing platforms changes the environment all of those systems are connected to, and "the app is installed" is not the same thing as "the data is correct."
You need to know whether the events your marketing relies on are still firing, whether purchases are being attributed properly, whether product feeds are updating and whether your email platform is receiving the behaviours it needs to trigger automations. An abandoned cart flow doesn't announce that it has stopped receiving the right event. It just quietly stops sending to some of the people it should have reached. A post-purchase flow can still be sitting there marked live while the information feeding it has changed underneath.
This is why it's worth documenting your measurement setup before the migration. Know what Shopify, Meta, Google, Klaviyo and the rest of your stack currently receive so you have something to compare against afterwards. Without that baseline, it becomes surprisingly difficult to answer a very basic question after launch: did performance actually change, or are we measuring it differently?
Once the new store is ready, don't just open each integration and check that it says "connected." Run through the journey. Visit a product, add it to cart, start checkout, complete an order, sign up to email and trigger the relevant automations. Then check whether the information actually arrived where it was supposed to.
The hardest things to migrate are usually the rules nobody wrote down
Over time, ecommerce stores accumulate exceptions. Free shipping kicks in at a certain amount, except for oversized products. One product can't ship internationally. Wholesale customers receive different pricing. A particular discount only applies to certain collections. A bundle has its own inventory logic. VIP customers have a particular tag. Someone on the team manually fixes something every Friday because an integration has never quite handled it properly.
Individually, none of these sounds like a major piece of ecommerce infrastructure. Collectively, they're how the business actually works.
The problem is that they're often not documented anywhere. They live inside app settings, custom code, plugins, shipping configurations, someone's memory or a process the team has repeated for so long that nobody thinks to mention it. Then the migration brief says, "Move us from WooCommerce to Shopify," and the obvious parts get rebuilt: products, collections, navigation, customer accounts, checkout and design. Nobody mentions the weird shipping exception because everyone assumed it was just how shipping worked — until it doesn't.
This is why one of the most useful things you can do before a migration is stop thinking about pages and start thinking about behaviour. Don't only ask what the website contains. Ask what the website does.
What happens when a first-time customer places an order? What changes for an existing customer? What happens when someone buys three products together, uses a discount, orders internationally or purchases an item with unusual fulfilment requirements? What gets sent to the warehouse after checkout? What happens when something goes out of stock? What happens after the purchase?
The unusual answers are the important ones. That's usually where the hidden migration requirements are.
Your customer data can migrate perfectly and still become less useful
Moving customer records sounds reassuringly concrete. You had 40,000 customers before the migration and you have 40,000 afterwards, so the migration worked. Except the number of records isn't the only thing that matters. What information was attached to those customers?
Tags, marketing consent, order history, addresses, customer groups, loyalty information, subscription status and custom fields can all determine what you're able to do with a customer after the migration. The same applies to products. A product title and SKU making it across doesn't necessarily mean all of the information your other systems depend on came with it. Metafields, variants, images, inventory locations, tags and category structures can affect merchandising, filtering, feeds, automations and reporting.
So don't validate a migration by comparing record counts alone. Take samples. Choose customers with different histories and statuses and inspect what actually came across. Choose straightforward products and complicated ones. Check products with multiple variants, unusual shipping requirements, bundles or custom fields. The exceptions will tell you more about the quality of the migration than the easiest records in the database.
The checkout working doesn't mean the migration is finished
Launch day creates a very convincing false finish line. The domain points to the new store, someone places a test order, the order appears in Shopify and everyone exhales. But that only proves one path worked.
A real store has dozens of paths. Mobile and desktop. New and returning customers. Guest checkout. Different payment methods. Discounts and gift cards. Domestic and international shipping. Products that are in stock, low in stock or unavailable. And then there is everything that happens after checkout: the confirmation email, fulfilment, inventory, analytics, post-purchase flows and whatever internal system the order needs to reach next.
The most useful migration testing isn't someone clicking around the homepage looking for broken buttons. It's deliberately recreating the ways real customers use the store, including the awkward ones.
Don't rebuild every workaround just because it already exists
There is another side to this. A migration shouldn't become an archaeological project where every strange decision made over the last six years gets lovingly recreated in Shopify.
If the old platform required three plugins to accomplish something Shopify now handles natively, don't automatically rebuild the three-plugin solution. If the navigation has become bloated because new categories were added every year without old ones being removed, don't preserve it simply because that's how the current site works. If your team has a manual process caused entirely by a limitation of the old platform, ask whether that process still needs to exist.
The goal isn't to produce a pixel-for-pixel, rule-for-rule replica of the old store on a different platform. The goal is to understand what exists well enough to make an intentional decision about what stays, what changes and what disappears.
There's a big difference between simplifying something deliberately and losing it accidentally.
Before you migrate, make these three maps
You don't need a 70-page migration document before anyone can touch the new store. But there are three things worth mapping properly.
Your URL map should show the important pages that exist today, where they'll live on the new store and which URLs need redirects. Pay particular attention to pages receiving organic traffic, revenue or backlinks rather than assuming every page has equal value.
Your integration and data map should show every system connected to the store and, more importantly, what information moves between them. Don't just write "Klaviyo." Write down what Klaviyo needs from the store — customer profiles, product activity, checkout behaviour, orders and whatever else your flows and segmentation rely on.
Your customer journey and business rules map should follow what happens from discovery through checkout and post-purchase, including the exceptions: shipping rules, discounts, bundles, subscriptions, customer groups, automations, fulfilment requirements and manual processes.
Those three maps make the invisible parts of your current ecommerce setup visible before anyone starts pulling them apart.
The migration isn't the risky part. Assuming you know what's being migrated is.
Moving to Shopify can solve a lot of problems for a business that's outgrown Wix, WooCommerce or a legacy ecommerce setup. But the value of a migration isn't that your products now live on a newer platform. It's that the business comes out the other side with a cleaner, more reliable ecommerce system than the one it started with.
That requires knowing what the current store is actually doing before you replace it.
Because the expensive migration problems are rarely dramatic technical failures. They're the Google traffic that slowly disappears because old URLs weren't mapped. The campaigns that suddenly look worse because purchase tracking changed. The automation that stopped triggering. The shipping rule nobody remembered existed. The customer data that technically migrated, minus the information that made it useful.
None of those will necessarily stop you from launching. That's exactly why they're so easy to miss.
If you're planning a move to Shopify and want someone to look at the whole ecommerce setup — not just rebuild the pages — that's something we can help with.
