Situation
Two versions behind, with a lot of plumbing attached
The store was two Magento versions behind and on an old PHP version, which meant it was also behind on security patches. It had an integrated WordPress blog, a card payment module and an SMTP module installed as loose files rather than managed packages, a custom form builder, and a server configuration file carrying 1,619 redirect rules built up over years of URL changes.
Every one of those rules protects a search ranking. Losing them in an upgrade is the kind of damage that shows up in the sales figures weeks later.
What we did
Upgrade the platform, then bring every attachment along
- Email Magento 2.4.8 changed its mail library. The SMTP module was replaced with a managed package that supports it, and the form builder was patched to hand its emails to the new mailer.
- Payments The card payment module moved from loose files to a managed package at a version built for 2.4.8, so future updates are a one-line change.
- PHP 8.4 Deprecations that broke the price import, the blog and the product quick view were fixed.
- Redirects All 1,619 rules were kept. Two malformed ones that broke the server configuration were corrected.
- After go-live Every email was being sent twice, traced to how the mail service responded to large messages, and fixed. The currency switcher needed its own fix for the new page cache.
The upgrade was rehearsed on our own copy of the store, with the real redirect file and the real payment sandbox, before the release window.
Result
Current, supported, and nothing lost on the way
2.4.8from two versions behind
1,619redirect rules intact
Monthlysecurity patches now applied as released
Worth checking on your store
Before any upgrade
- Count the modules installed as loose files rather than managed packages. Each one is an upgrade risk.
- Find your redirect rules and make sure they are in version control, not only on the server.
- Send a test email from every form and payment flow on staging before the release, not after.