Adobe Commerce Cloud licence pricing crossed $40k/year in 2026 for many mid-market merchants. Three of our clients hit that wall over the past 14 months and asked the same question: is migrating to Magento Open Source actually worth it?

We ran all three migrations. Two were worth it. One wasn't.

This is the honest version of that story — including the database schema gotchas, the B2B Suite trap, and the cost math nobody puts in marketing posts.

TL;DR

• Migration saves $100k-250k over 5 years IF you don't depend on Adobe-only features
• B2B Suite, Adobe Sensei, and staging features are the three biggest dependency traps
• The row_id vs entity_id schema difference will break custom modules that bypass Repository pattern
• Two-thirds of mid-market merchants pay for features they don't use — the other third critically depend on them
• Open Source is the same Magento 2 framework. What changes is the licensing, infrastructure, and a handful of proprietary modules.

Why this conversation is happening now

For years Adobe Commerce Cloud was the "safe" choice for mid-market merchants doing $1M-$10M GMV. You paid the license, you got hosting + auto-deploys + B2B + AI recommendations + Adobe's support, and you didn't have to think about infrastructure.

That math is shifting in 2026:

• License pricing has climbed steeply (we've seen $22k → $40k+ jumps on renewal)
• Adobe's roadmap focus has shifted toward Adobe Experience Manager integrations, not core Commerce features
• The Hyvä ecosystem has reached production maturity on Open Source
• Self-managed hosting (Hypernode, MGT, Cloudways) is now operationally as smooth as Adobe Cloud was three years ago

The merchants asking us about migration aren't doing it to save $10k. They're doing it because Adobe's value proposition no longer matches what they need.

What actually stays the same

Both platforms share the Magento 2 core. If your team works in Magento daily, this part doesn't change:

• Module structure and DI XML
• GraphQL schema and REST API
• Composer-based dependency management
• Admin layout and UI components
• Frontend stack (Luma, Hyvä, PWA Studio, custom headless — all work either way)
• bin/magento CLI commands

This is why "migration" is a misleading word. You're not moving to a different platform. You're removing the Adobe layer from the same platform.

What actually breaks — the technical reality

This is where I disagree with most write-ups on this topic. The migration is not "smooth" or "straightforward." It has specific failure modes, and pretending otherwise leads to blown timelines.

1. The row_id vs entity_id schema split

Adobe Commerce uses row_id in catalog tables (catalog_product_entity, catalog_category_entity) to support staging and preview features. Open Source uses entity_id.

If your codebase has SQL that queries these tables directly — instead of going through Magento's Repository pattern — those queries silently break:

// Will break after migration
$connection->query("SELECT * FROM catalog_product_entity WHERE row_id = $id");

// Will keep working — uses repository pattern
$product = $this->productRepository->getById($id);

Across three projects we found ~40 places where developers had bypassed Repository for "performance reasons." Each one needed identification and rewrite. Plan for a full audit, not a global find-replace.

2. The B2B Suite trap

Adobe's B2B Suite isn't just a feature — it's an architectural dependency. Company accounts, shared catalogs, quote workflows, requisition lists, and tiered pricing for company structures all live in this module.

If you use it, your options are:

• Rebuild from scratch (8-12 weeks of senior dev time)
• Replace with paid alternatives (Aitoc, Wyomind, Magexperts have partial coverage)
• Drop the functionality (sometimes acceptable, often not)

There is no migration path. The data export is partial. The schema doesn't map cleanly. We've seen this kill migration projects in week 2.

If you depend on B2B Suite, get a specific rebuild estimate BEFORE committing to migration.

3. Adobe Sensei recommendation widgets

This one's quieter and easier to miss. Sensei (Adobe's AI recommendation engine) leaves orphaned database tables and broken admin pages after migration if you don't clean them up explicitly.

Replacement options for product recommendations:

• Self-hosted ML
• Open source modules (mgt-commerce/related-products, amasty/recommendations)
• Rebuild on top of Magento's native related products engine

None are drop-in. Budget 2-4 weeks for whatever you choose.

4. Page Builder content drift

Page Builder content stored in CMS pages mostly survives migration — Open Source has Page Builder too. But Commerce-Cloud-only widgets (dynamic blocks tied to customer segments, staged content) render as empty divs.

Audit every CMS page before go-live. Replace dynamic blocks with static content or third-party segmentation modules.

5. Hosting migration is bigger than it sounds

This is the one teams underestimate most.

Adobe Cloud abstracts away Fastly, Platform.sh, cron jobs, deploy hooks, secrets management — you don't notice them because they "just work." When you move to Hypernode or similar:

• Fastly VCL → rebuild or migrate to Varnish
• .magento.app.yaml → your CI/CD pipeline
• Adobe Cloud variables → environment management (we use Vault)
• Cron jobs → manual provisioning
• Deploy hooks → custom GitHub Actions / GitLab CI

Plan ~2 weeks of DevOps work. Not optional.

The cost math — honest version

Mid-market store, $2-3M GMV, 5-year comparison.

Adobe Commerce Cloud:

Magento Open Source (post-migration):

The 5-year savings ARE real — but they're mostly real for merchants who already have an in-house Magento dev OR a long-term dev partner relationship. If you'd need to hire a partner from scratch just to run Open Source, the math gets thinner.

Where the savings genuinely show up:

• Year 6 onward (migration is amortised, licence still $0)
• When Adobe raises the licence at renewal (commonly 15-20% increases)
• When you'd otherwise need infrastructure Adobe Cloud doesn't allow (custom Redis, specific regions, headless storefronts with edge compute)

Decision framework

Migrate if you can say yes to most of these:

• Licence cost ≥ $25k/year
• You use ≤30% of Adobe-only features (no B2B Suite, light Sensei usage, no staging dependency)
• Team has senior Magento experience (or trusted partner)
• You want infrastructure flexibility Adobe doesn't allow
• You're already planning major dev work (replatform, redesign, headless)

Stay on Adobe if:

• Heavy B2B Suite usage
• Compliance requirements where Adobe SLA matters
• No DevOps capacity for self-managed infrastructure
• Licence is bundled with other Adobe products you actively use

The one migration we didn't recommend

Of the three I mentioned at the top, the one we didn't migrate was a B2B distributor with deep Sensei + B2B Suite usage. Their license was $35k/yr — meaningful money — but rebuilding their B2B functionality would have cost ~$120k, and Sensei replacement another $40k. Payback was ~7 years before infrastructure savings, and they didn't have the DevOps capacity to manage it.

Sometimes the answer is "Adobe is expensive AND it's still the right choice." That's worth saying out loud.

What I'd ask before migrating

If you're considering this:

1. List every Adobe-only feature you use. Score each one 1-5 on "how critical"
2. Get a specific rebuild cost for everything you score 4-5
3. Add to that: migration cost, 2 weeks of DevOps, 6-12 months of dev partner ramp-up
4. Compare to 5-year licence cost INCLUDING expected annual increases
5. If self-managed math wins by less than 20%, stay. The risk premium isn't worth a marginal saving.

If you've migrated recently — what was the schema or dependency gotcha you didn't see coming? I'm collecting war stories for a deeper post on the technical pitfalls specifically.

Full cost breakdown and FAQ on the canonical: https://angeo.dev/migrating-from-adobe-commerce-cloud-to-magento-open-source-is-it-worth-it/