Leaving Magento: Where Merchants Land and What Each Destination Costs to Keep Running

For most small and mid-size merchants leaving Magento, the best destination is WooCommerce, unless one of the conditions in this guide applies: a very large catalogue, heavy business-to-business pricing rules, many storefronts and currencies, or deep two-way integration with an ERP (the system that runs stock, accounting and fulfilment). If one of those is true for you, a hosted platform or a headless engine, or staying on a maintained Magento, can be the better call, and we say below how to tell.

This guide is for the person who owns the store or manages ecommerce, not for a developer. We explain each technical term the first time it appears. Nothing here is legal, financial or compliance advice, and we give no prices because they change and depend on your setup.

In this guide

• What the Magento support dates mean for your store, and why “it still works” is not a plan
• Where merchants land: WooCommerce, a hosted platform, a headless engine, or staying on Magento
• A decision table by merchant type
• What a migration actually moves, and what it cannot
• What each destination costs to keep running
• How we would approach a Magento to WooCommerce move, and when we would say it is the wrong fit
• Questions people ask

What do the Magento support dates mean for my store?

They tell you how long the vendor will keep fixing security problems in the version you run. After that date, a newly found weakness in your version may stay unfixed, and your store keeps taking card payments on code nobody is patching. Read the dates against the version you actually run, and read the fine print about your edition.

We read Adobe’s software lifecycle policy page on Experience League on 8 October 2026. For Adobe Commerce, it lists these dates:

Release	General availability	End of standard support	End of extended support
2.4.6	14 March 2023	11 August 2026	31 August 2027 (then a security-only period to 31 May 2028)
2.4.7	9 April 2024	31 May 2027	31 May 2028
2.4.8	8 April 2025	31 May 2028	Listed as to be decided
2.4.9	12 May 2026	31 May 2029	Listed as to be decided

Two details matter. First, the page says Adobe offers one year of additional support at no additional cost for Adobe Commerce customers on versions 2.4.6 and 2.4.7. The words “Adobe Commerce customers” are doing work in that sentence. Second, the page does not mention Magento Open Source at all. It does not say that Open Source gets extended support, and it does not say it does not. So for Open Source, check your edition: confirm in writing, from Adobe or from whoever maintains your store, which dates apply to the edition you run. Do not assume the Adobe Commerce table is yours.

The same page describes a security-only transitional period for 2.4.4, 2.4.5 and 2.4.6 and calls it a one-time exception that will not be extended beyond the published dates.

Why “it still works” is not a plan

A store on an unsupported version works until the day it does not, and that day is usually chosen by someone else: a payment provider raising its requirements, a PHP version your host retires, or a newly published vulnerability. The symptom is quiet: nothing looks wrong. The check is simple. Write down your exact Magento version, your edition, your PHP and database versions, and the end-of-support date for each. If any date is in the past or inside the next twelve months, you have a project to schedule, whether that project is an upgrade or a move. The fix is to choose the destination deliberately, with a date. Prevention is a calendar: we keep one for open-source software generally, in our open-source maintenance calendar.

Where do merchants land after Magento?

There are four realistic destinations: WooCommerce, a hosted platform such as Shopify, a headless open-source engine such as Medusa or Saleor, or staying on Magento with a maintained version or the community fork. Each section below says what it is, who it suits, and what running it involves.

WooCommerce

What it is. WooCommerce is an ecommerce plugin for WordPress. You own the code and the data, and you choose the hosting. Its documentation currently recommends PHP 8.3 or greater, MySQL 8.0 or greater or MariaDB 10.6 or greater, WordPress 6.9 or greater, and HTTPS (we read that page on 8 October 2026).

Who it suits. Merchants with a catalogue from a few hundred to tens of thousands of products, normal tax and shipping needs, one or a few storefronts, and a wish to own the content side (blog, landing pages, SEO) in the same system as the shop.

What running it involves. You need hosting sized to your traffic, a plan for updating WordPress, WooCommerce, the theme and every extension, a staging copy to test updates, backups you have actually restored once, and search that suits your catalogue. Someone has to own all of that. For orders, WooCommerce has High-Performance Order Storage (HPOS), which keeps orders in dedicated database tables with their own indexes instead of in the general WordPress posts table. Its documentation says HPOS is enabled by default for new installations from WooCommerce 8.2 onward, and that if an installed extension is not compatible, the option to switch is disabled. That second point is why we check extensions before any move.

A hosted platform such as Shopify

What it is. Shopify describes itself as a cloud-based and hosted platform. In plain words, the vendor runs the hosting and you rent the platform, so you do not manage servers.

Who it suits. Merchants who want the least technical upkeep and are happy to work inside the platform’s rules, with apps for anything it does not do. It is a strong fit when you have no one to own hosting and updates, and your needs are mainstream retail. We cover the trade-offs in more depth in WooCommerce vs Shopify: When to Migrate or Stay, so we will not repeat them here.

