Magento Technical Audit Checklist: 47 Checks Before Any Replatform or Major Upgrade Decision

A Magento technical audit inventories code health, extensions, security posture, performance, and the integration layer so you can decide with evidence whether to upgrade in place or replatform. Run all 47 checks below before you commit budget. The findings, not a gut feel, should drive the decision.

Most audit content you will find online stops at five vague categories: speed, security, SEO, UX, and code quality. That is enough to sell an audit, not enough to run one. This checklist is the version we use on real mid-market Magento and Adobe Commerce stores before a major upgrade or a platform move. Every section opens with a short answer you can act on, then lists the specific checks. At the end you get a decision framework that turns the findings into a stay-or-move recommendation.

If you want context on how we work as a hands-on Magento partner rather than a report vendor, see About Bemeir. This checklist reflects how our team actually opens up a codebase.

Why a structured audit beats a general health check

A recurring health check tells you whether the store is currently healthy. A pre-decision technical audit answers a harder question: what will it cost, and how risky is it, to take this codebase where you want it to go next. The two overlap, but the audit has to look at upgrade blockers and replatform effort that a routine check ignores.

Score each check as Pass, Watch, or Fail. Count the Fails by severity, not by quantity. Ten cosmetic Fails matter less than one Fail in your payment or ERP path.

Section 1: Code health and customization (checks 1 to 8)

Custom code that overrides Magento core classes directly, instead of using plugins and preferences, is the single most common reason upgrades turn into rewrites. This section finds that debt before it surprises you.

1. Core modification scan. Confirm no files under vendor/magento or app/code/Magento have been edited in place. Any direct core edit is a Fail.
2. Plugin and preference discipline. Check that customizations use the plugin (interceptor) system, di.xml preferences, or events rather than class rewrites that block future updates.
3. Coding standard compliance. Run phpcs against the Magento coding standard and record the error and warning counts as a baseline.
4. Static analysis. Run phpstan or the Magento quality tools and capture the number of type and null-safety issues.
5. Deprecated API usage. Grep the codebase for calls to APIs deprecated in your target version. Each one is upgrade work.
6. Dead code and unused modules. Identify modules enabled in config.php that no page, cron, or API path actually reaches.
7. Composer discipline. Confirm the project is managed through Composer with a committed composer.lock and no manually copied packages.
8. Frontend build health. Check whether the theme still depends on the legacy Luma stack or has moved to a modern frontend. A Luma dependency is a major factor in both performance and upgrade cost, and it is the strongest signal that a Hyva frontend build belongs in the plan.

Section 2: Extension and module inventory (checks 9 to 15)

Every third-party extension is a dependency you do not control. Before any upgrade, each one needs a vendor, a version, a license status, and a compatibility verdict against your target Magento version. Abandoned extensions get replaced before the upgrade, never during the go-live window.

9. Full extension register. List every third-party module with vendor, version, license status, and renewal date.
10. Target-version compatibility. For each extension, confirm a released version supports your target Magento or Adobe Commerce version.
11. Abandonment check. Flag any extension whose vendor has shipped no release in 18 months as a replacement candidate.
12. Overlap and conflict map. Identify extensions that touch the same area (two search modules, two checkout modifiers) and are likely to conflict.
13. Core-touching risk tier. Mark whether each extension touches checkout, pricing, tax, shipping, catalog indexing, customer groups, or authentication. These are the high-risk tier.
14. Override audit. Record any place where an extension overrides another extension or core, since these break silently on upgrade.
15. License and support status. Confirm each paid extension has an active license so you can get patches during the project.

Section 3: Security and PCI posture (checks 16 to 24)

Security findings are P0 by default. The store should be no more than one minor version behind, with security patches applied within 30 days, zero known critical or high CVEs in dependencies, and no development leftovers exposed to the public internet. Align this section with the Adobe Commerce security best practices.

16. Patch level. Compare the installed version and applied security patches against the latest release. Anything more than one minor version behind is a Fail.
17. Dependency CVE scan. Scan composer.lock and JavaScript bundles for known vulnerabilities. Critical and high counts should be zero.
18. Exposed development files. Confirm there is no publicly reachable .git directory, database dump, phpinfo file, or log file.
19. Admin hardening. Verify a non-default admin URL, two-factor authentication, CAPTCHA, and least-privilege admin roles.
20. Secret management. Confirm API keys and payment credentials live in environment configuration or a vault, not in the database or committed files.
21. PCI scope map. Document how card data flows. A hosted or tokenized payment integration keeps most of your store out of PCI scope; a self-hosted card form pulls it back in.
22. TLS and headers. Confirm site-wide HTTPS, current TLS, and security headers such as HSTS and a content security policy.
23. Access and audit logging. Verify admin actions and SSH access are logged and reviewable.
24. Backup and recovery test. Confirm backups exist and, more importantly, that a restore has actually been tested.

Section 4: Performance and Core Web Vitals baseline (checks 25 to 32)

Capture a real field-data baseline before you change anything, so you can prove the improvement later. The current Core Web Vitals targets are LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 at the 75th percentile, per the Core Web Vitals thresholds. Measure per template, not as a single site average.

