The Integration Decision That Determines Which Shopify Migrations Survive Launch

Most Shopify migrations that break on an integration were signed off as fully tested the week before launch. That is not a coincidence, and it is not a testing failure. It is a sign the test checked whether the systems could connect, not whether the migration would survive a live store environment.

Testing was never the problem

On most Shopify migrations, integration testing confirms that a connection can be made. An order placed in Shopify appears in the accounting system. A stock update flows through to the warehouse. Everyone watches it happen, everyone is satisfied, and the project moves on.

What that kind of testing does not confirm is what happens outside the happy path. For example:

None of these are unusual scenarios. They are what most live stores experience within their first week of trading. We see the same pattern on most Shopify migrations that run into integration trouble after launch: the scenarios that get skipped are rarely the ones anyone thought to test, because the test was built to prove a connection works, not to define what should happen when it doesn’t.

An integration that has only been tested against easy scenarios will always look finished.

Live traffic asks the hard questions automatically, on a schedule nobody controls, and usually within the first few weeks of trading on the new platform.

The store is only one piece of what’s actually migrating

Most Shopify migration scopes are built around the parts everyone can see: the storefront, the theme, the checkout flow. That is understandable, because it is also the part that gets demonstrated and signed off. But the store does not operate on its own. It sits inside a wider operation that includes an accounting or ERP system, a warehouse or stock management platform, a shipping and fulfilment provider, a customer support tool, and a marketing or loyalty stack.

Most of those connections were built for the old platform, often by someone no longer involved in the business, using assumptions that made sense for a different data model. Migrating the store does not migrate those relationships with it. It forces most of them to be re-decided, not simply reconnected. A shipping integration that worked because the old platform sent weights in a particular format does not automatically work because the new platform can technically call the same API. This is where we spend a disproportionate share of early discovery time on most Shopify migrations we run, and it is rarely where clients expect that time to go. A migration that treats integrations as a lift-and-connect exercise has usually been scoped wrong from day one, regardless of how well the storefront turns out.

A connection can be functional and still fail

Two systems can both be “integrated” and still disagree about which one is telling the truth. Stock levels are the clearest example, and one of the most common: if the warehouse system and Shopify both claim to know how many units are on hand, something has to decide which one is right when they don’t match, and what the customer-facing number should show while that gets resolved.

The same question applies when an API call fails. Some integrations retry automatically and alert someone if the retry also fails. Others fail silently, and the missing record only surfaces when a customer asks where their order is. The difference between those two outcomes usually has little to do with the platform itself. It comes down to a decision, made or not made, about what should happen when things don’t go to plan.

Someone has to own the decision before the build starts

For every integration in the ecosystem, somebody needs to decide, in advance, what the correct behaviour is when systems disagree, when a call fails, or when data arrives in a format nobody anticipated. That decision belongs to the business, not the platform vendor and not the development team alone, because it is a call about which system is the source of truth and what the customer should experience while a problem is being resolved. It is also one of the most underrated decisions in a Shopify migration, precisely because it rarely looks urgent until the moment it is.

The best time to decide what happens when a sync fails is before it has ever failed, not after it has cost you a customer.

Leaving that decision until user acceptance testing, or worse, until after go-live, is a common and entirely avoidable source of cost on a migration. It is also one of the easiest to prevent. Integration mapping belongs alongside discovery, not as a task squeezed into the build once development is already under way.

The cost of finding out live

None of this shows up as a dramatic failure. It shows up as a support team fielding calls about orders that technically exist but haven’t synced, a warehouse team picking against stock numbers that were already wrong an hour ago, a finance team reconciling by hand because nobody decided what should happen when an order got refunded twice in the same session. It is the quiet, unglamorous cost we are often asked to help clients untangle in the weeks after a Shopify launch that otherwise went well. None of it is a platform problem. It is a decision that got deferred until the worst possible moment to make it.

The platform can be exactly right for the business, and the migration can still fail to survive its first weeks of live trading, because the parts of the project that determine whether it holds together in production were not given the same attention as the parts everyone could see on a staging site. That is the gap we spend a significant amount of time closing on a Shopify migration, and it is the reason integration mapping gets equal billing with the build itself in how we scope this work.

If you are heading into a Shopify migration and haven’t yet worked through what should happen when your integrations fail, not just when they work, that is where the conversation needs to start. LET’S CHAT!