Magento Migration Guide: Moving to Shopify or WooCommerce

A Magento store should plan a move when its 2.4.x release line is leaving Adobe's support window, when upgrade and extension maintenance costs more than the platform returns, or when the business no longer needs Magento's flexibility. The usual destinations are Shopify (hosted, less to maintain) and WooCommerce (self-hosted on WordPress, more control), and staying on a supported Magento or Adobe Commerce release is also a legitimate choice. Whichever you pick, the migration succeeds or fails on three things: a complete data inventory, a URL-level redirect map, and a cutover plan with a rollback path.

This guide is written for store owners, operations leads and in-house developers at small and mid-size merchants in the US, UK and EU. It covers when to move, how to choose, what data has to travel, how to redirect thousands of URLs without losing search equity, what happens to extensions and B2B features, and a phased plan you can adapt.

When a Magento store should move (and when it shouldn't)

The support lifecycle is the first trigger

Magento 1 reached end of life in June 2020, so any store still on Magento 1 is running software with no official security patches and should treat migration as urgent.

For Magento 2, Adobe publishes the support window for each 2.4.x release on its Adobe Commerce software lifecycle policy page. As of September 2026, that page lists:

Two details matter for planning. First, Adobe describes a three-year standard support window from each release's general availability date. Second, the security patch release notes state that extended support security patches are available to Adobe Commerce customers only and are not available for the Magento Open Source code base. In practice, a Magento Open Source store on 2.4.6 or earlier is already outside the window where Adobe publishes patches for it. Check the lifecycle page yourself before you commit to a date, because Adobe revises it.

Other signals that a move is worth evaluating

• Every minor upgrade turns into a project because of custom code and third-party extensions that break.
• Hosting, performance tuning, search (OpenSearch) and caching need specialist attention the team no longer has.
• The catalogue and order volume have stabilised at a size a hosted or WordPress-based platform handles comfortably.
• The business wants marketers and merchandisers to publish content without a developer.
• Security scanning and PCI questionnaires keep flagging the platform layer rather than your own code.

When staying is the better answer

Staying on Magento Open Source or Adobe Commerce and upgrading to a supported release (2.4.8 or 2.4.9 as of this writing) is often right when:

• The store depends on heavily customised pricing, configurators or ERP logic that would need rebuilding elsewhere.
• You run many storefronts, languages and currencies from one back office and the setup works.
• You use Adobe Commerce's B2B module (company accounts, shared catalogs, quotes, requisition lists) extensively and a replacement would mean several apps or plugins stitched together.
• The upgrade effort is smaller than a re-platform once you count redirects, retraining, integrations and lost momentum.

A good migration decision compares the cost of *staying current* on Magento, not the cost of staying on an unsupported version.

Shopify vs WooCommerce vs staying: a decision matrix

If you are weighing the two main destinations in more depth, the Shopify vs WooCommerce comparison on cost, SEO and ownership goes through the trade-offs in detail.

A useful shortcut: if the team wants to stop managing servers and the catalogue fits Shopify's model, Shopify is usually the simpler landing. If content, URL control or custom logic matter more, and someone will own WordPress maintenance, WooCommerce fits better.

The data inventory: what has to move

Before you pick a migration tool, list every data type the store holds, where it lives in Magento, and how it maps to the destination. Treat each row as its own workstream with an owner and an acceptance test.

Products and configurable variants

Magento models products as simple, configurable, grouped, bundle, virtual and downloadable types. Configurable products are parents whose children are simple products selected by attributes such as size and colour.

• Shopify: a product with variants defined by options. Check the current option and variant limits for your plan against your largest configurable products, and plan how bundles and grouped products will be represented (native bundles, an app, or separate products).
• WooCommerce: variable products with attributes and variations map closely to configurables. Grouped products exist natively; bundles usually need an extension. WooCommerce's product CSV importer and exporter handles simple and variable products.

Also inventory attribute sets, custom attributes used for filtering (layered navigation), tier and customer-group pricing, special prices with date ranges, multi-source inventory, images and alt text, and SEO fields (URL key, meta title, meta description).

Customers and password handling

Customer records, addresses, customer groups and newsletter status can be exported. Passwords are the exception. Magento stores salted password hashes in its own format, and neither Shopify nor WooCommerce can verify them out of the box. Plan for customers to set a new password:

• On Shopify, imported customers typically receive an account invitation or use the password reset flow.
• On WooCommerce, customers can use the lost-password flow; custom code or a plugin that verifies legacy hashes on first login is possible but needs a security review.

Draft the customer email before launch. Explain the change plainly, avoid anything that looks like a phishing message, and only send it to people you have a lawful basis to contact. For EU and UK customers, a service message about their existing account is different from marketing email; keep them separate. This is general information, not legal advice.

Orders, CMS content, reviews and everything else

• Orders: decide how much history you need in the new admin versus an archive (a read-only export or the old database kept offline). Historical orders on Shopify come in through migration apps or the API, as described in Shopify's Migrate to Shopify guide.
• CMS pages and blocks: Magento CMS pages, static blocks and Page Builder content need rebuilding, not just copying, because layout markup does not transfer cleanly.
• Reviews: native Magento reviews or a third-party review service; confirm the destination can import them with ratings, dates and product association intact.
• Promotions: cart price rules, coupon codes and gift cards rarely map one to one. Rebuild the active ones and let expired ones go.
• Tax, shipping and payment configuration: rebuild and test rather than migrate. EU/EEA card payments still need Strong Customer Authentication under PSD2, so test 3-D Secure flows on the new checkout.
• URL rewrites: Magento's url_rewrite table holds the product, category and custom URLs the store actually serves, including historical ones. Export it; it is the backbone of your redirect map.

Redirect mapping at scale

Google's guidance on site moves with URL changes recommends server-side permanent redirects (301 or 308), mapping each old URL to its closest equivalent, and keeping redirects for as long as possible, generally at least a year. For a Magento store with tens of thousands of URLs, that means building the map from data rather than by hand.

Build the source list from several places

1. 1The url_rewrite export (every URL Magento knows about).
2. 2A crawl of the live site.
3. 3Search Console's top pages and pages with links.
4. 4Analytics landing pages over the last 12 months.
5. 5Backlink data for URLs that other sites link to.

De-duplicate, then join each old URL to the new product, category or page by a stable key such as SKU or entity ID rather than by title.

Example redirect map

Do not redirect every retired URL to the homepage; Google may treat that as a soft 404. If nothing relevant exists, a 404 or 410 is the honest response.

Where the redirects live

• Shopify: URL redirects are managed in the admin and can be imported by CSV. Shopify's URL redirect documentation notes that redirects only fire for URLs that would otherwise return a 404, lists reserved paths that cannot be redirected, and sets a maximum number of redirects per store (higher on Shopify Plus). Check your map against those limits early.
• WooCommerce: redirects can live in a plugin or, for large maps, at the web server. A server-level map is faster and survives plugin changes. An nginx example, with the map block in the http context:

`nginx

# http {} context

map $uri $magento_redirect {

default "";

/mens-trail-shoe-blue.html /product/mens-trail-shoe/;

/mens-trail-shoe-blue-42.html /product/mens-trail-shoe/;

/footwear/trail.html /product-category/footwear/trail/;

include /etc/nginx/redirects/magento-map.conf;

}

server {

# ...

if ($magento_redirect) {

return 301 $magento_redirect;

}

}

`

The map uses $uri (the normalised path without the query string) so that tracking parameters do not break matches. Each line in the included file is a source and destination pair ending with a semicolon. See the nginx map module documentation for matching rules; large maps may need map_hash_max_size and map_hash_bucket_size raised.

Test the full map with a script that requests every old URL and checks for a single 301 hop to a URL that returns 200. The website redirects guide for migrations and redesigns covers chains, loops and testing in more depth.

Extensions, integrations and B2B features

List every installed Magento module, then classify each one:

• Replace with native functionality: many stores find that features they bought as extensions (for example basic SEO fields, simple promotions or sitemap generation) exist natively on the destination.
• Replace with an app or plugin: search, reviews, subscriptions, loyalty, product feeds, ERP and PIM connectors, shipping-rate calculators.
• Rebuild as custom code: bespoke pricing logic, configurators, integrations with in-house systems. On Shopify this may be a custom app or checkout extension; on WooCommerce a custom plugin.
• Drop: anything no one can name a current use for.

For each integration (ERP, warehouse, accounting, marketing platform, marketplaces) document the data direction, frequency, identifiers used and who owns the connection after launch. Integrations are where cutovers most often slip, because they depend on third parties.

B2B features deserve their own line. If the store uses Adobe Commerce B2B, list exactly which capabilities are in daily use: company accounts with multiple buyers, shared catalogs and negotiated prices, quote requests, requisition lists, purchase orders and payment on account. Then check each against Shopify's native B2B features for your intended plan, or against specific WooCommerce extensions. Gaps here can decide the platform choice on their own.

Analytics and marketing tags are rebuilt too. For EU and UK visitors, non-essential cookies and tags still need prior consent under ePrivacy rules and PECR, and Google Consent Mode v2 is required for ad measurement in the EEA and UK. Configure the consent banner on the new platform before launch, not after.

A phased migration plan

The phases below are a structure, not a timeline. Duration depends on catalogue size, custom code, integrations and how much content is rebuilt.

Phase 1: Discovery and decision

• Record the current Magento version, edition, extensions, integrations and hosting.
• Confirm lifecycle dates on Adobe's page and decide between upgrade and re-platform.
• Export baselines: organic landing pages, top queries, revenue by landing page, conversion rate, Core Web Vitals, crawl of all URLs.

Phase 2: Data mapping and build

• Build the field-level mapping for products, customers, orders, content and reviews.
• Choose tools: a migration app, CSV imports, API scripts, or a mix.
• Build the theme, navigation and templates; rebuild CMS content.
• Replace or rebuild extensions and integrations.

Phase 3: Trial migrations and QA

• Run at least one full trial migration into a staging store and reconcile counts (products, variants, customers, orders) against Magento.
• Spot-check prices, stock, images, attributes and SEO fields on a sample of products.
• Test real journeys: search, filter, add to cart, checkout with each payment method including 3-D Secure, account creation, password reset, order emails, returns.
• Run the redirect test script against staging.

The e-commerce migration testing checklist has a fuller pre-launch and post-launch test list.

Phase 4: Cutover

Freeze catalogue and content changes in Magento, run the final delta migration (new orders and customers since the last trial), and switch DNS or the storefront.

Phase 5: Stabilise and monitor

Watch errors, redirects, indexing and revenue daily for the first weeks, then weekly. Keep Magento available read-only for reference until you are confident nothing is missing.

Cutover and rollback checklist

Before cutover

• [ ] Full Magento database and media backup taken and restore-tested
• [ ] Final trial migration reconciled with no unexplained count differences
• [ ] Redirect map imported and every row tested on staging
• [ ] Payment gateways switched to live mode and tested with a real low-value order
• [ ] Tax and shipping rules checked for each market you sell to
• [ ] Transactional emails, sender domain (SPF, DKIM, DMARC) and customer account email ready
• [ ] Consent banner, analytics and conversion tags verified
• [ ] XML sitemap generated; robots.txt allows crawling of the new store
• [ ] DNS TTL lowered in advance; team contacts and decision-maker for rollback agreed

During cutover

• [ ] Content and catalogue freeze announced and enforced
• [ ] Final delta of orders, customers and stock migrated and reconciled
• [ ] DNS or domain connected; SSL certificate active
• [ ] Spot-check 50+ old URLs for a single 301 to a live page
• [ ] Place test orders across payment methods and confirm fulfilment and integration sync

Rollback criteria and steps

• [ ] Written triggers, for example checkout unavailable, payments failing, or integration sync broken beyond a set window
• [ ] Old Magento store kept intact and able to serve traffic again by reverting DNS
• [ ] Plan for orders placed on the new platform during the failed window (export and re-key)
• [ ] Communication template for customers and staff

After cutover

• [ ] Submit the new sitemap in Search Console and watch the Page indexing report
• [ ] Monitor 404s daily and add missing redirects
• [ ] Compare organic landing-page traffic and revenue against the baseline
• [ ] Keep redirects in place for at least a year, ideally indefinitely

Getting the move right

A Magento migration is less about the import tool and more about discipline: knowing every data type and URL the store owns, deciding deliberately what to rebuild, and keeping a way back until the new store has proven itself. If you are moving from WooCommerce rather than Magento, the WooCommerce to Shopify migration checklist covers that path specifically.

If you would like help deciding between upgrading Magento, moving to Shopify or moving to WooCommerce, or want a second pair of eyes on your redirect map and cutover plan, see our e-commerce solutions or get in touch to talk through your store.