Online store migration: what migrates easily, and what causes problem

Online store migration rarely looks the way owners imagine it. In their heads: "we move the shop to a new platform, everything works as before." In practice: there are always gaps, some things migrate smoothly, others don’t, and some data is worth consciously leaving behind in the archive.

We work as an integrator connecting online stores with suppliers, and we’ve handled multiple migrations between ecommerce platforms. We see the whole process from the outside – from decision to go-live on the new shop. This article shows which elements migrate smoothly, where the real cost sits (usually not where you’d expect), and how to avoid paying for things you don’t actually need.

We cover each migration area separately – because the decision on what to actually move doesn’t have to be a package deal.

1:1 migration is a myth – define your scope first

The first migration conversation usually ends with: "so will everything work exactly the same?" The honest answer: no. Functionality and data structures don’t fully overlap between ecommerce platforms. WooCommerce has different product fields than Shopify, BigCommerce handles variants differently from Magento, Squarespace has its own promotion rules, Wix its own tax configuration. In every "old platform → new platform" pairing you’ll find several places where "the same thing" needs to be rebuilt differently or consciously left behind.

Rather than fighting this mid-migration, it’s worth defining the scope consciously at the start. A migration can cover three areas: customer accounts, products, orders. The decision on each is independent – sometimes you migrate everything, sometimes just the product catalogue, sometimes only the customer base, and sometimes just a set of orders. None of these areas is a prerequisite for the others.

Practical consequence: a partial migration is often enough to launch. The new shop can go live with customers and products, and historical orders can stay in the old system or be archived as a report. It works the other way too: sometimes you migrate only the product catalogue because customers and orders are expected to return to the new shop organically. We’ll come back to these decisions in the dedicated sections.

Customer accounts – usually the smoothest part

Customers are the easiest to migrate. The basic fields – name, email, billing address, shipping address, login history – look similar on most platforms. There are no structural surprises here.

What there are, though, are operational surprises that customers often don’t notice but should.

Passwords don’t migrate 1:1. For security reasons, platforms store passwords as hashes, and those hashes differ between systems. After migration, your customers will most often be asked to reset their password on first login. That’s normal and safe – but plan the communication in advance. A customer who sees "reset password" without context will assume your shop has been hacked.

Check GDPR consent and segmentation before migration. This is the moment when some shops tidy up: remove inactive accounts, verify marketing consents, refresh segments. If you’re planning that kind of spring clean, do it before the migration, not during – otherwise you’ll mix two separate operations.

What to plan: a heads-up to customers (email or a banner on the old shop) with the switchover date, password reset instructions, a link to the new address. A customer who knows what to expect doesn’t generate support tickets.

Products – easy only if your source data is clean

Products are the middle of the road. Technically they migrate well – title, description, price, stock levels, images, variants map between platforms. But the success of a product migration depends not on the target platform, but on the state of the base in the old shop.

In practice it looks like this: in the shops we migrate, product data is often outdated, inconsistent, or incomplete. Categories where some products sit "by accident". Images that weren’t uploaded or are in a format the new platform doesn’t support. Variants that haven’t been in stock for ages but no one has removed them. Descriptions copied from suppliers with errors and artefacts. Prices inconsistent with promotions. The older the shop, the more of those layers.

We assume that a few percent of items in a typical migration will require manual intervention – fixing, merging duplicates, filling in data, or a conscious "we’re not migrating this" decision. The exact figure depends on the state of the specific shop. That’s why we start every migration with a data audit – we assess the clean-up scope before we start moving anything. This means you know what you’re paying for and how long it’ll take, instead of discovering it halfway through the project.

Typical product pitfalls:

• duplicates – the same product from two sources (e.g. two suppliers) without a merge
• missing images or images in an old format the new platform doesn’t support
• product variants no longer available but still sitting in the database
• scattered categories – products in the wrong branches, or no category at all
• descriptions with hardcoded links to the old shop (URLs to products, CDN images)

Each of these is hours of manual work. Worth cleaning up before migration or consciously leaving behind – but you decide, not the system.

Orders – where 50%+ of the cost sits and the biggest traps hide

Now for the thing that surprises most shop owners: historical order migration is the most expensive part of the entire migration project. In our work, 50% or more of the total effort regularly goes on orders.

Why so much? Orders depend on consistency across all other data. An order references a customer (who must already be migrated), products (which must exist with the same identifiers), fulfilment statuses, payments, shipping, invoices. Any inconsistency in the source data surfaces right here. Orders are a "stress test" of the whole database’s quality.

The good news: a full order migration is very often not necessary. For the new shop to operate, what matters are products and customers. Historical orders can be:

• left in the old system (if access to it is still possible)
• archived as a report or export (PDF, CSV, separate database) for audit purposes
• partially migrated (e.g. only the last 12 months)

When historical orders ARE worth migrating:

• if you regularly handle returns and refunds on orders older than 6-12 months
• if you run a loyalty programme based on purchase history
• if it’s required by law or your accounting retention policy
• if you segment customers based on purchase history for marketing

When NOT worth it:

• the new shop starts fresh – history is "dead"
• orders older than X months aren’t operationally used (an export is enough)
• migration cost exceeds the business value of the archive

