Magento Technical Audit: 5 Priority Risks in Adobe Commerce Builds

The stores that break under pressure are rarely the ones that had an obvious problem. They are the ones where a series of individually tolerable decisions — an extension added under deadline, an indexer left misconfigured, an ERP integration that worked well enough at low volume — compounded over time until a release or a traffic spike exposed them all at once.

A Magento technical audit is not a search for failures. It is a structured review of where risk is accumulating, so the business can decide what to address and in what order before that decision is made under pressure. This guide covers the five risk categories that consistently appear in Adobe Commerce builds that have been running in production for more than 12–18 months — what each one looks like, why it matters commercially, and how to assess it.

---

Before You Start: What a Useful Audit Actually Produces

A useful audit produces a prioritised risk register with commercial context — not a list of code style observations or a report that catalogues every deviation from Magento best practice without distinguishing between what matters and what does not.

The questions the audit should answer:

• Which risks are creating revenue exposure right now?
• Which risks will block the next release or the next integration?
• Which risks are accumulating quietly and will become significant at scale?

The output should be actionable by the people who make investment decisions, not just the engineers who carry them out.

---

Risk 1: Extension layer conflicts and class rewrites

What it is

Magento’s extension architecture allows third-party modules to modify core behaviour through class preferences, plugins, and observers. When multiple extensions modify the same class — or when an extension modifies a class that a later Magento upgrade has changed — the result is behaviour that is unpredictable, difficult to test, and often only visible in production.

The failure mode is rarely a hard error. It is more commonly a checkout that silently skips a step under specific conditions, a tax calculation that produces the wrong result for a particular customer group, or a product import that works for 98% of SKUs and fails for 2% in ways that are difficult to reproduce.

What to audit

Pull the list of installed extensions and their declared dependencies. For each extension that uses class preferences (full rewrites rather than plugins), identify what it rewrites and whether any other extension rewrites the same class. In a production codebase with 20+ extensions, conflicts here are common.

Check composer.json and composer.lock against the installed Magento version. Extensions pinned to older version constraints that have been force-installed — bypassing dependency resolution — are a reliable indicator of unresolved conflicts that someone worked around rather than fixed.

Review the system.log and exception.log for the last 30 days. Recurring plugin intercept errors, observer dispatch failures, or undefined method calls that appear consistently for a specific module combination indicate active conflicts that are suppressed rather than resolved.

Why it matters commercially

Extension conflicts degrade over time. A conflict that produces intermittent checkout failures at 1% of sessions during normal traffic becomes visible at 5% of sessions under peak load. The commercial cost — abandoned checkouts, failed orders, customer service volume — scales with your traffic, not with the severity of the underlying code issue.

---

Risk 2: Database health and index state

What it is

Magento’s database accumulates degradation from several sources: orphaned data from uninstalled extensions that did not clean up their tables and observers, EAV attribute proliferation across product catalogues that have been managed without governance, and indexer state that is invalid or stuck without anyone having noticed.

A slow checkout on an otherwise well-configured store is frequently a database problem — specifically, observers still firing for modules that were uninstalled months ago, or flat catalogue tables that are out of sync with the EAV layer they are supposed to mirror.

What to audit

Check the current state of all indexers via bin/magento indexer:status. Any indexer showing as invalid or working without a currently running reindex job is a problem. Indexers that are permanently stuck — cycling from working back to invalid without completing — indicate a background process failure that is usually caused by a cron job that is not running correctly, a table lock from a conflicting process, or a memory limit being hit silently.

Review core_config_data for configuration entries belonging to modules that are no longer in app/code or vendor. These orphaned entries trigger observer lookups on every page load for event handlers that no longer exist. The overhead per request is small; across your total daily request volume it is not.

Check the size and row count of catalog_product_index_eav and the flat catalogue tables if flat catalogue is enabled. EAV tables that have grown to tens of millions of rows without a corresponding catalogue size are accumulating historical index data that should have been cleaned up.

Run SHOW PROCESSLIST during a peak traffic window. Queries that are consistently appearing in a Waiting for table metadata lock or Waiting for table level lock state indicate that your indexer processes and your web processes are competing for the same table locks — a configuration problem that produces the kind of intermittent slowness that is difficult to reproduce in staging.

