Case study · B2B and retail wholesaler · Netherlands
Four-language B2B Magento store upgraded to 2.4.9 and PHP 8.4 while it kept trading
Magento core, PHP 8.4 and OpenSearch went up in one release, even though an expired extension licence had Composer stuck. We released it in a quiet window, ready to undo it if anything looked off, and customer orders were coming in straight after.
- Magento 2.4.9
- PHP 8.4
- OpenSearch 2.19
- Redis
- Ploi
4
Store languages live on 2.4.9
2.4.9 + PHP 8.4
Supported and fully patched
0
Console errors after launch
01
Problem
One Magento install ran a wholesale shop and a retail shop in Dutch, English, German and French. It had fallen several releases behind on security patches.
An expired extension licence stopped Composer from upgrading, and 2.4.9 needed OpenSearch in place of Elasticsearch.
02
What we found
A third-party extension whose licence had run out, so Composer couldn't resolve the upgrade.
Elasticsearch 7, which 2.4.9 no longer supports.
Module code that broke on PHP 8.4 because of removed functions, dynamic properties and stricter types.
One store view on en_GB while the rest used en_US. A normal static deploy would have left that store with no CSS.
03
What we did
We copied production to staging and did the upgrade there: Magento 2.4.9, PHP 8.2 to 8.4 and OpenSearch 2.19. Broken module code was fixed by hand.
We wrote down every catch before release, including the en_GB store view that would have gone out unstyled.
The tested code went live in a planned quiet-hours release. Live settings and data weren't touched, and we could have rolled back at any point.
04
Result
Running on 2.4.9 and neither wholesale nor retail customers noticed a thing. We checked home, category and product pages in all four languages in a real browser, with no console errors.
Customer orders came in as normal straight after the release.
The store is on a supported version, up to date on patches, and ready for new features.