What running it involves. No server work. You still manage the apps you install, the theme, your product data and your redirects. You also accept that the checkout and some data structures follow the platform’s design, and that moving away later is its own migration.

A headless open-source engine such as Medusa or Saleor

What it is. “Headless” means the shop’s back end (products, carts, orders) is separate from the storefront that customers see, and the two talk through an interface called an API. You build the storefront yourself. Medusa describes itself as an AI-native commerce platform with a framework to build custom commerce features. Its repository is MIT licensed for the core, as an open-core model: some enterprise features need a commercial agreement. Its documentation lists Node.js (v20.19.0 or later, or v22.12.0 or later) and PostgreSQL as prerequisites. Its latest release was v2.21.2 (28 September 2026). Saleor describes itself in its repository as a high performance, composable, headless commerce API. It is BSD-3-Clause licensed, its latest release was 3.23.40 on 7 October 2026, and its project configuration requires Python 3.12. Its documentation offers a managed option (Saleor Cloud) and self-hosting, and describes Docker for local setup.

Who it suits. Merchants with a development team, unusual business rules, or several storefronts and sales channels that a plugin-based shop strains to cover. It gives the most freedom, because nothing is pre-built that you did not choose.

What running it involves. The most. You run or buy hosting for the back end and the storefront separately, you build and maintain the storefront, search, checkout and payment integrations, and you patch the framework and its dependencies yourself. For the longer discussion of when separating the front end is worth it, see Headless WooCommerce: Worth It for Your Store or Not?.

Staying on Magento: a maintained version or the community fork

What it is. Two options. One is to upgrade to a version that is still inside its support window. The other is Mage-OS, which describes itself as a community-owned ecommerce platform, fully open source, run by the Mage-OS Association. Its site says it is built on Magento 2.4.9 and supports migration from Magento Open Source. The Mage-OS repository on GitHub shows a latest release of 3.5.0 on 8 September 2026 under the OSL-3.0 licence, the same licence shown on Magento’s own repository, whose latest release is 2.4.9 (12 May 2026).

Who it suits. Merchants with a large, heavily customised store, a working relationship with a Magento development team, and business rules (B2B pricing, multi-store, ERP links) that already work. Moving away would mean rebuilding things that are not broken.

What running it involves. The same as today: a search engine service, a cache layer, a capable server, a developer who knows the platform, and upgrades that are real projects, because extensions and custom code have to be tested against each release. Staying is a legitimate answer, but it means committing to that upgrade work.

Which destination fits which kind of merchant?

Use this table as a starting point. The first row that matches your biggest constraint usually decides it. If two rows match, the stricter one wins.

Merchant type	Likely best fit	Why	Watch for
Under about 10,000 products, one storefront, standard B2C	WooCommerce, or Shopify if you have no one to own upkeep	Everything needed is mainstream on both	Choose by who will own updates, not by feature lists
Large catalogue (hundreds of thousands of products or more)	Staying on a maintained Magento, or a headless engine	Search, indexing and import speed become the main engineering problem	WooCommerce can hold large catalogues with the right engineering, but we would test your numbers first
Heavy B2B: customer-specific price lists, quotes, approvals, credit terms	Magento (maintained) or a headless engine	These rules are core features there, and extensions elsewhere	Count how many rules you really use, since many stores use few
Many storefronts, currencies or languages from one back office	Magento (maintained), or Saleor or Medusa with a development team	Multi-store is a first-class idea there	WooCommerce can run several sites, but each is its own shop to maintain
Deep ERP integration, two-way, in real time	Whatever your ERP vendor and integrator already support best	The integration is the project; the storefront is secondary	Ask who builds and maintains the connector after launch
No in-house developer, small team, content matters	WooCommerce with a care plan, or Shopify	Lowest total moving parts	Never run any of them without a named owner for updates
In-house developers who want full control of the storefront	Headless (Medusa or Saleor), or WooCommerce used as a back end	Freedom to build exactly what you need	You are signing up to maintain a custom product

The table is a guide, not a verdict. List what your store does today that you would hate to lose, and ask each destination how it is done.

What does a migration actually move?

A migration moves data and rebuilds behaviour. Data is the easier half. For each item below we explain what moves, what does not, and what to check.

Products and variants