Why it matters commercially

Database problems have non-linear effects. A query that takes 200ms under normal conditions takes 4 seconds under load because the table lock queue has backed up. A slow checkout at peak traffic is not a database problem at 1x load — it is a database problem at 3x load that was invisible until your busiest trading period.

---

Risk 3: Frontend performance and Core Web Vitals

What it is

Google’s Core Web Vitals — specifically Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) — are both a ranking signal and a direct indicator of checkout conversion rate. Stores running on Luma-based themes with accumulated JavaScript from extensions are consistently at a structural disadvantage on all three metrics, and the gap compounds as more extensions are added.

The specific problem with Luma in 2026 is not that it is badly built — it is that it was built for a browser and network environment that no longer represents the majority of your traffic. Mobile users on mid-range devices, which is where most UK ecommerce traffic now comes from, are parsing and executing a JavaScript bundle that Luma was never designed to serve at that scale.

What to audit

Run your key customer journeys — homepage, category page, product page, checkout initiation — through Google PageSpeed Insights and Chrome’s DevTools Performance panel on a throttled mobile profile (Moto G Power equivalent, Fast 3G). The numbers from your office on a wired connection are not relevant. The numbers from a mid-range mobile on a 4G connection are.

For LCP: identify what the LCP element is on each page. On most Luma-based stores it is either a hero image that is not preloaded or a above-the-fold element that is blocked by render-blocking scripts. Both are fixable without a theme change; neither is fixed without specific work targeted at that element.

For JavaScript payload: use the Coverage tab in Chrome DevTools to measure what percentage of the loaded JavaScript is actually executed on a given page. On a typical Luma installation with 10–15 extensions contributing frontend assets, unused JavaScript above 60–70% of total payload is common. This is JavaScript being parsed and compiled on the user’s device for no benefit.

For INP: test interactive elements on mobile — add to cart, quantity selectors, accordion components. INP failures are usually caused by long tasks in the JavaScript main thread, often from analytics and tracking scripts that are not deferred correctly, or from event listeners added by extensions that fire synchronously on every interaction.

Why it matters commercially

PageSpeed Insights scores are not an abstract metric. For every 100ms improvement in LCP on mobile, conversion rate improvements of 1–3% are consistently observed across large ecommerce datasets. On a store doing £2m annually, that range represents £20,000–£60,000 in recoverable revenue that is currently being lost to load time. The calculation is specific to your traffic, device split, and baseline conversion rate — but the direction is consistent.

---

Risk 4: Integration reliability and queue health

What it is

Magento integrations — ERP sync, marketplace order routing, WMS feeds, third-party PIM connectors — almost always use one of two mechanisms: cron-based batch processes that run on a schedule, or Magento’s message queue system (RabbitMQ or the database queue fallback). Both can fail silently, and both produce the same symptom: data that looks correct in Magento but is out of sync with the connected system.

The failure mode that causes the most operational damage is not the hard failure — an exception that throws and logs. It is the soft failure: a cron job that completes without error but processes fewer records than expected because a memory limit was hit partway through, or a message queue consumer that stops processing because its process was killed and not restarted.

What to audit

Check your cron schedule configuration via bin/magento cron:status and review the cron_schedule table for jobs that are consistently showing as missed rather than success. A missed cron job is one that was scheduled but did not start — usually because the previous run had not completed when the next execution window opened. This indicates a job that is taking longer to run than its schedule interval allows, which is a scalability problem that worsens as your catalogue or order volume grows.

For message queue consumers: if you are using RabbitMQ, check the management UI for queue depth and consumer count. A queue with growing depth and a fixed consumer count means messages are arriving faster than they are being processed — your integration is falling behind under load. If you are using the database queue fallback rather than RabbitMQ, check queue_message and queue_message_status for backlogs.

Review your integration logs — specifically M2E Pro logs if you are running marketplace operations, and your ERP connector logs — for error rates and the specific errors occurring. A 2% error rate on order sync that is never alerted on and never resolved accumulates into a meaningful order count over a month of trading.

Check whether your integration cron jobs have overlapping execution windows. Two jobs that both read and write to the cataloginventory_stock_item table on overlapping schedules will intermittently deadlock — producing errors that appear random but are structurally consistent.

