1The challenge
Six installations means six times the risk. Extreme Intimo’s platform was due for an upgrade:
- An older Magento version that missed security fixes.
- PHP 7.4, which is no longer supported.
- Custom modules that had never been tested on newer versions.
- Six upgrades by hand meant six chances for something to break.
Why upgrades go wrong
A Magento upgrade touches the core, every extension and every custom module at once. With a major PHP jump on top, small incompatibilities pile up. A repeatable, scripted process keeps the risk low, especially when the same upgrade runs on several installations.
2Our approach
We treated the six upgrades as one programme: analyse once, script the process, then run it per country on a separate upgrade server.
Audit first
Every custom module checked for compatibility with the new Magento and PHP versions, including patches and overrides, across all regions.
Scripted per region
DevOps scripts for deployment, configuration and go-live, tested on a separate upgrade server for each country.
Everything upgraded
Core, database and purchased extensions upgraded, and the Hyvä theme updated on every installation.
New hosting, no downtime
Migration to Hypernode, followed by zero-downtime deployments through Bitbucket Pipelines.
3The result
All six of Extreme Intimo’s webshops run on a supported Magento and PHP version, on new hosting, with releases that no longer take the webshop offline. Because the process is scripted, the next upgrade is a repeat, not a new project.
Security patches, such as the emergency fix for SessionReaper, can now be rolled out across every installation quickly.
Also read: how we protect client webshops when a critical Magento vulnerability is announced.
?Frequently asked questions about Magento upgrades
How often should Magento be upgraded?
Security patches as soon as they are released, and version upgrades before your current version loses support. Waiting makes every upgrade bigger.
What usually breaks in an upgrade?
Custom modules and extensions that aren’t compatible with the new version, especially when PHP changes too. That’s why we audit them first.
Can you upgrade without downtime?
The upgrade itself is prepared and tested on a separate server and the go-live is scripted. After the move, regular releases run without downtime.
We have several webshops. Is that much more work?
There is more to test, but with a scripted process most of the work is done once and repeated.
