Adobe Commerce Development That Earns Its Licence

Yes. The two editions share a core code base, so moving from the free one to the licensed one is a licence change plus configuration rather than a rebuild. Your theme, custom modules and integrations carry across, and developer skills transfer completely. What you gain is the B2B suite, the Adobe hosted services and a longer support window. What you take on is the licence fee and, on Adobe Commerce Cloud, a different deployment model your team will need to learn. The work worth doing first is confirming which paid features you will genuinely switch on, because the common regret is paying for capability nobody enabled.

Start at least three to six months before your version loses support, and longer if the store is heavily customised. That sounds generous until you count what has to happen: an assessment of what is installed, chasing extension vendors for compatible releases, the build itself, then testing and a cutover window that does not collide with your trading peak. Leaving it to the final weeks removes every option except rushing, and a rushed upgrade is how stores end up with a broken checkout in their busiest month. With 2.4.6 losing standard support on 11 August 2026, anyone still on that line should be scheduling rather than researching.

No, and this is the detail most coverage gets wrong. Adobe's extended support window applies to Adobe Commerce customers, not to the Magento Open Source code base. In practice that means Open Source 2.4.6 is a hard stop on 11 August 2026, while a licensed Adobe Commerce 2.4.6 store has until 30 August 2027. If you are on Open Source and were planning around the 2027 date, you have roughly a year less runway than you think. It is worth confirming which edition you actually hold before scheduling an upgrade.

Your store keeps working. Nothing switches off on the end of support date. What stops is security patches, and that is the real exposure. Sansec found roughly 75 percent of stores were still unpatched a week after the fix for CosmicSting, CVE-2024-34102, was released, and thousands were breached. An unsupported store also becomes a compliance problem: PCI DSS expects supported software, and insurers and enterprise customers increasingly ask. The technical risk is manageable for a short window. The compliance and liability risk usually is not.

For a live store with real customisations, plan six to fourteen weeks. The upgrade command itself takes minutes. The work is auditing every extension and customisation, replacing anything abandoned or incompatible, moving core edits into upgrade safe modules, and then regression testing checkout, payment, tax, shipping and any ERP integration. Data volume and the number of third party extensions drive the timeline more than the version gap does. If a quote promises a few days for a major line jump, it is pricing the command rather than the testing.

Possibly, and it is worth checking early because these are infrastructure changes rather than code ones. The 2.4.9 matrix drops Elasticsearch in favour of OpenSearch and replaces Redis with Valkey, so a host still provisioning the older services cannot run it as supplied. It also expects PHP 8.5, MySQL 8.4 or MariaDB 12.3. Managed Magento hosts generally handle this for you. Self managed environments, and anything defined as infrastructure as code, need the new services provisioned and tested before the upgrade rather than during it. We check your current stack against the matrix at the assessment stage so it never becomes a mid-project surprise.

The B2B suite is the clearest case: company accounts, shared catalogues, requisition lists, negotiated quotes and approval rules. Live Search and Product Recommendations are also licence only, because they are Adobe hosted services rather than code you can install. Beyond those, most of what teams assume is licence gated is not. Multi store, multi currency, custom pricing rules, advanced promotions and headless front ends all work on Magento Open Source. We audit which licence features you genuinely use before any renewal conversation, because many stores pay for capability they never switched on.

It is where Adobe active front end investment has moved, so it deserves a look, but it suits a narrower set of stores than the surrounding noise suggests. It targets content led commerce where page speed and authoring workflow matter most, and it asks your team to work differently rather than simply swapping a theme. For a typical store with an existing Luma or Hyva front end and people who maintain it, the pragmatic answer today is still Hyva. We would consider Edge Delivery seriously for a content heavy brand starting fresh, and would not recommend replatforming a working front end onto it on roadmap direction alone.

Yes, though it is a rebuild rather than an upgrade. Magento 1 reached end of life in June 2020 and shares no upgrade path with 2.x, so the catalogue, customer and order data are migrated while the theme, extensions and customisations are rebuilt on the current platform. That sounds worse than it is: it is an opportunity to drop the accumulated extensions nobody uses. We start by auditing what is actually in use versus what is merely installed, which usually shrinks the rebuild scope considerably.

Adobe prices the licence individually based on your gross merchandise value, so there is no public list price and we cannot quote it for you. What we can do is tell you honestly whether you need it. If your requirements are standard B2C retail, Magento Open Source plus good hosting usually delivers the same commercial outcome, and the licence budget is better spent on performance and merchandising. If you need the B2B suite or the Adobe hosted services, the licence is generally the cheaper route compared with rebuilding that functionality.

Yes, and roughly half our commerce work is Open Source. The same engineers work across both editions because the codebase is shared, which means moving between them does not mean changing agency. It also means we have no commercial reason to push you toward the licence. If your requirements are met by Open Source, we will say so. That has cost us work on occasion, and it has also produced longer relationships than a licence sale would have. In practice the edition is settled by a short list of features rather than a preference, and we work through that list before quoting anything.

On a schedule, not after an incident. Adobe releases security patches on a published cadence, and the window between disclosure and active exploitation has been short: CosmicSting saw widespread breaches within days. We apply patches to a staging environment first, run a regression pass across checkout and integrations, then deploy to production in a low traffic window. For stores on a support retainer this is routine maintenance. For stores that have drifted years behind, patching is usually the first phase of a larger upgrade rather than a standalone job.