Ask yourself one question before making the decision: "How often in the last year have I referenced orders older than 12 months?" If the answer is "rarely" or "never" – the cost of a full order migration probably won’t pay back.

Supplier integrations – no rebuild with us (this is the real difference)

Here we reach the element that’s often decisive for dropshippers and shops with many suppliers. A platform change without a supplier-integration plan is a guaranteed bottleneck.

The problem in a typical migration: integrations with each supplier (API, XML feed, CSV, vendor panel) are usually wired directly into the old platform. When you switch to a new shop, they need to be rebuilt from scratch. That means: reconfigured authentication, field mapping, price and stock sync configuration, testing, fixes. For each supplier separately. For a shop working with several or a dozen suppliers, that’s weeks of extra work – often hidden in the migration quote as "supplier integration".

How it looks on our side. Our integrator is platform-agnostic – it sits as a layer between the shop and suppliers. The supplier doesn’t know and doesn’t need to know which platform your shop is running on. It’s us translating data from the suppliers we’re integrated with into a format that WooCommerce, Shopify, PrestaShop, BigCommerce, Magento, Squarespace, Wix, or any other platform we support can understand.

Practical consequence: migrating your shop from one platform to another doesn’t require a supplier integration rebuild. Reconnecting suppliers to the new platform is a standard procedure for us – not a from-scratch project. Stock and price sync keeps running, orders reach suppliers as before, only the shop on the other side is new.

If you work with multiple suppliers and are considering a migration – this is usually the biggest saving you can unlock by choosing a universal integrator over bespoke per-platform deployments.

SEO after migration – ranking dips are normal, but manageable

Concern about Google rankings is one of the two most common reasons shops delay a migration (the other being cost). The truth is that ranking fluctuations after a migration are a normal phenomenon. Google needs time to reindex the new structure, check the 301 redirects, verify that content quality hasn’t changed. No migration has zero SEO impact.

What matters isn’t fighting this fact, but preparing the SEO migration plan before you start moving content.

What the SEO migration plan should cover:

• 301 mapping from old URLs to new ones (especially for the top-ranking pages)
• retaining URL structure where possible (if the old shop used /product/product-name/, the new one should too – don’t change without reason)
• meta data audit (title, description) – what’s lost in the transfer
• retention of category content and informational page text (terms, privacy policy, About us)
• a Google Search Console monitoring plan for post-launch

One important practical recommendation: coordinate the SEO plan with the shop’s SEO lead or agency. They know the optimisation history, current rankings, strategic phrases. Technically, any team can do a migration – but the judgement of "what’s worth keeping from an SEO perspective at all costs" needs context that sits with the person responsible for visibility.

After migration: ranking and index error monitoring in GSC, quick reaction to reported issues (404s, duplicates, missing metadata), patience. The time needed to recover visibility depends on many factors – the domain, competition, quality of the migration itself, the redirect structure. There’s no sensible universal answer to how long that’ll be. Every shop behaves differently.

What we don’t promise: "you’ll recover rankings in 6 weeks" or "you won’t lose more than 10% visibility". Honestly, these figures can’t be predicted without data on the specific shop.

Before you start – a checklist from an integrator

Collected into one list – the steps that separate a successful migration from a chaotic one.

• [ ] Source data quality audit. Products, customers, orders – what’s consistent, what needs cleaning. Without an audit, you’re going in blind and every issue becomes a surprise. We start every migration with this step.
• [ ] Defined migration scope. Write down what you’re moving (customers, products, orders, information pages, media) and what you’re not. A decision like "we’re not migrating orders older than 24 months" taken at the start saves weeks of arguments.
• [ ] SEO plan prepared with your SEO lead or agency. 301s, URL mapping, key pages to preserve. Don’t leave this for launch day.
• [ ] Customer communication. Password reset, potential downtime, address changes. Better to warn than to explain.
• [ ] Supplier integration mapping. If you work with suppliers – how will they operate after migration. With us: typically no rebuild, but worth confirming as part of the project.
• [ ] Realistic timeline. A typical migration takes 1-2 weeks, but it depends on scope and the tempo at which you or your team provide decisions, access, and feedback. If the client responds once a week, the migration takes a month – and that’s not the contractor’s fault.
• [ ] A migration partner. Someone with experience in your specific platform pair (Shopify → WooCommerce is different from PrestaShop → BigCommerce) and with the integrations you have in place.

Summary: migrate consciously, not 1:1

The main takeaway from this article: online store migration isn’t cloning. It’s an opportunity to tidy up data, cut unnecessary baggage, and arrive on a new platform with a cleaner, more consistent base than you had before.

Shortest summary in three points:

• Define the scope consciously. A migration is three independent areas: customer accounts, products, orders. Each is a separate decision – sometimes you migrate everything, sometimes just one area. Consider whether historical order migration is even needed – in many cases, it isn’t.
• Supplier integrations don’t have to be rebuilt. If you work with a universal integrator like us – reconnecting suppliers to a new platform is a standard procedure, not a weeks-long project.
• SEO plan and customer communication. Plan them before the start, not during. The costliest migration mistakes are the ones you could have foreseen.

Thinking about migrating your shop? See our online store migration service – we start with a source data audit so you know what to expect and can budget realistically. No surprises mid-project.

Working with multiple suppliers? See how our supplier integrations stay with you after platform migration – no rebuild required.