Products, their descriptions, images, categories, prices and stock levels can move. Variants (a shirt in three sizes and four colours) need careful mapping because platforms model options differently. A product in Magento may be “configurable” with several “simple” children; in WooCommerce that becomes a “variable” product with variations. WooCommerce’s built-in product CSV importer handles simple, variable, grouped, external, variation, virtual and downloadable products, and supports fields such as SKU, name, pricing, stock, categories, tags, images and attributes (we read its documentation on 8 October 2026). It also states limits: large imports depend on your server’s memory, upload limits and processing time, so big catalogues may need splitting into batches; image URLs behind redirect scripts are not supported; and you cannot assign a specific post ID to a new product. How to check: import a sample of 50 products that cover every product type you sell, and compare them with the originals side by side. Prevention: clean the data first. Duplicate SKUs and missing images are cheaper to fix before the move.

Customers, and why passwords usually cannot move

Names, emails, addresses and order links can move. Passwords usually cannot be carried over in a form the new system can use, because they are stored as one-way hashes made by the old platform’s method, and a new platform will normally expect its own. In practice customers set a new password through a “reset your password” email. Plan the reset email and its wording early, because an unexpected one can look like phishing. How to check: test the whole reset flow with real mailboxes, including spam folders. Prevention: warn customers before cut-over.

Orders and history

Past orders matter for customer service, returns, accounting and tax records. They can be imported as historical records, with their totals, line items, addresses and statuses. They will not behave like live orders: you generally do not want old orders to trigger emails, stock changes or payments. Decide how many years of history you need in the new shop, and keep a searchable archive of the rest. Ask your accountant what records you must keep, since we cannot advise on that. On WooCommerce, imported orders land in the order tables described by HPOS, so the import tool needs to be one that writes to the correct storage. How to check: reconcile totals by month between old and new.

URLs and redirects

Your product and category addresses carry years of search ranking. If the addresses change, each old address should send visitors, and search engines, to its new equivalent. Google’s documentation on site moves with URL changes says to map old URLs to new ones before the redirects go live, to use server-side permanent redirects (301 or 308) where technically possible, to avoid long redirect chains (it says to keep them under three hops if you can, and not beyond five), and to keep the redirects for as long as possible, generally at least one year (we read that page on 8 October 2026). It also advises submitting new sitemaps in Search Console. How to check: crawl the old site before the move to get a full list of addresses, then test every one after launch and chase each that does not land on a relevant page. Prevention: keep the redirect map in version control so it survives later redesigns.

SEO metadata

Page titles, meta descriptions, canonical tags, image alt text, structured data and the text of category pages are easy to lose because they live in extensions or in fields the importer does not know about. The fix is a field-by-field list made during the audit, since a page that kept its address but lost its title can still drop in search. Google’s site move guidance also notes that new pages should carry self-referencing canonical tags and that internal links should be updated to the new addresses.

Payment tokens and subscriptions

Stored cards are the item most likely to disappoint. A “token” is a reference your payment provider holds in place of the real card number, and it usually belongs to the provider account and the platform connection that created it. Moving the store does not by itself move the tokens. There are two routes: ask customers to enter their card again on first purchase, or, if you stay with the same payment provider, ask that provider whether it can transfer or reuse the stored payment methods at the provider level. We would ask this early, because it decides whether subscriptions can renew without customers doing anything. If it cannot be done, plan a customer message and a short re-entry window. We do not promise a transfer; that depends on the provider and your contract.

Integrations

Every connection between your store and another system (ERP, warehouse, shipping, accounting, email marketing, reviews, tax) has to be rebuilt or replaced, because the old connectors were written for Magento. List them all in the audit, with what each sends and receives, how often, and who depends on it. Integrations are where plans slip, so we treat the list as a gate.

What does each destination cost to keep running?

We leave prices out, since they change. Here is the running side in words: who patches, how upgrades happen, what search and performance need, and what changes in payment and compliance scope.

Destination	Who patches	How upgrades happen	Search and performance	Payments and compliance scope
WooCommerce	You or your agency: core, plugins, theme, PHP, server	Updates applied on a staging copy, tested, then pushed live	Hosting and caching you choose; search plugin or external search service for big catalogues	Depends on checkout method: a hosted payment page keeps card data off your server
Hosted platform (Shopify)	The vendor runs the platform; you manage apps and theme	Platform changes arrive on the vendor’s schedule; app updates are yours to watch	Handled by the vendor; limited by platform design	Ask the vendor which parts it covers and which remain yours
Headless engine (Medusa, Saleor)	You or your developers: framework, dependencies, hosting, storefront	Version upgrades are development projects	You design caching and search; the freedom is the cost	Depends on the payment integration you build
Magento, maintained or Mage-OS	You or your Magento agency; the edition and its support terms decide what the vendor still fixes	Each release means testing extensions and custom code	Needs a dedicated search service and a capable server	Same as today unless you change the checkout

Patching and upgrades

On self-managed options, the symptom of neglect is a site that is two or three major versions behind and cannot be updated in one step. The check is to list every component with its installed and latest version once a month. The fix is small, regular, tested updates, rather than a yearly rescue. The prevention is a named owner, a staging copy and a rollback plan. With a hosted platform the platform part is done for you, but theme and app updates still need an owner.

