Magento 2 patch installation checklist
A practical checklist for installing Magento 2 security patches without breaking checkout, admin workflows or third-party extensions.
What to check before touching production
A Magento patch should never start with production SSH. Start with the current Magento version, PHP version, database version, Elasticsearch or OpenSearch version, enabled modules and recent deployment history.
The risky part is rarely the patch command itself. The risk usually lives in extension compatibility, old theme overrides, custom plugins and stores where nobody is quite sure what changed last time.
- Confirm the exact Magento version and current composer.lock state.
- Check whether the patch has already been partly applied.
- Snapshot database and code before any change.
- Apply the patch on staging first.
- Test browse, search, add to basket, checkout, payment and admin orders.
Choose the right patch method
Confirm whether the change is an Adobe security patch, a Quality Patches Tool fix, a Cloud patch or a custom vendor patch. The delivery route matters because it determines how the change is tracked, reapplied and removed later.
Adobe recommends the Quality Patches Tool for supported individual patches on Magento Open Source and non-Cloud Adobe Commerce projects. Cloud projects use their deployment configuration and patch packages. Avoid turning a temporary patch collection into a substitute for keeping the Magento release supported.
- Run the Quality Patches Tool status command and save the output before changing anything.
- Check dependencies, deprecations and replacement patches for the installed release.
- Apply one patch at a time where practical so a regression has a clear cause.
- Keep the patch declaration in version control rather than relying on an undocumented server change.
Build a staging test matrix
The patch should be installed on an environment that matches production closely enough to expose real conflicts. That includes PHP, database, OpenSearch, Redis, enabled modules, theme code and the deployment mode.
Test the paths that create revenue and the admin actions the operations team uses every day. A green homepage is not evidence that checkout, payment callbacks or order fulfilment still work.
- Browse category, search and product pages as a guest and signed-in customer.
- Add, update and remove basket items, including promotions and configurable products.
- Place test orders through each active payment and shipping method.
- Check account registration, password reset, transactional email and payment webhooks.
- Verify admin login, order processing, refunds, catalogue saves, cron, queues and indexers.
- Compare application logs, browser errors and response times with the pre-patch baseline.
Write rollback before the maintenance window
A rollback needs named artefacts and an owner: the Git revision, composer.lock, database snapshot, media strategy, cache steps and the decision point for abandoning the deployment. Saying that a backup exists is not enough unless somebody has confirmed it can be restored in the available window.
Schedule production work for a quieter trading period, tell stakeholders what will be unavailable and define who approves reopening. If the deployment changes database schema or queued work, the rollback plan must account for data created during the window.
Deploy, verify and keep evidence
After deployment, clear the appropriate caches and repeat the critical-path tests against production. Confirm that cron, consumers, indexers, payment callbacks and monitoring have recovered before closing the change.
Keep the before-and-after patch status, commit reference, deployment log, test result, scan result and sign-off date. This is useful for PCI evidence, incident response and the next upgrade, when patches may need to be reapplied or removed because the fix is included upstream.
When to bundle patches into an upgrade
If the store is more than one patch level behind, depends on several temporary fixes or already has PHP, search or Composer compatibility problems, a supported version upgrade may be cleaner than stacking more patches.
Treat that as a separate project with compatibility analysis, QA, user acceptance testing, launch planning and post-launch monitoring. The decision should reduce long-term maintenance risk, not merely make the patch list look shorter.