25. Field LCP by template. Record the 75th-percentile LCP for homepage, category, product, and checkout separately.
26. Field INP. Record INP for the same templates, since interactivity problems often hide in filters and add-to-cart.
27. Field CLS. Record layout shift, most often caused by images without dimensions and late-loading banners.
28. Time to first byte. Measure server TTFB. Under 200 milliseconds is the target; higher points at caching or hosting.
29. Full-page cache posture. Confirm Varnish or an equivalent full-page cache is active and that hit rates are healthy.
30. Indexer health. Confirm indexers run on schedule and complete, since stale indexes slow catalog pages.
31. Cron and queue health. Verify cron runs reliably and message queues are draining rather than backing up.
32. Third-party script weight. Measure how much render-blocking JavaScript comes from tags and pixels, a common hidden cause of poor field scores. Our guide on how to fix Magento Core Web Vitals without replatforming covers the per-template fixes in depth.

Section 5: ERP and integration layer (checks 33 to 39)

The integration layer is where audits that skip it turn into failed projects. Every connection to an ERP, PIM, WMS, CRM, or POS is a place where an upgrade or platform move can break order flow, pricing, or inventory. This section is entirely absent from most audit checklists, which is exactly why integration failures surprise so many teams.

33. Integration register. List every inbound and outbound integration with direction, protocol, and business owner.
34. Sync pattern. For each integration, record whether it is real-time, batch, or queue-based, and how failures are retried.
35. Idempotency. Confirm order and inventory writes are idempotent so a retry cannot double-post an order or oversell stock.
36. Pricing and catalog source of truth. Document whether Magento or the ERP owns pricing, catalog, and customer-specific pricing, since a wrong assumption here breaks B2B accounts.
37. Inventory reservation logic. Confirm how stock reservations behave under concurrent orders and ERP sync lag.
38. Middleware dependency. Identify any middleware or iPaaS in the path and whether it will support the target platform.
39. Failure visibility. Confirm someone gets alerted when an integration fails, rather than discovering it from a customer complaint. A deep integration partner ecosystem matters here; see the Bemeir technology partners network across payments, shipping, and fraud.

Section 6: Data, catalog, and SEO baseline (checks 40 to 44)

Before any migration, crawl and export every URL, record canonical tags and metadata, and capture the sitemap. These become your verification list after the change. Losing rankings to broken redirects is a self-inflicted wound that a baseline prevents.

40. URL inventory. Crawl and export every indexable URL on the current store.
41. Redirect map. Document existing 301 redirects so none are lost in a rebuild.
42. Metadata and canonical baseline. Record titles, meta descriptions, and canonical tags for top-performing pages.
43. Structured data. Capture existing product, breadcrumb, and FAQ schema so it survives the move.
44. Catalog data quality. Assess attribute completeness, duplicate SKUs, and image coverage, since dirty catalog data multiplies migration effort.

Section 7: Infrastructure and release governance (checks 45 to 47)

An upgrade is only as safe as your ability to roll it back. Confirm the stack meets target requirements, staging matches production, and a tested rollback exists before go-live.

45. Stack readiness. Confirm PHP, database, search, and cache versions meet the target release requirements, and that CLI and web PHP versions match. The Magento 2.4.9 upgrade checklist lists current stack requirements.
46. Staging parity. Confirm staging mirrors production data volume and configuration closely enough to trust the test.
47. Tested rollback. Confirm a database snapshot procedure and a last-known-good code tag, and that the rollback has been rehearsed.

Scoring the audit: severity tiers

Translate raw Fails into a priority stack. Fix P0 before anything else, and let the P0 and P1 counts drive the stay-or-move decision.

The replatform-versus-upgrade decision framework

Once the checks are scored, the choice becomes a comparison rather than an argument. Use the pattern of Fails, not their total count, to point toward the right path.

A store that passes Sections 1, 2, and 5 and only trips on frontend and performance is usually a Hyva and upgrade candidate, not a replatform. A store failing the code health and integration sections often costs more to drag forward than to rebuild. For most Magento merchants the honest answer is to stay on Magento and Adobe Commerce development and modernize, because the platform is rarely the problem. When a genuine platform move is on the table, the same audit informs a fair comparison against Shopify and Shopify Plus, BigCommerce, or Shopware, each of which fits a different kind of catalog and B2B need.

What the findings should produce

The deliverable is not a PDF that lists problems. It is a prioritized plan: P0 items with owners and dates, a scoped upgrade or replatform recommendation with a rough range, and a verification list built from your Section 6 baseline. That is the difference between an audit that sells a project and one that de-risks it. If you want a second set of hands to run these checks and turn them into a plan, the team at Bemeir does exactly this work.

Frequently asked questions

How long does a Magento technical audit take?

For a mid-market store with a normal number of extensions and one or two integrations, a thorough audit across all 47 checks usually takes one to two weeks. Stores with heavy customization, undocumented integrations, or no staging environment take longer because the auditor has to reconstruct how the system actually behaves before scoring it.

Do I need an audit if I only want a version upgrade, not a replatform?

Yes. The checks in Sections 1, 2, 3, and 7 exist specifically to find upgrade blockers: core modifications, incompatible extensions, unpatched security holes, and stack mismatches. Skipping the audit is how a routine upgrade turns into an emergency during go-live weekend.

Can I run this checklist myself?

You can run the inventory and baseline checks yourself, especially Sections 4 and 6, using free tooling. The code health, extension conflict, and integration checks reward experience, because the hard part is judging how risky a given finding is, not spotting that it exists.

What is the single most overlooked section?

The integration layer, Section 5. Most published audit checklists omit it entirely, yet failed ERP and inventory sync is one of the most common reasons a Magento upgrade or replatform goes wrong after launch.

Does a bad audit result mean I should replatform?

Not usually. A poor result more often means the current store needs remediation before any big move, and that remediation frequently makes a replatform unnecessary. The audit exists to make that call with evidence rather than fear.