In this blog
- What is an Adobe Commerce audit?
- What does an Adobe Commerce site audit cover?
- Which Adobe tools help with an Adobe Commerce health check?
- Is your Adobe Commerce version still supported?
- How does an Adobe Commerce audit run?
- What do you get at the end of an audit?
- When should you commission an Adobe Commerce audit?
- What drives the cost of a Magento audit?
- What to do before your audit starts
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.
| Area | What is checked | Typical findings | Priority |
|---|---|---|---|
| Code and customization | Custom modules, core edits, coding standard | Core files changed, logic in templates | High |
| Third-party extensions | Inventory, versions, vendor support, overlap | Abandoned modules, two doing one job | High |
| Upgrade readiness and version support | Release line, patch level, PHP and services | Line past standard support, old PHP | Critical |
| Security patching and admin access | Patches, two-factor login, Admin URL, roles | Missed patches, shared logins | Critical |
| Performance and caching | Full-page cache, Fastly or Varnish, slow pages | Pages that skip the cache | High |
| Cloud infrastructure | Environments, service versions, deploys, backups | Staging unlike production | Medium |
| Catalog and indexing | Indexer modes, cron, attributes, search | Update on Save on a big catalog | High |
| Checkout and conversion | Steps, payment methods, errors, mobile | Untracked payment failures | High |
| SEO and site structure | Canonical tags, URL rewrites, sitemap, robots.txt | Duplicate product URLs, redirect chains | Medium |
| Integrations (ERP, order management, payments) | Connections, queues, scheduled jobs, error handling | Failures nobody is alerted to | High |
| Data and analytics tracking | Events, data layer, consent, order match | Revenue that doesn't match orders | Medium |
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.
| Tool | What it shows | Availability |
|---|---|---|
| Site-Wide Analysis Tool | Health score, recommendations, extensions, available patches | Not on-premises since April 2024 |
| Security Scan Tool | Malware and security risks, over 21,000 tests | Free in your Commerce account |
| Upgrade Compatibility Tool | Issues to fix before a target version | Adobe Commerce only, command line |
| Quality Patches Tool | Individual patches for your installed version | Composer package |
| Observation for Adobe Commerce | Logs and New Relic data on one timeline | Through New Relic |
| Managed alerts | CPU, memory, disk, Apdex, database and Redis alerts | New 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.
| Release | Released | Standard support ends | Extended support ends |
|---|---|---|---|
| 2.4.9 | 12 May 2026 | 31 May 2029 | Not yet set |
| 2.4.8 | 8 April 2025 | 31 May 2028 | Not yet set |
| 2.4.7 | 9 April 2024 | 31 May 2027 | 31 May 2028 |
| 2.4.6 | 14 March 2023 | Ended 11 August 2026 | 31 August 2027 |
| 2.4.5 | 9 August 2022 | Ended 12 August 2025 | Ended 11 August 2026 |
| 2.4.4 | 12 April 2022 | Ended 12 April 2025 | Ended 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.