Custom modules, integrations and upgrades
Custom modules for on-premises and Cloud stores, App Builder extensions for Adobe Commerce as a Cloud Service, and the version upgrades that keep either supported. Formerly Magento, and many of the same rules still apply.
Customization now works differently depending on how you are hosted, and a proposal that ignores this is not worth reading.
Customization runs in-process, as PHP modules inside the application. Plugins, observers and service contracts all apply, and you keep responsibility for versions and patching.
Adobe manages infrastructure, patching and upgrades, and PHP customization no longer runs inside the Commerce container. Custom logic moves out of process, to App Builder actions triggered by webhooks or I/O Events.
We use the lightest mechanism that does the job, because every heavy customization is something you pay for again at the next upgrade.
Interceptors that change how a public method behaves without editing the original class. This is the usual way to adjust the input or output of a core function.
Listeners that run your code when an event fires, such as sending an order to another system. Adobe's guidelines say an observer must not change the values passed to it, so that work belongs in a plugin.
Business logic goes on the service contract layer, where your storefront, admin and integrations all reach it through the same interface.
Adobe asks for GraphQL customization to sit in its own module, MyModuleGraphQl alongside MyModule, with resolvers for new queries and plugins on existing ones.
Out-of-process apps connected by webhooks when the store has to wait for an answer, and by I/O Events when it does not. This is the route on the Cloud Service.
Syncing orders, stock and customers with the systems you already run, with retries and a clear record of what failed.
Adobe supports only the listed combinations of PHP, database and search, so a version upgrade usually means a server change as well.
| Version | PHP | Standard support | Note |
|---|---|---|---|
| 2.4.9 | 8.5 | May 31, 2029 | Current release, available since May 12, 2026 |
| 2.4.8 | 8.4, 8.3 | May 31, 2028 | Supported |
| 2.4.7 | 8.3, 8.2 | May 31, 2027 | Extended support to May 31, 2028 |
| 2.4.6 | Check against Adobe's matrix | Ended August 11, 2026 | Extended support to August 31, 2027 |
From Adobe's lifecycle policy and system requirements, October 2026. PHP versions are for the latest patch of each release, and may change with later patches.
We do not publish prices for this platform. The assessment is how you get a real number, and it tells you what your existing customization will cost to carry forward.
We review your version, hosting, installed extensions and custom code, and read the core overrides that make upgrades hard. A list of what you want changed helps us here.
You get the module list with the approach for each one, what can be configured rather than built, and a price for the agreed scope.
Each piece of work is a separate Composer-installable module or App Builder action, tested on staging with a sanitised copy of your catalogue, and shown in demos, weekly on most projects.
Deployment follows a written plan with a rollback, outside your busy periods. You get documentation for every module, so your own team or another supplier can take it on.
Neither of these is an Adobe Commerce build. One shows a high-volume store kept in sync with Microsoft Dynamics over three years, and the other shows payments, ledgers and accounting sync where the numbers have to reconcile.
Three years keeping a high-volume Belgian WooCommerce store up, fast and in sync with Microsoft Dynamics: PHP 7.4 to current, two-hourly backups to S3-compatible storage, monitoring, and every change request handled.
UK telecom billing and revenue-assurance platform for resellers and MSPs: CDR rating, locked bill runs, Stripe card and Direct Debit collection, full receivables and ledger, Xero/QuickBooks/Sage sync, supplier-invoice reconciliation. Laravel + Next.js, two and a half years and ongoing.
On price, hosting model and support dates.
We quote after an assessment, because the same request can be a small plugin on one store and a long job on another, depending on what is already customised. We do not publish price bands. If you want a developer working with your team, rates start from $20/h, invoiced in USD, GBP, EUR or INR.
Yes, with a different method. Adobe's comparison lists the Cloud Service as out-of-process only, so we build with App Builder, webhooks, events and APIs instead of in-process PHP modules. Existing PHP modules have to be redesigned rather than copied across.
Adobe's policy gives each release three years of standard support. Today, 2.4.9 runs to May 31, 2029 and 2.4.8 to May 31, 2028. The right target also depends on PHP: 2.4.9 lists PHP 8.5, while 2.4.8 lists 8.4 and 8.3.
You stop receiving quality and security patches once support ends. On Commerce on Cloud, Adobe says it will stop maintaining environments on unsupported versions, from June 1, 2027 for 2.4.4 and 2.4.5 and from June 1, 2028 for 2.4.6 and 2.4.7. It may suspend traffic to them, which would take the storefront offline.
Yes. We start by reading the custom modules and the third-party extensions, and we tell you which will be expensive to carry forward. You get those findings whether or not you continue with us.
Not a published one. Most of our work is delivered under NDA, so many projects cannot be named. The work on this page is the closest we can show: a high-volume store kept in sync with an ERP, and a payments and ledger system.
Send your Adobe Commerce version, hosting type and the change you have in mind. We will come back with what an assessment would cover.
We reply within one business day (IST). We are an engineering team in India with 3–5 hours of overlap with the UK and Europe; US calls by appointment.