Search and performance

Product search is where catalogue growth shows first. The symptom is slow or irrelevant results; the check is to run your twenty most common customer searches and read the top results; the fix is usually a dedicated search service rather than the built-in database search. Slow category pages usually point to hosting, caching and database indexing. Test with your real catalogue size, not a demo.

Payments and compliance scope

PCI DSS is the card industry’s security standard. The PCI Security Standards Council describes it as providing a baseline of technical and operational requirements designed to protect payment account data. “Scope” is what falls under those requirements: the systems that store, process or transmit card data, or could affect the security of the environment that does. The less card data touches your own servers, the smaller your scope. Using a payment page hosted by your provider usually reduces it, on any platform. Which questionnaire you must complete depends on how you take payments, so ask your payment provider and your acquiring bank rather than assuming.

How would we approach a Magento to WooCommerce move?

Below is our approach, as steps. It describes how we work, not a count of past projects or a promised outcome. Your store sets the details.

1. Audit. Inventory the catalogue, product types, customer and order volumes, extensions and custom code, integrations, payment setup, search, and the current address structure. We also decide here whether WooCommerce is the right fit at all.
2. Data mapping. A written map from every Magento field to its WooCommerce home: attributes, configurable products, customer groups, tax classes, order statuses. Anything with no home is flagged for a decision.
3. Test import. A full trial import into a staging site, with the real catalogue size, so timing, memory limits and data problems show up early. Then a comparison of samples and totals against the original.
4. Redirect map. Old address to new address for every indexed URL, built from a crawl and checked against search data, following Google’s site-move guidance quoted above.
5. Parallel run. The new store is complete and tested while the old one still takes orders. We test checkout, payment, emails, tax, shipping and every integration with test orders.
6. Cut-over. A planned window, a final data sync for orders and customers created since the trial import, the DNS and redirect switch, and a rollback plan agreed beforehand.
7. Monitoring. After launch we watch error logs, search crawl reports, 404s, order flow and payment success, and fix redirect gaps as they appear.

Afterwards the store needs the ordinary upkeep of any WooCommerce shop: updates on staging first, backups with a restore test, monitoring, and a review of search and speed.

When we would tell you WooCommerce is the wrong fit

We would say so, at the audit, if any of these is true:

• A very large catalogue where search, indexing and bulk updates would need engineering well beyond a standard WooCommerce build.
• Heavy B2B rules that are central to the business (negotiated price lists per customer, approval chains, credit terms) rather than a few extras.
• Many storefronts and currencies that must be run as one operation from one back office.
• Deep, real-time ERP integration where the ERP vendor already supports another platform well.

In those cases we would recommend one of three paths. First, staying on a maintained Magento or Mage-OS with a team that knows it, and putting the money into upgrades rather than a rebuild. Second, a headless engine such as Medusa or Saleor if you have, or will hire, developers to own it. Third, an enterprise platform chosen with your ERP vendor. Our WooCommerce delivery is what we can show you; for the other platforms we would help you write the requirements and judge proposals, rather than claim a delivery record we cannot point to.

Questions people ask

Is Magento Open Source getting extended support?

We cannot tell you from Adobe’s lifecycle page. It lists standard and extended support dates for Adobe Commerce releases and does not mention Magento Open Source. Check your edition with Adobe or your maintainer, in writing.

Can customers keep their passwords?

Usually not in a form the new platform can use, because passwords are stored as one-way hashes in the old platform’s format. Plan a password reset email at launch, and warn customers first.

Will a move cost us our Google rankings?

Not automatically, but a move with changed addresses is a risk. Google’s guidance is to map old URLs to new ones, use permanent server-side redirects, update internal links and sitemaps, and keep the redirects for as long as possible, generally at least a year.

Can stored cards and subscriptions move across?

Sometimes, at the payment provider level, if you stay with the same provider and it supports transferring or reusing stored payment methods. Otherwise customers re-enter their card. Ask your provider before you plan the launch.

Is Mage-OS a safe place to stay?

Mage-OS describes itself as community-owned and open source, built on Magento 2.4.9, and its repository shows regular releases. Whether it suits you depends on your extensions, your team and your risk appetite. Ask your Magento developer to test your store against it before deciding. We have read its own site and repository only, so treat this as a pointer, not an endorsement.

Can WooCommerce handle thousands of orders?

Yes with the right setup: current hosting, HPOS enabled and compatible extensions, caching, and good search. The details depend on your numbers, which is why we test a full-size trial import before we commit to a plan.

If you are weighing a move and want an honest read on whether WooCommerce is the right destination for your store, get in touch and tell us your version, catalogue size and integrations, or start a project and we will begin with the audit described above.