Brands rarely leave Magento, BigCommerce, or WooCommerce because they’re bored. Something is usually costing them sales: a checkout that drags on mobile, a Salesforce Commerce Cloud contract that renews at a painful number, or a plugin setup so fragile that the dev team flinches every time an update ships. Shopify tends to look like the obvious answer, and for a lot of merchants it is the right one. The hard part comes a bit later, once someone has to work out what the move will actually involve.
Sales-focused brands feel launch problems faster than most. Organic traffic dips for a month, returning customers get stuck at a login screen, and the discount code printed on last week’s flyers suddenly throws an error. Usually nobody did anything wrong in the build. Somebody simply forgot that a certain page, rule, or app was quietly bringing in money on the old site, so it never made it into the scope.
The planning work sits upstream of the build, and it doesn’t change much depending on who does the building. In-house teams usually split the work between developers, marketers, and ops staff. Brands that bring in a Shopify store migration service hand most of the build to one outside team, yet that team still works from the brand’s own records of what sells. In both cases the project starts from the same document, a plain map of how the current store makes its money.
The checklist below is organized around sales rather than features. Roughly speaking, it moves from traffic to pricing, then to data, connected systems, and finally timing (which also happens to be the order in which these things tend to break).
Most migration scopes start from a feature list, and that’s fine for estimating the build. The trouble is that a feature list describes what the platform can do. It says very little about which of those things paid the bills last quarter. A sales map runs the other way: begin with the pages, offers, and rules that bring in money, and only then figure out which features support them.
Google Analytics 4 will answer most of this in an afternoon. Pull the landing page report for the past 12 months, sort it by revenue, and hold it up against the Performance report in Google Search Console. Pages that sit near the top of both lists are the ones carrying the store. The list is often surprisingly short; a catalog with 8,000 SKUs might get the bulk of its organic sales from two or three hundred URLs.
Those URLs should move with as little change as possible for the first few months: same copy, same slugs where Shopify allows it, same internal links, same reviews. Teams often want to redesign everything at once (it’s tempting, given the fresh start). Holding off for a quarter gives the new store time to settle and gives the data time to show what can safely change.
Pricing logic on an older platform piles up like boxes in a garage. Somebody added a tiered discount for wholesale accounts back in 2019, a free-gift promo applies only to skincare, and the loyalty program stacks with some coupon codes but not with others. Customer service knows about half of these. The other half come to light when an annoyed email lands in the inbox the week after launch.
Before build work starts, it’s worth pulling a full list of active price rules and promotions, including:
Each one then needs a home on Shopify. Native automatic discounts and Shopify Functions cover a lot of ground, and wholesale pricing can usually move into B2B catalogs on Shopify Plus. Loyalty points tend to need an app like Smile.io or LoyaltyLion. Some rules won’t be worth rebuilding at all, and retiring those deliberately is far better than discovering later that they vanished.
A page that ranks on Google’s first page behaves a lot like inventory. It sold something last month and will keep selling, provided nobody breaks the address it lives at. Protecting it involves two separate jobs: pointing every old URL to the right new one, and carrying over the on-page signals that earned the ranking in the first place.
Shopify’s URL structure is fixed. Products sit under /products/, collections under /collections/, and content under /pages/ or /blogs/, with no way to change those prefixes. Stores coming from Magento or BigCommerce almost never match it, which means nearly every indexed URL is about to change.
A full crawl of the old site in Screaming Frog is the usual starting point. Merge that with URLs from Search Console, the XML sitemap, and a backlink export from Ahrefs or Semrush, since a crawl on its own misses orphaned campaign pages that still attract links. From there, each old URL gets a destination in a spreadsheet, ideally the closest matching product or collection. Sending everything to the homepage is the lazy fallback, and Google tends to treat those redirects as soft 404s anyway. Shopify’s redirect tool accepts a CSV upload, so the spreadsheet more or less becomes the redirect file.
Discontinued products deserve a decision as well. A redirect to the parent collection usually holds on to more value than a plain 404.
Redirects get visitors and crawlers through the door, but rankings hold or slip based on what they find inside. Title tags, meta descriptions, alt text, and heading structure should be migrated field by field rather than rewritten by whoever happens to be building the theme.
Structured data is easy to overlook, especially if review stars currently show up in search results. Judge.me, Yotpo, and Okendo all have import tools, although the schema output also depends on the theme. Running key templates through Google’s Rich Results Test before launch catches most problems. Filtered collection URLs need attention too; pages that were indexed on the old platform may be handled differently on Shopify, so canonical tags are worth a second look after the collections go live.
Moving data looks like the most mechanical part of the project, and in a sense it is. Matrixify, LitExtension, Cart2Cart, and Shopify’s own Store Importer app handle the actual transfer well enough. What they can’t do is decide how the data should be structured once it lands. That’s where a fair amount of revenue slips away, because so much retention marketing depends on customer history.
Passwords won’t transfer. They’re stored as one-way hashes, so no tool can carry them over to a new platform. Under classic customer accounts, every returning buyer has to reactivate through an invite email. Shopify’s newer customer accounts drop passwords entirely and use a one-time code sent by email, which takes most of the pain out. Whichever setup is used, customers should hear about the change from the brand first. A short note through Klaviyo (perhaps with a modest thank-you discount) will get opened far more often than a generic system invite.
Order history carries more weight than it seems to. Lifetime value, repeat-purchase segments, and win-back flows are all built on it. Orders need to keep their original dates and stay linked to the right customer records. Notifications should be switched off for the import, too; otherwise a few thousand people receive confirmation emails for purchases they made back in 2022.
Shopify organizes products around variants, with extra attributes stored in metafields and metaobjects. A Magento catalog built on configurable products with a dozen custom attributes rarely maps across one to one. Some products will need splitting or merging, and some may work better grouped through Shopify’s Combined Listings app. Checking the current variant limits in Shopify’s documentation early saves an awkward rebuild halfway through.
Anything representing money a customer already holds has to be reconciled carefully. Gift card balances, store credit, and loyalty points should match to the cent before and after cutover. Subscriptions take the most coordination. Recurring billing relies on saved payment tokens, and moving those typically involves the payment processor (Stripe, Braintree, or whichever one is in place) plus the subscription app, whether that’s Recharge, Skio, or Shopify Subscriptions. Token migrations can take several weeks to arrange, so they belong near the start of the timeline rather than the end.
Customers never see the integrations behind a store, but they notice quickly when one fails. Orders stop reaching the warehouse, stock levels drift out of sync, and the support inbox fills up. Mapping this layer means writing down every app and system the current store depends on, both on the storefront and in the back office.
A product-label extension built for Magento almost never has an identical twin on the Shopify App Store, and frankly it doesn’t need one. It helps to describe what each plugin actually does in plain terms (shows low-stock badges, sells bundles, calculates tax by state) and then look for the simplest way to cover that job. Shopify Flow, Shopify Markets, and the free Shopify Bundles app handle a good share of work that used to require custom code. Fewer apps generally means faster page loads and a lower monthly bill.
ERP, warehouse, and shipping integrations deserve a diagram of their own. A brand using NetSuite for finance, ShipStation for fulfillment, and Gorgias for support has at least three data flows that need to work from the very first order. For each one, document what data moves, in which direction, and how often. Inventory sync timing is the classic weak point: a 15-minute delay that never caused trouble on the old store can lead to overselling during a flash sale. These flows should be tested with real orders on a development store, because a green “connected” status in the app settings only confirms that a connection exists.
For a brand that tracks revenue week by week, the launch date matters nearly as much as the build. The same store, launched in two different weeks, can lose very different amounts of money while things settle.
Most merchants avoid launching anywhere near Black Friday and Cyber Monday, and many put a code freeze in place from October through the holidays. For general retail, late January through March is a common choice. Seasonal brands have to read their own sales curve; a swimwear label and a ski-gear shop will end up picking very different months.
The plan should also include a delta migration. The bulk import runs weeks ahead of launch, and a final sync on cutover day brings over the orders, customers, and reviews created since then. Product and content edits on the old platform need to freeze during that final stretch, or a carefully made price change can disappear somewhere between the two systems.
Arguing about whether the new store is performing well during launch week rarely goes anywhere useful. It’s much easier when the team has agreed on the numbers beforehand and recorded a baseline from the old platform. A typical set includes:
These metrics need close watching for 30 to 60 days after launch. Some fluctuation is expected while Google processes the redirects and returning customers get used to the new layout. A steady decline in one specific metric is another matter, since it usually traces back to something that was missed in the map, and that kind of gap is much easier to find when a written map exists.
Moving to Shopify can give a sales-driven brand a quicker checkout, lower running costs, and a simpler tech stack. Those benefits depend on the parts of the old store that make money today arriving intact. High-earning pages, pricing rules, redirects, customer and order history, stored value, and connected systems should all appear on the map before the first product is imported.
Most of this work happens in spreadsheets, crawl reports, and fairly unexciting meetings with finance and warehouse staff. Brands that put the time in early tend to hit their launch date and spend the following quarter on growth rather than on tracking down what went missing. Last year’s revenue report is a sensible place to begin, since it shows which items on the map deserve attention first.
