Moving a store to a new platform is part data project, part website rebuild and part change of daily habits. The parts that go wrong are rarely the obvious ones. Products usually come across. What gets lost is the detail: variant options that do not map cleanly, old product URLs that now return errors, customers who cannot log in, marketing consent that did not travel with the email addresses, or an app feature nobody remembered until a customer asked for it.
This checklist breaks a migration into stages: deciding, inventorying, mapping, moving, redirecting, testing and launching, with the details that are easiest to miss.
Key takeaways
- Write down why you are moving and what the new platform must do; use it to test the decision.
- Inventory everything the old store does, including what apps and custom code provide.
- Map data fields before importing. Products, variants, customers and orders rarely line up one to one.
- Redirect every URL that has traffic or links, and check them after launch.
- Test real orders end to end before switching the domain.
Stage 1: Decide, with a list of requirements
Moves are expensive in time, so be clear about the reasons. Common ones include costs that no longer fit, features you need that the current platform cannot provide, selling in new markets or channels, or a platform that is being discontinued.
Write two short lists:
- Must have: features and processes the store cannot run without, such as variant handling, multi-currency, wholesale pricing, subscriptions or specific payment methods.
- Nice to have: things that would help but are not essential.
Then check each requirement on the new platform, ideally in a trial store, before committing. Ask how each must-have is provided: built in, through a theme setting, through an app or through custom code. Our guide to choosing between an app, a theme setting or custom code explains the trade-offs.
Stage 2: Inventory the old store
Make a list of everything the old store contains and does. This is the step most often rushed.
| Area | What to record |
|---|---|
| Products | Count, variants, options, custom fields, images, bundles, digital products |
| Content | Pages, blog posts, policies, FAQs |
| Customers | Count, account status, tags, marketing consent for email and SMS |
| Orders | How much history you need on the new platform |
| URLs | Every product, collection, page and post URL, plus existing redirects |
| Apps and integrations | What each one does, what data it holds, whether you still need it |
| Custom code | Theme edits, tracking, scripts and any custom features |
| Settings | Shipping, taxes, payments, checkout, notifications, domains, email |
| Ongoing commitments | Gift cards, store credit, subscriptions, preorders, loyalty points |
Our guide to backing up and exporting your store data covers how to export most of this, and what standard exports leave out.
Apps and features
For every app on the old store, decide one of three things: replace it on the new platform, cover the feature another way, or drop it. Note any data the app holds, such as reviews, subscriptions or loyalty balances, and how it can be exported. Our checklist for choosing apps applies when picking replacements.
Stage 3: Map the data
Platforms structure data differently. Before importing anything, decide how each field on the old platform maps to the new one.
| Old data | Things to check on the new platform |
|---|---|
| Product options and variants | Limits on the number of options and variants per product |
| Custom fields | Whether there is an equivalent, and how it is displayed |
| Categories and collections | Manual vs rule-based grouping, nesting |
| Product URLs (handles or slugs) | Whether you can keep the same slugs, and the URL prefix pattern |
| Images | Order, alt text and which image belongs to which variant |
| Customer accounts | Whether passwords can be moved (usually not) |
| Marketing consent | Separate fields for email and SMS, and consent dates if available |
| Orders | Whether historical orders can be imported, and how they are marked |
| Gift cards and store credit | Balances, codes and expiry dates |
| Taxes | How tax settings and tax-inclusive prices are handled |
Run a small test import of a few products first, including your most complicated one, and check them carefully before importing everything.
Customer accounts
Customer passwords are normally stored in a form that cannot be read back, so they usually cannot be migrated. Plan to invite customers to set a new password or activate their account on the new store, and explain why in a short service message.
Subscriptions and saved payment methods
Moving recurring payments or saved cards usually requires the cooperation of your payment providers, and sometimes is not possible. Check this early, because it can decide the timing of the whole move.
Stage 4: Build and move
- Build the new store on a temporary address, with the domain still pointing at the old store.
- Rebuild the theme and pages rather than copying old layouts blindly. It is a good moment to fix weak product pages, such as missing sizing, specs or delivery information.
- Import products and content, then customers and orders if you are moving them.
- Set up shipping, taxes, payments and notifications using your settings document from Stage 2.
- Recreate essential features with the apps, settings or code you chose.
- Freeze changes on the old store close to the switch, so the data you imported stays current. Plan a final import of anything that changed during the build, such as new customers or stock levels.
Stage 5: Redirects
URL patterns usually change between platforms. A product at one address on the old store may sit under a different prefix on the new one. Without redirects, links from search results, other websites, emails and social posts lead to error pages.
- Export every old URL, from the old platform, your sitemap or a site crawl.
- Match each old URL to its new equivalent in a spreadsheet: product to product, collection to collection, post to post.
- Use permanent (301) redirects.
- For removed products, redirect to the closest equivalent or a relevant collection, not the home page. Our guide to sold-out and discontinued product pages explains the choices.
- Keep existing redirects from the old store, updated to point at the new URLs, so you do not create chains.
- Import the redirects before switching the domain.
Stage 6: Email lists and consent
- Move consent status with every customer, separately for email and SMS where you collect both.
- Do not add people to marketing who had not agreed to it on the old store.
- If you change email tools at the same time, set up domain authentication for the new sender before sending to the full list. See email deliverability basics.
- Check that unsubscribes carried over, so nobody who opted out receives marketing from the new store.
Stage 7: Test before launch
| Test | What to check |
|---|---|
| Orders | Place real test orders with each payment method and shipping option; refund them |
| Taxes and shipping | Correct amounts for your main destinations |
| Discounts and gift cards | Codes and balances work as expected |
| Emails | Order, shipping and account emails send, with correct branding and links |
| Products | Spot-check variants, prices, stock, images and descriptions |
| Redirects | Test a sample of old URLs, including your top traffic pages |
| Mobile | Browse and buy on a phone |
| Tracking | Analytics and any ad tracking you use record test orders correctly |
| Forms | Contact, newsletter and back-in-stock signups store data and consent properly |
Stage 8: Launch day and after
- Switch the domain at a quiet time, following both platforms’ instructions.
- Check the store over a secure connection once the domain and certificate are active.
- Submit the new sitemap to search engines and watch for crawl errors.
- Check old URLs again, especially pages with backlinks.
- Watch orders, payments and emails closely for the first days.
- Keep the old store accessible but closed to customers until you are confident nothing is missing, then cancel it after a final export.
Search traffic can fluctuate after a migration, even when it is done well. Careful redirects and matching content are the best protection.
FAQ
How long does a migration take?
It depends on catalog size, custom features and how much history you move. A small, simple store may take a few weeks of part-time work; a store with subscriptions, many variants and custom code takes much longer. Build in time for testing.
Should I hire someone?
If you have custom code, subscriptions, large catalogs or limited time, a developer or migration specialist can reduce risk. Our guide to working with a freelance store developer covers scoping the work and giving safe access.
Can I keep my domain?
Yes. You point your existing domain at the new platform. Keep control of the domain account yourself throughout.
Bottom line
Decide with a written list of requirements, inventory everything the old store does, and map the data before importing. Redirect every old URL with traffic or links, move marketing consent with each customer, and test real orders end to end before switching the domain. Keep the old store and a full export until the new one has proven itself.
