E-Commerce

Is Your E-Commerce Data Ready for a Platform Migration?

Simon Bestbier 29 June 2026
Article

Before any data moves during a Shopify migration, there is a conversation that needs to happen, and in our experience most businesses tend to gloss over it. It is not a technical conversation. It is a business one, centred on three questions that should be asked and answered before any project work begins:

  • What data do we actually want to carry across?
  • What condition is it currently in?
  • Is moving it as it exists today genuinely going to serve us on the other side?

The businesses that run into the most trouble post-migration are usually not the ones with the most complex technical setups. They are the ones who treated data migration as a “side-quest” to get through quickly rather than a decision to make carefully, and the difference in outcome between those two approaches is significant.

The Default Assumption That Causes Most of the Problems

The default assumption in most migrations is lift-and-shift: take what exists, move it across, and pick up where you left off on the new platform. It is understandable, because the data is there, the migration needs to happen, and nobody wants to add time or cost to a project that is already consuming both. The problem is that lift-and-shift moves the mess along with everything else.

A migration is not just a moment to change platforms. It is one of the best opportunities a business will ever have to fix the data it has been living with for years.

Most businesses that have been trading online for several years have accumulated data that looked fine from the outside but is inconsistent, incomplete, or structured in ways that will create problems on a new system. Not because anyone was careless, but simply because data accumulates quietly, and the old platform was tolerant of things the new one will not be.

A migration is one of the few moments a business gets to genuinely improve its data rather than just relocate it, and most businesses miss that opportunity because they are moving too fast to stop and ask whether they should.

Not Everything Is Worth Migrating

Before any migration work begins, we ask clients to make a decision that most have never been asked to make: what data is actually worth carrying across to the new platform. The answer differs for every business, but the categories that come up most consistently are worth examining individually.

The decision of what to migrate should be made on the basis of business value and data quality, not on the assumption that everything should move simply because it exists.

Products are straightforward in principle but are often complicated by missing fields, inconsistent categorisation, or descriptions that were written for the old site’s structure rather than the new one. A migration is a natural point to address catalogue gaps that have built up over time rather than carrying an incomplete product set onto a new platform.

Customers are valuable, but only if the data is usable. Customer records with missing email addresses, duplicate entries, or usernames instead of email logins create real operational problems on a platform that uses email as the primary identifier. The question is not just whether to migrate customers, but what state those records need to be in before they move.

Orders represent the most complex call. Historical order data has genuine value: customers can see their purchase history, support teams have context, and the business retains records it may need. Migrating orders cleanly is technically demanding though, and the benefit needs to be weighed honestly against the effort. For many businesses, a clean start on order history is the right decision, particularly where the historical data is messy or the volume makes a clean migration disproportionately expensive.

Wishlists and saved items are often the last thing businesses think about and frequently the one that prompts the most debate. The question worth asking is how many wishlists have been actively interacted with recently. Where that number is low, the complexity of migrating them may not be justified by the value retained. Every migration is different and the right call depends on the business, but it should always be a deliberate decision rather than a default.

Lift, Massage, Then Shift

For the data that is worth migrating, the next question is whether it can move as it is or whether it needs work first. Rather than taking data in its current state and forcing it into the new system, the migration becomes an opportunity to restructure, clean, and improve the data before it arrives on the new platform.

What that looks like in practice depends entirely on the data. It might mean separating out product attributes that were bundled into a single description field so they can be used for filtering and search on the new site. It might mean standardising category structures across a product catalogue that has grown inconsistently over time. It might mean resolving customer records that have missing or duplicate information before they are carried across. Some of this work can be done programmatically, with rules applied systematically across large data sets to fix consistent issues. Some of it requires direct business input, because the decisions about how to restructure or categorise data are not technical ones. Both are part of the process.

The businesses that take this seriously arrive on the new platform with data that is not just present but actually fit for purpose. The ones that skip it bring their old problems with them.

The Conversation Most Partners Don’t Have

A partner who is primarily focused on delivery timelines will typically avoid this conversation because it adds time, it surfaces complexity, and it is easier to scope a project around moving data than around improving it. There is also a subtler risk: when a client pushes hard for speed, they can inadvertently put their migration team in a position where the right questions simply don’t get asked. The project moves fast, and the data problems surface later, when fixing them costs considerably more.

The conversation we have with clients before a migration starts is structured around understanding both the business and its data. What does the business need its data to do on the new platform? Which data types are genuinely valuable and which represent historical baggage? Where is the quality poor enough that migrating as-is will create more problems than starting fresh?

From that conversation, we produce a data migration strategy: an agreed position on what moves, what gets cleaned before it moves, and what gets left behind. The client approves it before any work begins, and it becomes the foundation for everything that follows. The businesses we have worked with that have gone through this process properly are the ones who go live with confidence, rather than discovering data problems in the weeks after launch when the cost of fixing them is considerably higher.

If you are planning a Shopify migration and have not yet had a structured conversation about your data, that is the right place to start. LET’S CHAT!