What Is Shopify Migration? An Operator's Definition

Shopify migration is the process of moving a store’s commerce data — products, customer records, order history, content and URL structure — onto Shopify. It covers two distinct situations that get talked about with the same word: moving onto Shopify for the first time from another platform, and moving between two Shopify stores. Both are the same underlying problem: sorting every piece of data the old store holds into one of three categories — what transfers cleanly, what transfers in a reduced form, and what has to be rebuilt from nothing — before a single record moves.

That sorting step is the part the dictionary definition skips, and it’s the part that decides whether a migration is a quiet weekend or a six-week fire drill.

What is a Shopify migration, in operator terms rather than vendor terms?

A Shopify migration is a data-transfer project with a hard deadline (the old store’s contract or hosting expires) and an audience that notices every gap (customers who expect their order history, their saved payment method, their loyalty balance to still be there). Most vendor descriptions of migration stop at “we move your products and customers” — which is true, and also the least useful part of the definition, because products and customers are the records that move cleanest in almost every migration. The harder question, and the one an operator actually needs answered, is what happens to everything that isn’t a product or a customer record: subscriptions, custom pricing tiers, gift card balances, review history, checkout logic, and every URL a customer or Google has bookmarked.

Framed that way, a migration has three moving parts, not one:

1. Products, customers, and a defined slice of orders — the data that Shopify’s import tools and most third-party migration apps are built to move, with genuinely high fidelity.
2. Content, redirects, and metadata — technically transferable, but only if someone builds the mapping; nothing does this automatically.
3. Custom logic, passwords, and platform-specific integrations — the category that does not transfer under any circumstances, and has to be either rebuilt on Shopify or formally written off.

A migration plan that only accounts for category one is not a migration plan — it’s a product import.

What moves, what degrades, and what doesn’t move at all

Products

Product titles, descriptions, images, variants, SKUs and inventory counts move with the highest fidelity of any data type, whether the source is another platform or another Shopify store. The friction shows up in variant structure — a source platform’s option/variant model rarely maps one-to-one onto Shopify’s, and a catalogue with deeply nested options (size, colour, material, and a fourth custom option) often needs a manual remapping pass rather than a straight import.

Customers

Customer name, email, shipping and billing addresses, and order association move cleanly. Two things routinely don’t: marketing consent state, which has to be re-verified against the destination platform’s own consent record rather than assumed to carry over, and loyalty or store-credit balances, which live in whatever app held them on the old platform and need an explicit export-import path through that app, not through Shopify’s core customer import.

Orders

Order history is the category with the most judgement calls. Shopify’s order object doesn’t map one-to-one onto every source platform’s order model, particularly for split shipments, partial refunds, and subscription-linked orders. The common pattern is importing a defined recent window — a business decision, not a technical ceiling — as live Shopify orders that customer service and reporting can query, and keeping the full history as a static export for tax records and dispute resolution. A store deciding “we import the last two years and archive the rest” has made a real decision; a store that never asks the question ends up with whatever the migration app defaulted to, which is not the same thing.

Content

Pages, blog posts and their associated images generally move, but formatting rarely survives untouched — rich-text and shortcode-based content from other platforms typically needs a manual pass in Shopify’s editor. Blog post URLs and slugs are worth locking down explicitly, because Shopify’s blog URL structure differs from most competitors’ and a silent rename here is one of the more common redirect gaps.

URLs and SEO

URLs are technically “content” but deserve their own line because they’re the highest-stakes item on this list and the one most often deprioritised. Shopify’s URL patterns for products, collections and blog posts rarely match the old platform’s, which means every URL that Google has indexed and every URL a customer might have bookmarked needs a corresponding redirect. A migration with a complete redirect map holds its search visibility through the transition. A migration without one returns 404s to both visitors and search crawlers — and a 404 doesn’t just lose that one visit, it tells Google the page is gone, which is a slower, quieter version of losing the ranking outright.

Passwords

Passwords do not move, full stop, regardless of source or destination platform. They’re stored as one-way hashes tied to the originating platform’s specific hashing algorithm, and there is no reversible path from a hash to a value Shopify could re-encrypt in its own format. Every migrated customer resets their password on first post-migration login. This isn’t a defect in any migration tool — it’s a structural property of how passwords are stored everywhere — and the operator’s job is to plan the reset-prompt communication rather than to look for a tool that avoids it.

Custom logic

Checkout customisation, private apps, custom Liquid, and platform-specific integrations are the category most migration estimates undercount, because none of it shows up in a product or order count. A store with a custom wholesale pricing rule, a subscription-pause flow built as a private app, or a checkout-page script that hides a shipping method under a condition has functionality that lives entirely in code — and code isn’t “migrated,” it’s rebuilt, on Shopify’s own extensibility model (Shopify Functions, checkout extensibility, or a Shopify-native app that does the equivalent job). Sizing a migration by SKU count alone, without auditing custom logic, is the single most common reason a “two-week migration” becomes a six-week one.

What changes for the operator once migration is treated as an ops problem, not a data copy

Once the three-category sort is done, a Shopify migration stops looking like a single event and starts looking like a project with dependencies — which is exactly the frame that gets it staffed and scheduled correctly. The category-one data (products, most customer fields) can run through an automated or semi-automated tool with light supervision. The category-two data (content, redirects, metadata) needs a person who owns the mapping and checks it against the live site before cutover. The category-three data (custom logic, non-transferring balances) needs a build decision made weeks before migration day, because rebuilding a checkout script is development work with its own timeline, not a checkbox in a migration app’s dashboard.

The failure mode that produces a bad go-live is almost always the same: category three gets treated like category one. Someone assumes the migration tool “handles everything,” discovers on launch day that the wholesale pricing logic didn’t come across, and is now doing emergency development work in front of live customers instead of on a planned schedule before the old store went dark.

