Adobe Commerce

What an Adobe Commerce Audit Covers and When You Need One

Rahul Aggarwal

AEM, Content & Commerce Practice · October 22, 2026

In this blog

An Adobe Commerce audit is an independent review of how your store is built, secured, hosted and run, ending in a ranked list of fixes. It checks custom code, extensions, version and patch status, performance, checkout, search engine optimization (SEO), integrations and tracking against Adobe's own guidance. Most audits take a few weeks and end with a roadmap, not just a report.

Many teams still call it a Magento audit, since Adobe Commerce is the product once sold as Magento Commerce. This guide covers what an audit checks and the tools Adobe provides. It also covers which versions are still supported, how the work runs, what you get and when to commission one. For a tour of the platform itself, see our guide to Adobe Commerce features.

What is an Adobe Commerce audit?

An Adobe Commerce audit is a structured look at the whole store, ideally by people who didn't build it. Its job is to find what's putting revenue, security or the next upgrade at risk, and to say how much effort each fix will take.

It's wider than a code review. A code review looks at one change. An audit looks at how everything fits together: the code, the hosting, the Admin settings, the extensions and the systems around the store.

Good audits mix Adobe's diagnostic tools with manual review. Tools find known patterns fast. People find what tools can't see, like a checkout step that confuses buyers or an enterprise resource planning (ERP) sync that fails quietly at night.

What does an Adobe Commerce site audit cover?

A full Adobe Commerce site audit covers eleven areas, from code quality to analytics tracking. The table shows what's checked, what auditors often find and where each area usually starts in priority. Your final ranking depends on how much revenue each finding puts at risk.

AreaWhat is checkedTypical findingsPriority
Code and customizationCustom modules, core edits, coding standardCore files changed, logic in templatesHigh
Third-party extensionsInventory, versions, vendor support, overlapAbandoned modules, two doing one jobHigh
Upgrade readiness and version supportRelease line, patch level, PHP and servicesLine past standard support, old PHPCritical
Security patching and admin accessPatches, two-factor login, Admin URL, rolesMissed patches, shared loginsCritical
Performance and cachingFull-page cache, Fastly or Varnish, slow pagesPages that skip the cacheHigh
Cloud infrastructureEnvironments, service versions, deploys, backupsStaging unlike productionMedium
Catalog and indexingIndexer modes, cron, attributes, searchUpdate on Save on a big catalogHigh
Checkout and conversionSteps, payment methods, errors, mobileUntracked payment failuresHigh
SEO and site structureCanonical tags, URL rewrites, sitemap, robots.txtDuplicate product URLs, redirect chainsMedium
Integrations (ERP, order management, payments)Connections, queues, scheduled jobs, error handlingFailures nobody is alerted toHigh
Data and analytics trackingEvents, data layer, consent, order matchRevenue that doesn't match ordersMedium

Business-to-business (B2B) stores add company accounts, quotes and requisition lists to the scope. Our guide to Adobe Commerce B2B capabilities explains how those features work.

Code, extensions and upgrade readiness

Adobe's upgrade guide is blunt here. Customizations that aren't coded to best practice lead to higher-than-expected upgrade costs. So auditors look for edits to core code, which Adobe says to avoid, and run the Magento Coding Standard through PHP_CodeSniffer.

Extensions get the same scrutiny. Adobe's security guidance says to source them from the Commerce Marketplace or your integrator, and to limit the number of extensions and vendors. It also says to make sure licences can transfer if your integrator changes. A long list of individually applied patches is a finding too, as Adobe warns it makes upgrades harder.

Security patching and admin access

Adobe lists a short set of top-priority security steps. They include two-factor authentication (2FA) for the Admin and all secure shell (SSH) connections, a non-default Admin URL, least-privilege roles and regular security scans. Auditors check each one, then look for leftovers such as exposed .git folders, database dumps and log files.

