When a Magento or Adobe Commerce store starts to feel like it is holding the business back, the usual reaction is to talk about rebuilding it. Releases slip, the catalogue does odd things, checkout throws errors nobody can explain, and a fresh start sounds decisive.
A rebuild without a diagnosis is a guess with a bigger budget. The same problems tend to move across to the new platform, because nobody established what was causing them. An audit is how you find out first.
Start with what buyers actually do
The useful place to begin is how trade customers use the site, rather than how it was meant to be used. Where do they search because the navigation does not narrow things down? Where do they land on a product page and leave? Which step of the basket do they drop out at, and which orders still arrive by phone or email when they could have been placed online?
Those patterns show where confidence drops. They also stop the audit turning into a code review that has lost sight of why anyone asked for it.
Then the code and the extensions
The question for the code is whether it can be changed safely six months from now, which is a different question from whether it works today. That means looking at how the custom modules are put together, how much business logic is hidden in plugins and observers, whether there are tests, and how much has been copied rather than reused.
Most Adobe Commerce stores also collect third-party extensions over the years. Each one made sense when it went in. Together they compete for the same events, slow pages down and make every upgrade harder. Some are worth keeping because rewriting them would cost more, but that should be a decision someone made on purpose rather than something the store inherited.
Where the platform is doing another system's job
A lot of B2B stores end up acting as the pricing engine, the customer service console and a data warehouse at once, because each was the quickest place to put something when it was needed. Custom work in B2B is normal and usually necessary. What matters is whether it sits in the right place, with clear edges, so the next change does not mean untangling the last three.
The same goes for integrations. The ERP, PIM, CRM, search and the warehouse all touch the store, and many problems that look like platform faults are integration or ownership problems showing up through the platform. An audit that looks at Magento on its own misses them, so we map which system owns which data and what happens when a sync fails.
Performance where it costs money
A page speed score for the home page tells you very little about a trade store. The slow parts are usually in the account area, large baskets, negotiated pricing, quick order and catalogues filtered by customer permissions. We look at caching, indexing, cron, queues and database load against those journeys, at the times of day the business is busiest.
Security and how releases happen
We check the patch level, who has admin access (including people who have left), how secrets are stored and whether there is somewhere to test that is separate from production. Then how a change gets from a developer to the live site. If a release depends on one person remembering the steps, or rollback has never been tried, the risk is high even when the code is decent.
What you should get back
A list of fifty findings in no particular order is not much use to anyone deciding where to spend. A useful audit ranks what it finds by consequence, separating what affects orders and security now from what is untidy but can safely be left. It should also show where one problem causes another, so money does not go on bigger servers when the real cause is a pricing customisation fighting the indexer.
Most of all it should answer the question that started it: keep and fix, or move. Often the honest answer is that a handful of targeted fixes will do more than a rebuild, with far less disruption. Sometimes it is the opposite, and then the audit gives the rebuild a scope based on evidence.
When it is worth doing
The obvious time is after a run of incidents or failed releases. It is also worth doing before a replatform decision, before a big integration project, after the developer who knew the store has left, or when people inside the business disagree about what is wrong. Development blames the requirements, operations blames development, and the board sees the costs going up. A shared set of facts settles a lot of that.
The best time is usually while the store is still trading well but confidence is slipping, because there is still room to fix things in a measured way.
For a rough read before talking to anyone, the rebuild or improve check takes a few minutes. To book one, see our Adobe Commerce audits.
