If you are an Adobe Commerce merchant, you are familiar with the importance of routine platform upgrades — and the challenges of planning and executing on an active production site. That’s why we strongly recommend you invest effort and resources in pre-upgrade platform audits — proactive, comprehensive assessments of all the elements that affect your store’s performance, stability, and profitability.

In this post, we do a deep dive into the audits you should do before upgrading to Adobe Commerce 2.4.8. It tracks the process we use in restructuring upgrades for our clients — a project that takes the success rate of both core and custom upgrades from 20% to over 90%. With images and commentary for each step, this guide may also help you develop your own audit templates.

The sooner you can get in front of an upgrade and identify risks, the faster you can fix or work around them.

If you want to go deeper into any of these topics, reach out for a conversation tailored to your site and your needs.

Pre-Upgrade Audit #1: Core Code and Security

Every upgrade project should begin with these questions:

Is the starting platform version supported? If its end-of-life date has passed, plan for a full replatform, rather than an upgrade. (For example: 2.3.x and 2.4.0-2.4.2 are out of support for Adobe Commerce merchants.)

Does any underlying data compromise performance or security? Check page weights, table sizes, stale records, and customer data hygiene. If any exceed best-practice benchmarks, make a plan to clean them.

Does the core file system and database pass a compatibility check? Upgrade without this step risks functional failures and security holes.

Has the system passed all security scans? Look for vulnerabilities in the core platform itself, as well as any reached through extensions, custom code, or integrations.

Backup Make backups of the code and data to give you an easy way back if the upgrade goes wrong.

If the core platform and data don’t meet standards, plan to renovate before upgrading — or your risks increase.

Looking at the outcomes of our upgrades over the last two years, the chance of failure (and the human cost that goes with it) is between 80 and 90%. By front-loading remediation with audits, you can limit failures to less than 10%.

For technical risk management, a dependable server restoration plan can help you recover quickly if an upgrade fails.

Pre-Upgrade Audit #2: Hosting Infrastructure

How well your upgraded platform will perform depends in large part on the supporting infrastructure. Before upgrading, consider these questions:

Does the hosting environment meet performance requirements? Monitor core, custom code, and infrastructure for bottlenecks and degradation.

Is the server software compatible with the new platform? Keep your operating system, PHP, NGINX/Apache, ElasticSearch, and MariaDB up to date according to Adobe Commerce’s system requirements.

Does your developer tooling introduce overhead? Our audits often find development tools, like New Relic’s APM, running in production — impacting CPU, memory, and disk on already throttled infrastructure.

If your stack needs a performance lift before an upgrade, a speed optimization service can help identify bottlenecks and reduce server load.

Workflow Automation

How well your hosting environment supports your upgrade project affects how much you disrupt routine operations. During audits we usually find one or more of these issues, each of which increases risk:

Without continuous integration and deployment (CI/CD), manual publishing limits testing. Fix: Standardize your build across environments and use automation to push code to production.

Spread your code repositories thin. Fix: Consolidate all the code for your site (core, customizations, 3rd party extensions, data) in a single repo.

Bundled upgrades push all the components at once, increasing the risk of failure. Fix: Identify upgrade types, classify them as core, custom, and 3rd party, and create focused pipelines for each.

A proper version control system and GIT repository setup can also make staged releases and rollback planning much safer.

Pre-Upgrade Audit #3: Custom Code

Let’s say your audit of the core platform, data platform, and infrastructure all passed muster. How about your custom code? Here’s what we check:

Does all your custom code work with the new platform version? Many internal customizations involve direct core hacks — and most of those don’t translate well. Upgrade without an audit here invites functional issues and security flaws.

Does the data cleanliness you checked earlier affect workflows? You can expect cascading fails if the platform tries to process missing or malformed records.

Do you have comprehensive test coverage? We frequently find complete absence of functional, integration, or performance tests — creating uncertainty in upgrade outcomes.

Can you perform upgrades of specific extensions, rather than bundling them all together? Extension-specific pipelines simplify development, testing, and troubleshooting.

For teams managing larger change sets, an advanced custom fields style review process can help organize custom data dependencies before changes go live.

Running Your Audits

At least at first, these audits are not routine. Each one builds knowledge of the platform, infrastructure, and customizations and can lead to follow-on strategies and workflows that yours teams will adopt.

Stay tuned. Coming next: pre-upgrade audits for extensions and integrations.

And if you want to speed your upgrade projects right now, let’s talk.