Patch level matters for compliance as well as safety. Adobe's upgrade guide ties patch level to card security rules. To stay compliant with the Payment Card Industry Data Security Standard (PCI DSS), you must be on the latest patch or security patch. Adobe also issues isolated security patch files between releases, and you can only apply them from the latest patch release for your line. The Action Logs report, which records logged Admin actions with a time, IP address and user name, shows who changed what.

Performance, caching and cloud infrastructure

Caching is usually the first performance check. Adobe strongly recommends Varnish in production, because the built-in full-page cache is much slower. On Adobe Commerce on cloud infrastructure, Fastly's Varnish-based content delivery network (CDN) and its web application firewall (WAF) come at no extra cost. Adobe says to set up Fastly on Pro Production and Staging to stay PCI compliant.

On cloud, the audit also tests Adobe's shared responsibility model against reality. Adobe secures the platform and issues core updates, but applying patches is the merchant's job. So is keeping PHP, the database, search and other services on supported versions. On-premises stores should note that Adobe lists MySQL 8.0 as past end of support since 30 April 2026, and Elasticsearch 7.17 since 15 January 2026.

Catalog, checkout, SEO, integrations and data

For catalog health, Adobe recommends setting indexers to Update on Schedule for large or busy sites. Update on Save triggers frequent reindexing, which slows the database. Scheduled indexing depends on cron, so a stalled cron job quietly leaves prices, stock and search out of date. If you use Live Search, which replaces the standard search, the audit checks its catalog sync too.

Checkout reviews walk the real purchase path on mobile and desktop, check payment errors and confirm settings such as guest checkout. Payment Services comes out of the box from 2.4.7, so auditors also check which gateway you really use. Small checkout changes can matter a lot, as our Manyavar checkout case study shows. SEO checks cover canonical tags, which Adobe recommends for both categories and products, plus URL rewrites, the sitemap and robots.txt.

Your ERP, order management and payment systems connect through Adobe Commerce's REST, GraphQL and SOAP application programming interfaces (APIs), scheduled jobs or message queues. Auditors look hard at error handling and retries. For tracking, Adobe's Data Connection extension (formerly the Experience Platform connector) sends events such as addToCart, completeCheckout and orderPlaced to Adobe Experience Platform. The audit checks that each event fires once and that revenue matches orders. Our page on Adobe Analytics with Adobe Commerce covers the setup.

Which Adobe tools help with an Adobe Commerce health check?

Adobe provides several diagnostic tools that make an Adobe Commerce health check faster. None of them is a full audit on its own, but together they handle much of the automated work.

ToolWhat it showsAvailability
Site-Wide Analysis ToolHealth score, recommendations, extensions, available patchesNot on-premises since April 2024
Security Scan ToolMalware and security risks, over 21,000 testsFree in your Commerce account
Upgrade Compatibility ToolIssues to fix before a target versionAdobe Commerce only, command line
Quality Patches ToolIndividual patches for your installed versionComposer package
Observation for Adobe CommerceLogs and New Relic data on one timelineThrough New Relic
Managed alertsCPU, memory, disk, Apdex, database and Redis alertsNew Relic alert policy

The Site-Wide Analysis Tool gives a health score, recommendations by priority, a list of third-party extensions and the patches available for your instance. Adobe retired it for on-premises customers on 23 April 2024, so on-premises audits need more manual work to gather the same data. The Security Scan Tool can run weekly, daily or on demand, and Adobe recommends weekly.

The Upgrade Compatibility Tool checks your customized instance against a target version. It lists the critical issues, errors and warnings to fix before upgrading. Observation for Adobe Commerce puts application logs and New Relic data on one timeline, which helps trace slowdowns and problem bots. Cloud projects include the New Relic application performance monitoring (APM) software and licence key.

Is your Adobe Commerce version still supported?

Check this first, because it shapes everything else in the audit. Adobe gives each release three years of standard support from general availability, and some lines then get extended support. Here's the picture from Adobe's lifecycle policy, read on 22 October 2026.