Why it matters commercially

Integration failures at low rates are invisible until they are not. A 1% order sync failure rate at 100 orders per day is one missed order. At 1,000 orders per day it is ten. The operational cost — customer service, manual recovery, potential refunds — scales with your growth, not with the severity of the underlying technical problem.

---

Risk 5: Caching layer effectiveness

What it is

Magento has two primary caching layers: the full-page cache (FPC), typically served by Varnish in production, and the application cache (block caching, config, layout), typically backed by Redis. Both can be configured and running while simultaneously not providing the performance benefit they are supposed to provide.

Varnish can be installed and routing traffic but achieving a hit rate of 30% on what should be a cacheable page — because cache invalidation is firing too broadly, because logged-in users are bypassing the cache on pages that should have a logged-out cached version, or because ESI (Edge Side Includes) is not configured for the dynamic blocks that are correctly excluded from full-page caching.

Redis can be configured as the cache backend but operating without LRU eviction policy configuration, causing it to fill up and start rejecting writes — which Magento handles by falling back to uncached responses silently.

What to audit

For Varnish: check the hit rate using varnishstat on your server. A healthy Varnish deployment on a typical ecommerce store should achieve a hit rate above 85% for anonymous traffic. Below 70% means something is preventing effective caching — either the TTL is set too low, cache invalidation is too aggressive, or a cookie is being set that causes Varnish to treat cacheable pages as uncacheable.

Check your Varnish VCL for the PHPSESSID cookie handling. A common misconfiguration is Varnish passing requests to the origin when a session cookie is present, even for fully cacheable pages. If your analytics or tracking setup is setting a cookie before the cache check, every page request from a new visitor goes to the origin.

For Redis: check memory usage and the eviction policy via redis-cli INFO memory. If maxmemory-policy is set to noeviction, Redis will start returning errors when it fills up — and Magento’s Redis adapter will fall back to uncached responses without logging a visible error. The policy should be allkeys-lru or volatile-lru depending on your configuration.

Check whether Redis is being used for both session storage and block caching, and whether those two uses are separated into different Redis instances or databases. Mixing session data and cache data in a single Redis instance means a cache flush — which you will run routinely for deployments — also destroys all active user sessions. On a store with active logged-in users, this is a significant disruption.

Why it matters commercially

Caching failures are capacity problems. A store that should handle 500 concurrent users with Varnish serving 85% of requests from cache requires roughly 6x the application server capacity to handle the same load without effective caching. The cost of that capacity, and the degraded response times when that capacity is saturated, are directly attributable to the caching misconfiguration.

---

Prioritising what you find

Not every audit finding requires immediate action. The prioritisation framework that produces useful decisions is based on two axes: likelihood of producing a customer-visible failure within the next 90 days, and estimated commercial impact if it does.

Anything in the immediate category should be addressed before any new development work begins. Deploying new features on top of an active queue failure or a stuck indexer creates compounding risk — the new work makes the underlying problem harder to diagnose and the blast radius of a failure larger.

---

What happens after an audit

The audit is a diagnostic, not a delivery. The value is in what the business decides to do with the findings and in what order.

For stores where the primary concern is stability and release confidence, the typical sequence is: resolve immediate-priority findings, then address high-priority risks on a structured roadmap before starting new feature development. Attempting to build on an unstable foundation consistently produces the same outcome — the features ship late, the bugs that surface in production are difficult to attribute to the new work versus the existing risk, and the release confidence does not improve.

For stores where performance is the primary commercial concern, the LCP and Core Web Vitals findings usually have the clearest revenue case and the most direct path to measurable improvement.

For stores planning an ERP integration or marketplace expansion, the integration reliability and queue health findings are the ones that will determine whether the new integration runs cleanly or inherits the instability of the existing setup.

---

If you are working through this audit internally and want a second opinion on the findings, or if you need senior engineering capacity to act on what the audit identifies, the Magento technical assessment is a 30-minute call with a senior engineer — specific to your stack, no sales handoff. For structured delivery against audit findings, see Magento project rescue and ongoing support retainers. For performance work specifically, see Hyvä and performance optimisation.