Migrating away from Magento or Adobe Commerce to a custom Solidus store

What Magento is, and who outgrows it

Magento is a serious piece of ecommerce software, and I want to say that plainly before I spend the rest of this article explaining why a shop might leave it. It handles very large catalogues, complex business to business rules, several storefronts and currencies from one installation, and attribute heavy products that other platforms struggle with. If your shop genuinely needs all of that, and you have the team and the budget to run it well, Magento earns its place and you should probably stay.

The business I am writing for is the other one: the shop that pays for far more platform, and far more specialist time, than its needs justify. It is usually a mid sized retailer or trade supplier that landed on Magento years ago, often on the advice of an agency, and now finds that the licence, the hosting and the day rate of the few people who know the system add up to a bill out of all proportion to what the shop actually does. The checkout works. The catalogue works. But every change is a project, every upgrade is a project, and the person who signs the invoice has started asking what all of it is for.

This article is the honest guide to moving off Magento Open Source or Adobe Commerce onto a custom store built on Solidus, the open source ecommerce framework for Ruby on Rails. I build the new store and run the move. You own the result. I will be specific about how Magento's export and its API really work, what it hands over cleanly and what it holds onto, and where the hard parts are. For the deep detail on how each kind of data actually moves, I link out to the pieces that cover it properly rather than repeat them here. The place to start, if you have not, is the overview: what moves and what does not.

Two editions on one codebase

The first thing to be clear about is which Magento you are on, because the two editions are the same software with very different commercial terms.

Magento Open Source is free to licence. The code lives on GitHub under the Open Software License 3.0, and you can download it, run it and change it without paying Adobe anything.¹ Your costs are hosting, development and whatever extensions you buy. This is the edition many smaller shops run, sometimes without realising there is another one.

Adobe Commerce is the paid edition. It is built on the same core, and adds features aimed at larger operations: native business to business functionality, content staging, customer segmentation, dedicated support and a managed cloud option. Adobe does not publish a list price for it. The commercial licence is agreed in an ordering document with Adobe, and the GitHub licence notice is explicit that once you pay fees under such an ordering document, those commercial terms supersede the open source licence for each file.¹ In practice the fee is quoted by Adobe and scaled to the size of your business rather than set from a public price list,² which is exactly why it is so hard to compare and so easy to keep paying. For many shops the Adobe Commerce licence is the single largest reason the January numbers stop making sense.

If you are on Adobe Commerce and you cannot comfortably say what you get for the licence that you could not get from the free edition plus a developer, that gap is the thing to examine first.

What you really own, and what holds you

Here is the good news, and it is genuinely good: you own your data, on both editions. Magento stores everything in a database you control, usually MariaDB or MySQL, and gives you admin tools and a full API to get it out.³ Nobody can switch your shop off or hold your catalogue hostage. That is a real advantage over a hosted platform, and it means the move I describe below is a question of effort rather than permission.

What holds you is not the data. It is the weight of the thing around the data.

A properly run Magento 2 store is a cluster of moving parts. For the 2.4.9 line it expects PHP 8.5, a search engine such as OpenSearch 3, a database on MariaDB 12.3 or MySQL 8.4, plus a cache, a message queue and a reverse proxy in front.³ Each of those has to be installed, tuned, kept patched and upgraded, and the work is almost always done at agency rates because the pool of people who do it well is small and in demand. The platform is not expensive because Adobe is greedy. It is expensive because it is big, and big software needs big care.

The second thing that holds you is the support clock. Adobe gives each 2.4 release line three years of standard support from its release date. The 2.4.6 line left standard support on 11 August 2026, 2.4.7 leaves it on 31 May 2027, 2.4.8 on 31 May 2028, and 2.4.9, released on 12 May 2026, on 31 May 2029.⁴ That cadence means a planned upgrade project every year or two, whether or not the upgrade brings you anything you wanted. On a platform you are also paying to licence and host, the upgrade cycle is the cost that quietly recurs forever.

None of this is a trap in the dishonest sense. It is simply the running cost of a heavyweight platform, and the question is whether your shop is heavy enough to need it.

Getting your data out of Magento

Because you own the database, getting your data out is a real possibility rather than a negotiation. Magento gives you two routes, and a serious migration uses both.

The first is the admin importer and exporter, under System, then Data Transfer. The export produces comma separated files, and you choose the entity type: products, the customers main file, customer addresses, advanced pricing, stock sources and customer finances are all available as separate exports.⁵ The format is a flat comma separated file, where each row that starts with a value in the SKU column begins a new product and extra rows carry its images and options.⁶ Import accepts the same comma separated format, or a zipped version of it, with behaviours for adding, updating, replacing or deleting records.⁶ This is the tool for the bulk of the catalogue and the customer list.