ReleaseReleasedStandard support endsExtended support ends
2.4.912 May 202631 May 2029Not yet set
2.4.88 April 202531 May 2028Not yet set
2.4.79 April 202431 May 202731 May 2028
2.4.614 March 2023Ended 11 August 202631 August 2027
2.4.59 August 2022Ended 12 August 2025Ended 11 August 2026
2.4.412 April 2022Ended 12 April 2025Ended 14 April 2026

Releases 2.4.4, 2.4.5 and 2.4.6 also get a one-time, security-only period with isolated security fixes and no quality fixes. It ends on 31 May 2027 for 2.4.4 and 2.4.5, and on 31 May 2028 for 2.4.6. Adobe tells customers to treat it as migration time.

Two more dates matter. Adobe lists PHP 8.1 as end of life on 31 December 2025 and PHP 8.2 on 31 December 2026. It flags both as a PCI compliance risk. And from 1 June 2027, Adobe says it will stop maintaining cloud environments on unsupported versions. That can include suspending traffic, which takes your storefront offline.

Upgrades move the floor as well. Adobe Commerce 2.4.9 supports PHP 8.5, allows PHP 8.4 only for upgrading and drops PHP 8.2 and 8.3. Adobe now recommends Adobe Commerce as a Cloud Service as the long-term home for cloud customers. Adobe manages its infrastructure, patching and upgrades, but it doesn't support Luma storefronts, so a Luma-based store needs a new storefront. Either route needs planning, and our Adobe Commerce migration team can help scope it.

How does an Adobe Commerce audit run?

Most audits follow five steps: scoping and access, automated checks, manual review, ranking and a readout. The timings below are indicative planning ranges, not Adobe figures.

  • Scoping and access (week 1). Agree the goals, get access to the code, Admin, environments, New Relic and analytics, and talk to the people who run the store.
  • Automated checks (weeks 1 to 2). Run the Site-Wide Analysis Tool, Security Scan Tool, Upgrade Compatibility Tool and coding standard scans. Build the extension and integration inventory.
  • Manual review (weeks 2 to 4). Sample custom code, walk the checkout, trace slow pages, read integration logs and test tracking.
  • Ranking (week 4). Score each finding by business impact and effort.
  • Readout (weeks 4 to 5). Walk your team through the findings and agree the order of work.

For a single-website store with a moderate number of extensions and integrations, 3 to 5 weeks is a sensible range. Several websites, B2B features, many integrations, load testing or slow access can push it to 6 to 8 weeks.

What do you get at the end of an audit?

You should get a ranked plan your team can act on, not a long list of worries. A good set of deliverables includes:

  • A one-page summary for leadership, with the top risks in plain language.
  • A findings register, where each item has evidence, risk, an effort class and a suggested owner.
  • A version, patch and dependency sheet with Adobe's support dates.
  • An extension inventory, marked keep, update, replace or remove.
  • An upgrade readiness view built on the Upgrade Compatibility Tool report.
  • A performance baseline for key pages, so you can measure progress.
  • A tracking gap list for analytics and Data Connection events.
  • A roadmap split into quick wins, next quarter and later.

Share security findings with a smaller group, since they describe how the store could be attacked. If you don't have the people to work through the fixes, an Adobe Commerce support team can take on the backlog.

When should you commission an Adobe Commerce audit?

Commission one when a decision or deadline is coming and you're not sure the store is ready. Common triggers include:

  • Your release line is past standard support, as 2.4.6 has been since 11 August 2026, or close to it.
  • You still run PHP 8.2, which reaches end of life on 31 December 2026.
  • You're on cloud and need a plan before Adobe's 1 June 2027 enforcement date.
  • You've inherited the store from another agency or team. Our post on what an Adobe Commerce partner owns covers the first 90 days.
  • Peak season is three to four months away, which leaves time to fix what you find.
  • You're weighing a replatform. Read Adobe Commerce vs Shopify Plus once you know the state of your store.
  • Conversion or speed has dropped and nobody can say why.

