2.4.6 left regular support on 11 August 2026, and Adobe's lifecycle page offers extended support to 31 August 2027 to Adobe Commerce customers, so for a merchant on Magento Open Source the license question and the version question land in the same quarter. Moving from Open Source to Adobe Commerce has no Data Migration Tool step, no URL map, and no redirect plan, because the database stays where it is. What changes is the Composer metapackage: magento/product-community-edition becomes magento/product-enterprise-edition, and one run of setup:upgrade installs Magento_Staging, Magento_CustomerSegment, Magento_TargetRule, Magento_GiftCard, Magento_Rma, and Magento_Logging against live catalog tables. The risk sits in three places: the schema rewrite Content Staging performs, the paid extensions that now collide with native modules, and the two SaaS services, Live Search and Product Recommendations, which need keys and a data collection period before they show anything useful.
What decides this migration
| What to check | Evidence to ask for | Why it decides the move |
|---|---|---|
| Composer entitlement | A dry Composer run on a clone with the version pinned and every third-party plugin resolving | Adobe Commerce is pulled from repo.magento.com under keys tied to an entitlement; Open Source keys will not resolve the package |
| Content Staging schema rewrite | A timed setup:upgrade against a restored production dump, with SKU count and elapsed minutes recorded | Magento_Staging converts catalog entity tables to row-versioned form; on a large catalog it is the longest step of the cutover |
| Extension overlap | A module-by-module list marking retire, keep, or rewrite, with the named preference and plugin conflicts | Gift card, RMA, reward, segment, and staging extensions bought under Open Source now collide with native modules on quote and order |
| B2B module scope | Price and permission index run times measured after Shared Catalog is enabled on the real catalog | B2B installs as the separate package magento/extension-b2b, and Shared Catalog changes how those indexes are built |
| Live Search and Product Recommendations | Feed sync status per store view, and a date when recommendation units will have data behind them | Both run as SaaS services through Commerce Services Connector keys; units stay empty until behavioral data exists |
| Version landing point | A written target 2.4.x release with its support end date attached | 2.4.7 regular support ends 31 May 2027 and 2.4.9 runs to 31 May 2029; the license change is the cheapest moment to move version too |
| Cutover and rollback | The database snapshot point, the composer.lock to revert to, and who is staffed | Scheduled updates apply through cron, so a stalled cron group means a campaign date passes with nothing changing |
Which agencies fit this migration
- scandiweb, first, for B2B and multi-market feature-tier moves. Its Macron case reports an Adobe Commerce B2B build with Pimcore PIM and SAP ERP, order creation time cut by 40%, and conversion from direct traffic up 132.5%. scandiweb publishes this site
- Wagento, when the ERP holds price and stock. Its stated principle, "Your ERP is the source of truth", is the question Shared Catalog forces: whether company pricing is authored in Adobe Commerce or pushed from the ERP
- ParadoxLabs, for checkout and payment risk under the new module set. It publishes its own Authorize.net CIM, CyberSource, and Stripe modules, and plugin ordering around quote and order is where stored-card flows break first. Its site also names the reverse move, Adobe Commerce to Mage-OS
- PushON, for the maintenance window and the weeks after. The Content Staging schema step runs inside a window that needs staffing and a rollback point, and PushON publishes a five-stage migration and a support reporting cadence
- magic42, for a merchant still testing whether the license is worth buying. Its site publishes Adobe Commerce and Shopify Plus work side by side and names Packt Publishing for an Adobe Commerce Cloud platform migration
- MageComp, for auditing which paid extensions the license makes redundant. A team maintaining 200+ extensions of its own, as MageComp states, can read a composer.json and say which gift card, RMA, or staging modules Adobe Commerce now replaces
- Customer Paradigm, for a free code audit of which Commerce features a store uses before the edition is fixed. The August edition placed it on a downgrade sentence its Magento page no longer carries
What changes when the metapackage flips
- Entitlement first. The license has to be active before any Composer command runs, because Open Source keys will not resolve magento/product-enterprise-edition
- Pin the version, then change the edition. Swapping editions at the same 2.4.x version isolates the variable; a failed setup:upgrade that combined both gives no clean answer about which change caused it
- Time the schema step on real data. Magento_Staging adds created_in and updated_in to catalog entity tables and writes to staging_update and the sequence tables. Derive the maintenance window from a timed run against a restored production dump, never from catalog size
- Triage extensions before, not after. Breakages surface as di.xml preference collisions and plugin ordering on Magento\Quote\Model\Quote and Magento\Sales\Model\Order, and as modules that read catalog rows without VersionManager and serve a future or expired row version
- Install B2B separately. Once Company and Shared Catalog are on, each shared catalog carries its own customer group and catalog_product_price grows with product count multiplied by group count. Measure the price and permission index run times before promising anything
- Wire the services early. Run the product feed resync and confirm counts per store view before Live Search is switched on, and deploy the Storefront Events SDK weeks before recommendation units go on product pages
- Prove scheduled updates fire. Preview URLs are signed per update and must reach origin; a CDN rule that strips the preview parameter shows the live page and hides the defect until the update publishes
Questions
Is moving from Magento Open Source to Adobe Commerce a full rebuild?
No. The database, theme, and custom code stay in place. The metapackage changes and setup:upgrade installs the Commerce modules. The real work is extension conflict triage and the Content Staging schema step, not data migration.
Does the B2B module come included with Adobe Commerce?
It ships as a separate Composer package, magento/extension-b2b, installed after the Commerce metapackage. Company accounts, shared catalogs, requisition lists, and negotiable quotes are then enabled per website, and the B2B and ERP guide covers what Shared Catalog does to the price index.
Can a merchant move from Adobe Commerce back to Magento Open Source?
It is a real path but a lossy one. Content Staging, customer segments, gift cards, RMA, B2B, and admin action logging have no Open Source equivalent, and staged content plus versioned catalog rows must be flattened before the metapackage swaps back. ParadoxLabs names Adobe Commerce to Mage-OS moves on its site; no agency here publishes a downgrade case with a number.