The second route is the web API. Magento ships a framework that exposes REST, GraphQL and SOAP interfaces built on a create, read, update, delete and search model, so anything the admin can do to a product, a customer or an order can be driven programmatically.⁷ Authentication is by token for integrations you create in the admin, by OAuth for outside applications, or by login for an administrator or a customer.⁷ For a migration the API is how I pull the records the flat export handles awkwardly, such as orders with their full line and status history, and how I verify counts between the old shop and the new one.

Two limits are worth knowing before you plan around the API, because both are Adobe's own defaults. Input limiting, when enabled, caps a single request at 20 entities for synchronous calls and 5,000 for asynchronous ones, and caps a paged result at 300 items, though it is disabled by default and set under the Web Api Limits and GraphQL Input Limits configuration.⁸ Separately, from Adobe Commerce 2.4.7 you can switch on rate limiting for the payment information sent through REST and GraphQL to blunt carding attacks, which is also off by default and needs a Redis connection to work.⁹ For a one off migration these rarely bite, but if you are reading large volumes you page the data and you do not fight the limits.

The data model, and why mapping takes work

The reason a Magento export is more involved than it looks is the way Magento stores a product. It uses an entity attribute value model, usually shortened to EAV. Instead of one wide table with a column for every product field, Magento keeps the attributes in several tables, one group per data type, and assembles a product by joining across them. Adobe says it directly: objects that use EAV attributes typically store their values in several database tables, and the catalogue and customer modules are the main users of it.¹⁰

That design is why Magento is so flexible with custom attributes. You can add a product attribute for shape, volume, voltage or anything else, and the model absorbs it without a schema change. The price of that flexibility is that your catalogue is not a tidy spreadsheet sitting in one place. It is spread across the model, and the meaning of each attribute, which ones are global and which vary per store view, which are required, which feed configurable products, lives partly in the data and partly in the heads of whoever set it up.

For a migration this matters in one concrete way: the export gives you the values, but you still have to map them onto the new shop's model, decide which attributes survive the move and which were never used, and reconcile the ones that turn out to mean something subtly different from what their name suggests. That is not a blocker. It is honest work, usually a few days of careful reconciliation on a real catalogue, and it is the same shape of work the products and catalogue spoke walks through in detail. Set the expectation now: the data comes out, and mapping it is the part that takes the time.

The export tools and the API limits

So what actually moves cleanly, what moves with effort, and what has to be rebuilt? This is the table I wish more vendors published.

What	How it moves off Magento	How hard
Products, variants, prices, images, categories, stock	Admin export to comma separated files, mapped onto the new model	Moves with mapping work
Customers and addresses	Admin export of the customers main file and addresses	Moves cleanly
Order and purchase history	Read through the API as records, imported as read only history	Moves partially
Passwords	Hashes only, upgraded at first login, never the plain text	Special handling
Saved cards and vaulted tokens	Only between certified processors, often needs the gateway	Hardest, plan first
Subscriptions from an extension	Depends on the extension, may need its own export	Hardest, plan first
URLs and redirects	Mapped by hand from the old structure to the new	Moves with effort
Theme, extensions, custom modules	Do not move, rebuilt as application code	Rebuilt

The rows in the hardest band are the ones to raise on day one, not in the last week. I come back to each below.

The traps that are specific to Magento

Every platform has its own places where a migration gets stuck. For Magento these are mine to flag honestly.

Passwords never come across as passwords. Magento never stores a customer's password in plain text. It stores a hash, a salt and a version marker, using SHA256 or Argon2id depending on when the account was last set,¹¹ and there is no way to read the original password back, which is the whole point of hashing. Because you own the database, you can carry those hashes into the new shop and verify them once at the customer's first login, then store the password in the new shop's own format, so nobody has to reset anything and no customer ever notices. If that extra care is not worth it for your shop, a one time password reset at launch works too. The customer accounts spoke covers both paths and the service message that goes with them.

Payments and vaulted cards are the hardest single thing. A saved card belongs to the payment provider, not to Magento, so whether your customers keep their saved cards depends on your gateway and not on either shop. The best case is that your Magento store already charges through a provider you own, such as your own Stripe account, in which case the new Solidus store connects to the same account and the tokens never move at all. The worst case is a provider that will only release tokens to another holder certified to the top level of the card security standard, if it releases them at all. This is the question to settle before anything else, and the payment tokens spoke is the detail. Read the hidden dangers of switching payment gateways before you commit to a gateway change on top of a platform change.