A yearly Adobe Commerce health check, plus one after each major upgrade, keeps future findings small.

What drives the cost of a Magento audit?

There's no standard price, because the work scales with your store. The main cost drivers are:

  • The number of websites, stores and store views.
  • How much custom code there is, and how many extensions.
  • The number of integrations and how they connect.
  • How deep the code review goes: a sample or a full read.
  • Whether load testing or penetration testing is in scope.
  • The deployment model, since on-premises stores no longer have the Site-Wide Analysis Tool.
  • How quickly access and documentation arrive.

Licence costs are a separate question. Our Adobe Commerce pricing guide explains what moves them.

What to do before your audit starts

You can do useful groundwork before anyone starts. Here's a short checklist:

  • Note your exact release and patch level, and check it against Adobe's released versions page.
  • Confirm your PHP, database and search versions.
  • Export a list of installed extensions with their versions.
  • List every integration, its owner and how failures get reported.
  • Set up the Security Scan Tool if it isn't running yet.
  • Write down the three business problems you most want the audit to answer.

At DWAO, an Adobe Gold Partner, you meet the named consultants who'd run your audit before you sign anything. If you'd like a scoped proposal, start with our Adobe Commerce audit service.

Frequently asked questions

How long does an Adobe Commerce audit take?

As an indicative range, most take 3 to 5 weeks.

  • A single website with moderate customization sits at the shorter end.
  • Several websites, B2B features or many integrations push it toward 6 to 8 weeks.
  • Load testing and slow access to environments add time.

Agree the scope in writing first, so the timeline means something.

What is the difference between an Adobe Commerce audit and a health check?

A health check is lighter and repeated, while an audit is deeper and less frequent.

  • A health check tracks known measures, such as patch level, scan results and page speed.
  • An audit adds manual review of code, checkout, integrations and tracking.
  • Many teams run one full audit, then yearly health checks against that baseline.
Does Adobe offer free tools for an Adobe Commerce audit?

Yes, Adobe provides several, though none is a full audit.

  • The Security Scan Tool is free in your Commerce account and runs over 21,000 tests.
  • The Upgrade Compatibility Tool flags issues before an upgrade.
  • Cloud stores also get the Site-Wide Analysis Tool and New Relic APM.

People still need to judge business impact and the order of fixes.

Is Adobe Commerce 2.4.6 still supported?

Only partly, as standard support for 2.4.6 ended on 11 August 2026.

  • Extended support, with quality and security patches, runs to 31 August 2027.
  • A security-only period follows, ending on 31 May 2028.
  • PHP 8.2, one of the two PHP versions 2.4.6 supports, reaches end of life on 31 December 2026.

Plan the upgrade or migration now, not near the deadline.

What access does an Adobe Commerce auditor need?

Mostly read access, granted before the work starts.

  • The code repository and the list of deployed versions.
  • Admin accounts with a suitable role, plus cloud project or server access.
  • New Relic, analytics and tag manager access.
  • Integration logs and a contact for each connected system.

Slow access is a common reason audits run late.

How often should you audit an Adobe Commerce store?

Do one full audit, then lighter checks on a schedule.

  • Run a full audit before a major upgrade or replatform decision, or after taking over a store.
  • Run a health check every year and after each major release.
  • Keep the Security Scan Tool running weekly in between, as Adobe recommends.

Each check compares against the last, so drift shows up early.

Talk to an Adobe expert

Tell us where you are and what you're trying to achieve. A certified consultant from DWAO will come back with a practical next step — not a sales pitch.

  • Adobe Gold Partner with certified specialists
  • Response within one business day
  • Delivery teams across five countries

We only use your details to respond to this enquiry. No spam, no resale.