If the upgraded store feels slower
Build a comparable before-and-after record before making another change.
Treat an upgrade as a business-system change
A Magento upgrade is not verified merely because installation finishes and the homepage opens. The store includes payment, delivery, catalogue management, integrations, scheduled work and customer communication. Midoriweb builds the test plan around those workflows so the release decision reflects the system the business actually operates.
This guide focuses on verification. Our Magento upgrade planning guide covers the broader preparation and scope. Adobe’s upgrade checklist is a useful primary reference, but the store’s own customisations and dependencies must shape the final test set.
Start by recording the current version, target release, extension changes, infrastructure dependencies and intended deployment method. Do not assume that compatibility of the core package establishes compatibility of every custom module or connected service.
Establish a baseline before the upgrade
Record how critical journeys behave on the current version. Existing defects should be labelled so they are not accidentally attributed to the upgrade or silently accepted as new behaviour. Capture relevant configuration and representative test data in an authorised environment.
Choose business outcomes rather than only page availability. A customer should be able to select the intended product, obtain the right price and delivery method, complete an authorised test payment and see the correct order state. Staff should be able to fulfil, cancel or otherwise manage the order according to the store’s processes.
Keep the baseline reproducible. Document the product types, customer groups, websites and provider modes used. A comparison is weak if the pre-upgrade test uses a simple guest basket while the post-upgrade test uses a different account and promotion.
Validate the environment and dependency matrix
Confirm supported runtime and service versions for the target release using current vendor documentation. Include PHP, database, search, cache and required extensions. The exact compatibility matrix changes, so a checklist should reference the chosen release rather than embed an evergreen version claim.
Review third-party module support and custom-code assumptions. A module loading without an immediate error does not prove that its checkout or background behaviour is compatible. Identify changed APIs, schema work and frontend dependencies relevant to the installed extensions.
The staging environment should represent production where the test depends on it. Record differences in catalogue size, infrastructure and external services. Those limitations do not make staging useless, but they must be considered when deciding what additional production verification is required.
Test catalogue discovery and product behaviour
Cover category navigation, search, filtering and representative product pages. Include the product types and custom options that generate meaningful business volume. Check image galleries, variant selection, stock messages and price presentation in the correct website and customer context.
Verify that catalogue updates reach the storefront through the normal process. A product page that looks correct immediately after a full rebuild does not establish that scheduled indexing continues to work. Include a controlled update and observe the relevant background processing.
Our search guide, image guide and indexer guide provide narrower diagnostic paths if a test fails. Record the failure with a reproducible example rather than collecting screenshots without context.
Exercise checkout across meaningful combinations
Test guest and signed-in journeys, relevant address flows, key delivery methods and supported payment methods. Include an applicable promotion and a basket that should remain excluded from it. The matrix should reflect actual business rules without attempting every theoretical combination.
Verify success and failure handling. Address validation, unavailable delivery, payment rejection, authentication interruption and repeated interaction can reveal defects missed by a single happy-path purchase. A failed response must not leave the customer unsure whether payment or order creation completed.
Use provider test arrangements and controlled data. Do not treat a simulated payment as proof of a real provider’s production behaviour. Record exactly which provider calls and notifications were exercised, and agree any necessary live verification separately within an appropriate authorised process.
Follow orders through operations and integrations
The test should continue after checkout. Verify the order reaches the intended ERP or warehouse, that stock-related events follow the agreed model and that shipment information returns correctly. Include partial fulfilment or other exceptions that the business actually uses.
Our order-sync guide, inventory-sync guide and shipment tracking guide describe the relevant evidence. A connector reporting “connected” is not equivalent to a completed business transaction.
Check customer and administrator messages independently. Confirm recipients, templates, links and attachments where used. Test environments should not send unplanned messages to real customers or create genuine warehouse work, so those side effects need explicit controls.
Verify scheduled work and staff workflows
Observe cron, indexers and relevant consumers through their normal execution path. Manual commands can help diagnose a failure but should not replace verification that the scheduled arrangement works after deployment. Check the jobs that support exports, emails and housekeeping as applicable to the store.
Staff also need representative Admin tests: product editing, order handling, imports, reports and custom operational screens. Permissions should remain appropriate. A successful test under a full administrator account may miss a role-specific problem affecting the people who actually perform the task.
Keep evidence concise and actionable. For each failed case, record expected behaviour, actual behaviour, environment and reproduction steps. This allows the developer to fix the defect and the business owner to verify the result without repeating the entire conversation.
Check performance and public discovery
Compare important page and transaction timings against the baseline under similar conditions. An upgrade can change cache behaviour, frontend assets or background workload. A functional pass should not conceal a substantial regression that would affect trading.
Verify canonical URLs, redirects, indexability and sitemap coverage for public pages. Confirm that staging restrictions have not been copied to production and that production content has not been accidentally exposed through a test environment. These checks should follow the actual deployment design, not a generic assumption about configuration inheritance.
For frontend experience, use the Core Web Vitals guide. For peak-demand questions, a separately planned load test may be appropriate. Neither a single speed score nor a homepage screenshot covers the complete release.
Rehearse deployment and rollback decisions
The release plan should specify backup coverage, deployment steps, verification gates and who can decide to proceed or roll back. Record how new orders and external side effects are handled if a problem appears after customers resume trading. A database restore is not automatically a safe rollback once new commercial records exist.
Rehearse the process in a suitable environment and measure the relevant timings. Identify which changes can be reversed independently and which require a more careful recovery. Do not discover during an incident that the only backup omits media, configuration or the data needed by a custom module.
Midoriweb’s Magento upgrade service can bring the technical and business checks into one release plan. The final handover should show what passed, what remains uncertain and who owns post-release monitoring. That is a more useful assurance than an unsupported statement that everything has been tested.
Upgrade testing questions
Is staging enough?
It is essential for many checks, but its differences from production must be documented. Targeted post-deployment verification is still needed.
Should every extension be upgraded at the same time?
That depends on compatibility and scope. Record the chosen versions and test their interactions rather than expanding the release without a reason.
Can we promise zero downtime?
Only make commitments supported by the actual deployment architecture and rehearsal. The plan should state the expected impact and recovery process honestly.