Subscriptions live in an extension, not the core. Magento has no native recurring billing, so if your shop sells subscriptions it does so through an extension or a payment provider's own recurring feature, and the data and logic sit there. That makes active subscriptions the other hard case: an active mandate often cannot simply be exported and reinserted, and may need the extension's or the gateway's cooperation to move without interrupting a customer's billing. Flag every live subscription early, and plan the cutover around the billing dates. The subscriptions spoke is the one to read in full if this is you.

The URL structure is yours to preserve. Magento builds its own URLs, often ending in .html, with category paths and layered navigation parameters, and years of links and search rankings hang off them. Every one of those addresses has to be mapped to its new home with a permanent redirect, or the traffic that found you yesterday meets a dead page tomorrow. On the shops I build the redirects live in the application itself, in a table the shop's own staff can edit, so they survive every future deploy. The mechanics are in the products and catalogue spoke, because the redirect map and the product move are the same exercise.

The logic hides in modules. The real reason a Magento shop is hard to leave is rarely the data. It is that years of business rules, price logic, integrations with an ERP or a warehouse, and quiet customisations live inside extensions and custom modules that nobody has fully documented. None of that moves by export. It has to be understood and rebuilt as ordinary application code. That is work, but it is also the opportunity, because the rebuilt version is tested, documented and yours.

A worked example in Manchester

Let me make this concrete with an invented business, because real client stories are not mine to tell.

Pennine Tools (penninetools.example) is a Manchester supplier of trade tools and workwear, selling to both the public and to trade accounts. It turns over about four million pounds a year online, runs a catalogue of roughly twelve thousand products with heavy use of custom attributes for voltage, size and material, and has been on Adobe Commerce for six years. Its trade customers have negotiated price lists and pay on monthly invoices. The shop works. What stopped working was the arithmetic: the Adobe Commerce licence, a managed hosting bill sized for the platform, and an agency retainer for patches and the next upgrade together cost more each year than two full time staff, and the owner could not say what the licence bought that a developer could not.

When I scope a move like this, the first week is not about products. It is about the three hard rows in the table. Pennine Tools charges through its own Stripe account, so the saved cards stay where they are: the new Solidus store connects to the same account and no token moves. It has no subscriptions, which removes the other hard case entirely. Its passwords are Argon2id hashes in a database the owner controls, so they carry across and upgrade at first login, and no customer is forced to reset. Those answers, settled in week one, are what make the rest of the project calm.

The catalogue is the real labour. The EAV export comes out as comma separated files, and the mapping work is deciding which of the many custom attributes are still used, collapsing years of near duplicates, and reconciling the trade price lists onto the new model. The order history comes through the API as read only records so customer service and customers can still look up the past, while refunds and returns on genuinely old orders stay with the old system for a short handover window. The twelve thousand old URLs become a redirect map that someone from Pennine Tools checks, because only they know which category pages still earn their traffic. On the far side, the trade price lists and the monthly invoicing that were an extension on Magento become ordinary tested features of the Rails application, and the yearly licence and forced upgrade disappear from the budget for good.

The move is not free and it is not instant. But a year on, Pennine Tools pays for hosting and a developer who knows its code, and nothing else, and it owns the shop outright.

The honest move onto Solidus

The shape of a Magento move is the same every time, and the order matters.

I start with the three questions that can sink a project: where do the saved cards and tokens live and will they move, are there active subscriptions and what do they depend on, and who on your side owns the data and can answer what an attribute means. Settle those first, because they are expensive to discover late. Then the catalogue and customers come across through the admin export and the API, mapped onto the Solidus model with the reconciliation the EAV structure demands. Order history follows as read only records. The URL map is built and checked by someone who knows the shop. The storefront, the checkout and every integration that lived in a module are rebuilt as tested Rails code. Old and new run in parallel for a few weeks with the catalogue frozen, the final import is rehearsed until it is boring, and cutover happens on a quiet weekday morning with the old shop kept untouched for thirty days as the fallback.

The result is a right sized shop. Where Magento gave you an enterprise platform and charged you to licence, host and upgrade it, Solidus gives you a Rails application with no licence fee, no forced upgrade cadence imposed by a vendor, and a hosting bill that fits one shop rather than a platform built for thousands. The customisation that was an extension and a quote becomes application code you own. For the full money comparison over five years, including the Adobe Commerce licence you cannot easily price, read the five year total cost of ownership, and for where the platforms sit against each other, the platform comparison.

It is also worth knowing, if you want to stay in the Magento world a while longer, that you have options short of a full move. The Hyvä frontend, which many agencies use to replace Magento's slow default theme, became free and open source in November 2025,¹² and a non profit association runs a community distribution of Magento Open Source, founded out of concern for the open source edition's future.¹³ Neither changes the licence or upgrade economics of Adobe Commerce, but both are honest ways to lighten the load if a move is not right yet.

