Migrating from Adobe Commerce to Magento Open Source: when moving down a tier is the right call

Almost every migration article moves you up a tier. This one goes the other way. Earlier this year we moved an industrial distributor from Adobe Commerce onto Magento Open Source, kept both storefronts and a live ERP integration running through it, and removed the licence line from their budget entirely. It's the right call more often than the ecosystem admits, and it's also genuinely easy to get wrong. Here's how to decide, and what the work actually is once you have.

Why would anyone move off Adobe Commerce?

Because a licence you renew every year should buy you something you use every day, and for a surprising number of merchants it doesn't.

The Adobe Commerce licence is priced on your revenue, not on your feature usage. So a distributor doing solid volume with a catalogue that mostly needs to be accurate, a pricing model that lives in their ERP, and a checkout that mostly needs to work can end up paying enterprise money for a feature set their team never opens. Meanwhile the things they actually depend on, the ERP connector, the custom configurator, the theme, the search, are all things you built and maintain yourself. None of that is Adobe's.

That's the pattern worth checking for. When your differentiation lives in custom code and an ERP integration rather than in Commerce's native features, the licence is buying support and a feature list, and you should price both honestly.

What do you actually give up?

This is where the decision gets made, so be thorough and unsentimental. Open a spreadsheet and go feature by feature. The significant Adobe Commerce exclusives, and what happens to each:

| Adobe Commerce feature | If you use it | Replacement path |
| --- | --- | --- |
| B2B module (company accounts, shared catalogs, requisition lists, native quotes) | This is usually the dealbreaker | Extension or custom build; budget seriously |
| Customer Segments | Common | Extension, or customer groups plus rules |
| Target Rules (automated related products) | Sometimes | Extension or manual related products |
| Dynamic Blocks / banners | Rarely | CMS blocks and widgets |
| Content Staging and Preview | Sometimes loved | Extension, or a staging environment and discipline |
| Gift Cards, Store Credit, Reward Points | Rare in B2B, common in B2C | Extensions exist for all three |
| RMA | Depends on returns volume | Extension or a helpdesk process |
| Visual Merchandiser | Nice to have | Manual sorting or an extension |
| Adobe support and SLA | Depends on your team | Your agency, or in-house |

Two honest notes on that table. First, the B2B module is the one that stops most migrations, and rightly so. If your customers log in to shared catalogues with company-level accounts and requisition lists, replacing that is a project, not a line item. Price it before you commit, not after.

Second, "an extension exists" is not the same as "this is free." Every replacement is a dependency you now own, patch, and upgrade. Add them up and compare the total to the licence. Sometimes the licence wins. That's a legitimate outcome of the exercise.

The decision test

Five questions, in order. If you answer yes to the first one, stop and think hard.

1. Are you using the B2B module in anger? Company accounts, shared catalogues, requisition lists, negotiable quotes. If yes, migrating means rebuilding that.
2. Does your pricing logic live in Magento or in your ERP? If your ERP is the source of truth for customer-specific pricing and availability, Commerce's pricing features are largely decoration and you won't miss them.
3. What does your team open in the admin every week? Not what's available. What they actually use. Ask them; the answer is usually shorter than anyone expects.
4. Who fixes it when it breaks today? If the honest answer is your agency rather than Adobe support, you're already paying for the support you use.
5. What's the total cost of replacements plus the migration itself, over three years, against the licence over three years? Do the arithmetic. If it isn't clearly favourable, don't do it.

The Composer change is the easy part

Mechanically, the switch is one line:

- "magento/product-enterprise-edition": "2.4.x",
+ "magento/product-community-edition": "2.4.x",

Then you delete the Commerce modules, run setup upgrade, and discover that the interesting work is all in your database.

Commerce features leave data behind in tables whose modules no longer exist. Staging rows point at future updates that will never apply. Sales rules carry columns that only meant something to the Enterprise rule engine. Products and categories carry attributes and relationships created by modules you just removed. None of that raises an error immediately, which is exactly the problem: it raises errors later, in indexing, or in a report, or at checkout, once you've stopped associating the failure with the migration.

So the real deliverable is a set of migration scripts. Ours cleaned up products, categories and sales rules specifically, and they were written by reading the schema rather than guessing. That work is unglamorous, it's the bulk of the project, and skipping it is how a migration looks successful for three weeks.

The parts nobody warns you about

• Third-party extensions with Commerce dependencies. An extension that references an Enterprise interface or extends a Commerce class will fatal after the swap. Audit every one before you start, not after, and expect at least one vendor to have no Open Source build.
• Your own custom code, same problem. If any module you own touches a Commerce class, it needs rewriting. Grep for it early.
• Sales rule and cart price rule behaviour. Test every active promotion after the migration. This is a place where "it still saves without error" is not the same as "it still calculates the same total."
• Order history has to survive intact. Historical orders reference features that no longer exist. They still need to open in the admin without exploding, because your support team lives in there.
• Your integrations must not notice. Which brings us to the part we cared about most.

Don't let the ERP notice

For a distributor, the ERP integration is the site. Real-time price and availability per customer is not a feature, it's the reason a buyer trusts the number on the screen. Our brief was that the migration had to be invisible to it.

In practice that meant treating the connector as a first-class constraint from the start rather than something to fix afterwards: verifying it against the Open Source build before cutover, keeping its version pinned so it wasn't changing at the same time as the platform underneath it, and testing the specific paths where Commerce and Open Source can differ, quotes and price calculation especially. Change one thing at a time. When both the platform edition and the integration version move together and something breaks, you have no idea which one did it.

Does Mage-OS change the maths?

It adds a third option worth knowing about. Mage-OS is a community-run distribution of Magento Open Source, built by long-time ecosystem contributors, and it's a drop-in for the same codebase. For a merchant leaving Adobe Commerce, the decision is really two decisions: leaving the licence, and then choosing which Open Source distribution to run. You can migrate to Magento Open Source now and evaluate Mage-OS later, because that second move is a much smaller one.

What matters either way is that you keep a Composer-managed, upgradeable install. The failure mode to avoid isn't picking the wrong distribution. It's ending up on a hand-patched codebase nobody can upgrade.

When we'd tell you not to do it

If you use the B2B module properly and don't want to rebuild it. If your team genuinely uses staging, segments and target rules weekly. If the arithmetic over three years is close rather than clear. If you're mid-replatform on something else already, because two large migrations at once is one too many. And if nobody on your side owns the site day to day, because Open Source moves the maintenance burden to you and it has to land on someone.

The point of the exercise isn't to leave Adobe. It's to know what you're paying for. Plenty of merchants run the numbers and stay, and that's a good outcome too, because now it's a decision instead of a renewal.

Thinking about it?

We've done this migration on a live B2B site with an ERP integration running through it, and we've also told clients not to. If you want the arithmetic done properly for your setup, that's a conversation worth having before your next renewal rather than after it.

Our replatforming cost calculator gives you a starting range, the replatforming playbook covers the migration mechanics in more depth, and if you'd rather just ask someone, get in touch. We also do this work directly: platforms and frameworks.