A migration is, underneath the data-transfer language, an operations problem for exactly this reason: it’s a cross-functional handoff — from whoever owns the current platform relationship, to whoever owns the data mapping, to whoever owns the Shopify build — and every dropped handoff shows up as a gap a customer finds first.

Where migrations go wrong, ordered by how often it happens

Redirects mapped incompletely, or not at all. The most common failure, and the most avoidable — a 301 redirect map is a mechanical task with a checkable output (crawl the old sitemap, confirm every URL resolves on the new domain), and it gets skipped anyway because it doesn’t feel like “real” migration work compared to moving products.

Order-history cutoff treated as a technical limit instead of a business decision. Teams either import everything the tool will allow (bloating the new store with orders nobody queries) or accept whatever default the tool ships with, without asking whether that default matches what customer service actually needs to look up.

Custom logic discovered, not planned. This is the single biggest source of post-launch fire drills, because it’s invisible in a data audit and only shows up when a specific piece of storefront behaviour goes missing.

Marketing consent assumed to carry over. A customer who opted into email on the old platform hasn’t necessarily consented under the destination platform’s own record-keeping, and re-sending marketing to a list without verifying consent state is a compliance risk as much as a deliverability one.

Go-live timed around the migration, not around the business. Cutting over mid-promotion, mid-peak-season, or the same week as an unrelated marketing push multiplies the blast radius of any gap that does surface. The redirect map catches most SEO risk; timing catches the rest.

Shopify migration vs Shopify replatforming — the adjacent term it gets confused with

“Shopify migration” and “Shopify replatforming” are used interchangeably often enough that the distinction, where anyone draws one, is worth stating plainly: migration refers to the data move itself — products, customers, orders, content, URLs. Replatforming is the broader project that a migration usually sits inside: the new theme, the rebuilt app stack, the reworked checkout, the redesigned information architecture. A migration can happen without a full replatform — moving the same theme and app stack from one Shopify store to another, for instance. A replatform, almost by definition, includes a migration, because there’s no way to redesign the store without also moving the data that lives in it. Confusing the two leads to the same scoping error from the other direction: a “migration” quote that only covers data transfer gets compared against a “replatform” quote that includes a full rebuild, and the two numbers look wildly different for reasons that have nothing to do with either vendor’s competence.

Who actually does the work: agency, in-house, or a hybrid

The right answer tracks data complexity, not store size. A catalogue with a few thousand SKUs, standard variant structure, and no custom checkout logic is within reach of an in-house team running a reputable migration app with a documented checklist. A store carrying custom subscription logic, a large B2B price-list structure, high order volume with split-shipment history, or several years of loyalty-program data usually needs a migration partner who has handled that specific combination before — not because the transfer itself is harder, but because the edge cases that a generic migration tool doesn’t know to flag are exactly the ones that turn into launch-day surprises.

A hybrid split is common and often the right call: an in-house team or freelancer runs the mechanical data transfer, while a specialist handles the custom-logic rebuild and the redirect map — the two categories with the most judgement calls and the least tolerance for error.

What a realistic Shopify migration costs and how long it takes

Timeline and cost both scale with the category-two and category-three work, not with SKU count alone — a small catalogue with heavy custom logic routinely takes longer than a large, simple one. There’s no reliable published industry average worth quoting here, and a number pulled from memory would be exactly the kind of plausible-looking estimate that’s worse than no number at all. The useful move is to size your own migration by inventorying the three categories before asking anyone for a quote: how much data is category one (fast, low-risk), how much is category two (needs a person and a checklist), and how much is category three (needs a development timeline of its own). A quote built against that inventory is comparable across vendors; a quote built against “move my store” is not.

The one number worth stating plainly, because it’s published and dated: Shopify Plus — relevant if the migration’s destination includes Plus-tier functionality — runs $2,500 USD/month on a 1-year term or $2,300/month on a 3-year term, per Shopify’s own pricing page as checked 13 September 2026. That’s a platform cost, separate from migration labour, and it’s worth confirming directly on Shopify’s pricing page before budgeting, since plan terms change.

Migrating to Shopify from WordPress specifically

WordPress-based stores (usually running WooCommerce) carry a version of the same three-category sort, with a source-specific wrinkle: WooCommerce’s plugin-based architecture means custom logic is often scattered across a dozen small plugins rather than concentrated in one custom build, which makes the category-three audit slower but not fundamentally different. The WordPress-to-Shopify migration guide covers the platform-specific mechanics — plugin-by-plugin equivalents, WooCommerce order-object mapping, and the redirect patterns specific to a WordPress URL structure — in the detail this definition deliberately leaves out.

Migration doesn’t end at go-live — it hands off to ops

A completed migration is the start of steady-state operation on Shopify, not the end of the project. The redirect map needs monitoring for the first few months as crawlers re-index the new URL structure. The category-three rebuilds — the custom logic that had to be reconstructed rather than transferred — need the same testing rigour as any new feature, because they’re new code even if they’re replicating old behaviour. And the order-history cutoff decision made before migration becomes a standing policy for how far back customer service can look, which is worth documenting once rather than re-litigating every time someone asks about a two-year-old order.

That’s the point at which migration stops being a project and becomes an operations question: who owns the redirect map’s ongoing accuracy, who verifies the rebuilt custom logic against the original spec, who decides what happens the next time a platform contract is up for renewal. For a brand doing $3M–$30M with an ops function already stretched thin, that handoff is worth planning as deliberately as the migration itself — see ops automation for how that steady-state ownership gets built, and what Pointerflow does for scaling brands for the broader operating picture a migration sits inside.