When you should stay where you are

I would rather lose the work than move a shop that should stay, so here is when to stay on Magento.

Stay if you genuinely use what Magento is for: a very large catalogue, deep business to business rules, multiple stores and currencies that the platform handles natively, and a team or agency you trust to run it. Stay if you are on the free Open Source edition, your hosting is under control, and the bill is not actually hurting. Stay if the only complaint is the Adobe Commerce licence and the honest fix is to drop to Open Source with a developer rather than to leave Magento altogether. And never start a migration in the months before your peak trading season, or without a named person on your side who understands the data.

The shop that should move is the one paying enterprise prices for a shop that is not enterprise sized, where the licence, the hosting and the scarce specialists cost more than the business the platform supports. If that is you, the money usually says move, and the total cost of ownership article will show you by how much.

What this means for you

Leaving Magento is not an escape from a platform that trapped you. You own your data on both editions, and the door is open. It is a decision to stop paying for an enterprise platform you have outgrown, or never grew into, and to run a shop that fits. The data comes out through the admin export and the API. The catalogue takes real mapping work because of the EAV model. The passwords, the saved cards and any subscriptions are the hard parts, and they get settled first. Everything else is a well understood project with a clear order.

If you own what Magento gives you and use it, keep it. If you are paying for far more platform than you need, and your own data belongs to you anyway, a custom Solidus store is usually the right size. Who holds the keys to that data in the first place is worth being clear about on any platform, which is the subject of who actually owns your business data.

If you want a straight answer on your own numbers, bring them to a free workshop and the first two weeks of work are on me. I will put your licence, hosting and agency figures against a Solidus build, flag the payment and subscription questions before anything else, and tell you honestly whether moving pays off for you. Sometimes it does not, and I will say so.

Footnotes

1. Magento Open Source, magento2 repository and licence notice (Open Software License 3.0, with commercial terms under an Adobe ordering document superseding the OSL for each file), GitHub, accessed 14 November 2026, https://github.com/magento/magento2 ↩ ↩²

2. Adobe, Adobe Commerce pricing (pricing provided by Adobe rather than a published list price), accessed 14 November 2026, https://business.adobe.com/products/magento/pricing.html ↩

3. Adobe Experience League, Adobe Commerce and Magento Open Source system requirements (editions, PHP 8.5, OpenSearch 3, MariaDB 12.3 or MySQL 8.4 for 2.4.9), accessed 14 November 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements ↩ ↩²

4. Adobe Experience League, Adobe Commerce lifecycle policy (three year standard support window, with 2.4.6 to 2.4.9 release and support dates), accessed 14 November 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy ↩

5. Adobe Experience League, Export data (System, Data Transfer, Export, with entity types and CSV output), accessed 14 November 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-export ↩

6. Adobe Experience League, CSV data files (comma separated value format, one row per SKU, import accepts CSV or ZIP), accessed 14 November 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-csv ↩ ↩²

7. Adobe Developer, Commerce web APIs, getting started (GraphQL, REST and SOAP on a CRUD and search model, with token, OAuth and login authentication), accessed 14 November 2026, https://developer.adobe.com/commerce/webapi/get-started/ ↩ ↩²

8. Adobe Developer, API security and input limiting (default maximum 20 entities for synchronous and 5,000 for asynchronous requests, 300 item page size, disabled by default), accessed 14 November 2026, https://developer.adobe.com/commerce/webapi/get-started/api-security ↩

9. Adobe Developer, Rate limiting (payment information rate limiting via REST and GraphQL from Adobe Commerce 2.4.7, disabled by default, requires Redis), accessed 14 November 2026, https://developer.adobe.com/commerce/webapi/get-started/rate-limiting ↩

10. Adobe Developer, EAV and extension attributes (objects using EAV attributes store values in several database tables, and the catalogue and customer modules are the main users), accessed 14 November 2026, https://developer.adobe.com/commerce/php/development/components/attributes ↩

11. Magento Open Source, Encryptor.php (password hash versions SHA256 and Argon2id, stored as hash, salt and version, never plain text), GitHub, accessed 14 November 2026, https://github.com/magento/magento2/blob/2.4-develop/lib/internal/Magento/Framework/Encryption/Encryptor.php ↩

12. Hyvä Themes, Hyvä Theme is now open source and free, 6 November 2025, https://hyva.io/blog/news/hyva-is-free-open-source.html ↩

13. Mage-OS Association, About Mage-OS (community distribution of Magento Open Source, non profit association founded out of concern for the open source edition), accessed 14 November 2026, https://mage-os.org/about/ ↩