Insights
What to check in a Magento or Shopify store before you replatform: a checklist by shopping stage and a fix, redesign or replatform rule. Before you replatform, audit the store one shopping stage at a time (find, judge, buy, return) and mark every problem as platform-caused or store-caused.
The short answer
Before you replatform, audit the store one shopping stage at a time (find, judge, buy, return) and mark every problem as platform-caused or store-caused. Only platform-caused problems are a reason to migrate. Store-caused problems, such as weak navigation, thin product content or a search box that cannot handle ordinary queries, will follow you to the new platform unless someone fixes them first.
The result of the audit is one of three decisions:
- Fix the current store, because most problems are store-caused and small enough to repair in place.
- Redesign on the same platform, because the problems are store-caused but structural, such as the information architecture or the theme.
- Replatform, because the platform itself blocks something your store needs, and you can name what.
This page is about the platform-specific question. For a general audit of a product, see our UX product audit. For the difference between a UX audit and a heuristic evaluation, see UX audit vs heuristic evaluation.
What to collect before the audit
An audit that starts from opinions ends in opinions. Gather these first, so every finding can be tied to something shoppers did.
- The analytics funnel. Sessions to product list, product page, cart, each checkout step and order, split by device. The biggest drop between two steps tells you which stage to audit hardest.
- Site search terms. What shoppers type, which queries return nothing, and which are followed by an exit.
- Returns reasons. Returns coded as "not as described" or "wrong size" point at product-page content, not the platform.
- Support tickets and chat logs. Questions about delivery, stock, sizing or discounts show where the store failed to answer.
- Performance field data. Core Web Vitals for your real visitors, not a one-off lab score. web.dev defines "good" at the 75th percentile of page loads as Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint at 200 milliseconds or less, and Cumulative Layout Shift at 0.1 or less.
- A list of installed apps or extensions, with what each does and who owns it.
- Your own decisions. Which parts of the store are the way they are because someone chose it, and which because the platform forced it. The audit tests this list.
Find: navigation, filters and search
Shoppers who cannot find a product never reach a product page. This is where store-caused problems are most common.
| Check | Cause | What to look at |
|---|---|---|
| Category structure and labels | Store-caused | Do category names match the words shoppers use in search? Is any product reachable only by one path? |
| Filters and sorting | Mostly store-caused | Are the attributes shoppers choose by (size, material, compatibility) filterable? Both platforms support filtering, but it can only filter on data that has been entered cleanly. |
| Site search quality | Store-caused, sometimes platform-caused | Test real queries from your search log. Baymard Institute's 2026 search benchmark found 56% of sites fail to support users' search needs. Non-product queries such as "return policy" had issues on 66% of sites, and queries with abbreviations or symbols, such as "13in laptop sleeve", on 54%. |
| Catalogue and attribute model | Platform-caused when it blocks you | Can the platform express your catalogue: many variants, bundles, compatibility, per-customer pricing? If you work around the model with unstructured text fields, filters and search suffer. |
| Mobile navigation | Store-caused, theme-bounded | Menu depth, tap targets and whether filters are usable on a phone. WCAG 2.2 adds a minimum target size of 24 by 24 CSS pixels (criterion 2.5.8, level AA). |
A common finding here is that the data is the problem. Inconsistent product attributes make filters unreliable and search poor on any platform. Migrating moves the mess.
Judge: product list and product page
This is where a shopper decides, so the audit asks whether the page answers the question they have.
| Check | Cause | What to look at |
|---|---|---|
| Product list items | Store-caused | Does each item show what separates it from its neighbours: price, key attributes, stock state, variants? |
| Product page content | Store-caused | Compare against your returns reasons and support tickets. If shoppers ask the same question repeatedly, the answer is missing or buried. |
| Variant selection | Platform-caused in part | How are options chosen and how does the page show stock for each? Custom selectors can be hard to build within a theme's limits. |
| Delivery, returns and warranty information | Store-caused | Reachable from the product page without leaving it? |
| Page weight and Core Web Vitals | Shared | Compare field data to the thresholds above. Apps, tracking scripts and unoptimised images are store decisions. Theme architecture and server hosting are platform-adjacent. Split the causes before judging the platform. |
| Third-party apps and extensions | Store-caused | Each one adds script and interface. Count them, and ask what each earns. |
On Adobe Commerce, themes override view-layer resources, and Adobe advises building a custom theme that inherits from a default one rather than editing the default theme files, because upgrades can overwrite those edits. A heavily edited default theme is a store decision that makes every upgrade harder, and a common reason a redesign on the same platform is the right call.
On Shopify, the theme is similarly the boundary of what a product page can do without custom development. In our GT Tools Shopify Plus work, the design audit reported on the constraints of working within a low-code platform, and a visual variant selector in the product thumbnail turned out to be technically difficult because of those constraints. That is the shape of a genuine platform limit: a specific interface you want, a specific reason the platform makes it hard. A vague sense that "the platform is slow to change" is not.
Buy: cart and checkout
Checkout is where platform and store causes are most tangled, and where the platforms differ most.
Platform-caused checks
- How much of checkout you control. On Shopify, checkout.liquid is no longer supported for the Information, Shipping and Payment steps, and customisation goes through Checkout Extensibility: UI extensions, Functions and related extension types. Shopify's help documentation says advanced checkout customisation is available only on Shopify Plus: eligible apps that customise the information, shipping and payments pages, and the Checkout Branding API, are Plus only, while standard plans get standard customisations and eligible apps on the thank-you and order status pages. If your audit finds a checkout change you need that this model cannot deliver, that is a platform finding.
- On Adobe Commerce, checkout is built from UI components, and Adobe documents customising each step by changing a component's JavaScript or template, or by adding, disabling or removing components. That gives control, and the cost is development work and upkeep through upgrades.
- Payment and delivery options the platform or its payment integrations cannot support.
Store-caused checks. Baymard Institute's 2026 checkout benchmark found 59% of desktop and mobile checkouts rated "mediocre" or worse, and that 17% of over 1,000 surveyed shoppers had abandoned a purchase in the previous three months because checkout was too long or complex. Most of the failing practices it lists are choices a store can change:
- Marking both required and optional fields (50% of sites fail to). In Baymard's testing, 32% of participants missed a required field when only the optional ones were marked.
- Explaining why a phone number is required (47% fail to); 68% of surveyed shoppers were reluctant to give one.
- Offering account creation after the order, at the confirmation step, rather than before it (56% fail to).
- Using a delivery date rather than only a delivery speed (48% fail to).
Check these in order, on a real mobile device, with a real basket. Also check the cart: can quantity be changed with an obvious control, and are delivery cost and any discount visible before the shopper commits?
Return: accounts, orders and accessibility
The return visit decides repeat revenue, and it is the stage audits skip.
- Order status and tracking: can a shopper find an order and its delivery state without contacting support? Store-caused, though the platform sets what data is available.
- Returns journey: is the policy findable and the process clear? Compare with your returns reasons.
- Account and login: WCAG 2.2 adds Accessible Authentication (Minimum) at level AA, which says login steps should not require a cognitive test such as remembering or transcribing, unless an alternative exists, and Redundant Entry at level A, which says information already entered in a process should be filled in or selectable, not retyped.
- Accessibility across all four stages. Check keyboard use, focus visibility and error messages through the whole path to purchase. If you sell to customers in the European Union, note that the European Accessibility Act, Directive (EU) 2019/882, sets 28 June 2025 as its application date and covers e-commerce services. The directive has an exemption for microenterprises providing services, so check whether it applies to you, and ask a lawyer for advice on your own case.
- Support and help: WCAG 2.2's Consistent Help criterion asks that help mechanisms repeated across pages appear in the same relative order.
Accessibility problems are mostly store-caused and theme-bounded. A theme that fails them is a reason to redesign, which does not by itself justify a migration.
Fix, redesign or replatform
Take every finding from the checklists, label its cause, then apply this rule.
| What the audit found | Decision | Why |
|---|---|---|
| Most findings are store-caused: content, labels, attributes, search tuning, checkout fields, app clean-up | Fix | These move to a new platform unchanged. Repair them where they are, and measure. |
| Findings are store-caused but structural: information architecture, a heavily edited theme, inconsistent templates, accessibility | Redesign on the same platform | The platform supports what you need, but the store was assembled piecemeal. |
| A named, specific need the platform cannot meet: checkout control you cannot get on your plan, a catalogue model that cannot express your products, performance that remains poor after the apps and images are dealt with | Replatform | The constraint is the platform. Write it down as a requirement. |
| Platform limits and store problems both present | Fix the store-caused first, then re-audit | Otherwise you cannot tell whether the new platform solved the platform part. |
Two cautions. First, a Shopify plan upgrade is a different decision from a migration, and Magento-to-Shopify is not the only move: if a limit is plan-specific, check whether a higher plan removes it. Second, if you do replatform, the audit becomes the brief: the platform-caused findings are the requirements the new store must meet, and the store-caused findings are the design work you carry across. Keep your URLs and put redirects in place for any that change.
Next step
If the audit says replatform, the audit is also the brief for it. If it says fix, you have saved the cost of a migration. Either way, you want the decision to rest on findings rather than on frustration. Our UX product audit is built to do that, and our work on commerce and transactional products covers what comes after.
