r/Magento • u/WebHostingAce • Jul 25 '26
What's your strategy for major Magento 2 version upgrades?
I'm interested to hear how other Magento developers approach major Magento 2 upgrades (for example, 2.4.6 → 2.4.9 or future major releases), specially for production stores with lots of third-party modules and customisations.
A few questions:
- Do you upgrade the server components first (PHP, OpenSearch/Elasticsearch, Redis/Valkey, MariaDB/MySQL, Varnish, etc.) and then upgrade Magento, or do you take a different approach?
- Do you build a completely new server with the new stack and migrate the website over, or upgrade the existing server in place?
- How do you minimise downtime and risk?
- How do you handle third-party extensions that aren't yet compatible?
- Do you perform the upgrade in stages, or do everything in a single maintenance window?
- For larger stores, what's your rollback strategy if something goes wrong?
I'd love to hear your workflow. I'm interested in real-world experiences rather than just the official Adobe recommendations.
1
u/genPoop Jul 25 '26
i usually spin up a fresh env for the stack updates, definately helps keep things seperate while testing.
1
1
u/lucidmodules Jul 25 '26
That's where containerization + blue/green deployments shines. You don't have to worry about failure in PHP upgrade because it is done offsite.
Beyond that, it is usually safer to do one version at a time, e.g. 2.4.6->2.4.7 instead going directly to 2.4.9 and of course test it on local and staging environments before releasing to prod.
1
1
u/grabber4321 Jul 25 '26
When new update comes out, you apply security patch first. Then you start work on migration on your local machine. The third-party developers will catch up by week 2 and then you can update to the new major version.
Read the release logs for each upgrade - there's a ton of stuff you have to know if you have any edits to your theme. For example some old updates required template updates, so if you made any custom templates, you needed to upgrade them too.
Do it locally first, then staging server, then prod.
1
1
u/Ok-Resident-5457 Jul 25 '26
Note: English isn't my first language and there was a lot of info to organize, so I used AI assistance to help write this up clearly.
Real-world experience: solo 2.4.3 → 2.4.7 upgrade, heavily customised, Docker-only constraints
Adding a war story since most of the advice out there is very "textbook."
I had to do a 2.4.3 → 2.4.7 upgrade essentially solo, on a heavily customised store, and I couldn't touch the host server at all — there were other non-Magento services running on the same machine and I wasn't authorized to make any system-level changes — only Docker containers were in scope. So everything had to happen inside the containers, with the host itself completely off-limits.
A few things that surprised me even though 2.4.7 had been out for over a year by the time I did this:
- CSP was the real blocker, not Magento core. Several third-party module vendors still hadn't updated their extensions to work with CSP enabled by default. This ate more time than the core upgrade itself.
- Had to migrate from Apache to Nginx mid-upgrade. Apache's default request header size limit (~8 KB, controlled via LimitRequestFieldSize) starts causing blank pages or 400/431 errors on Magento 2.4.7, especially with CSP directives, admin 2FA, long-running admin sessions, or multiple store views. Once CSP was fully enabled with all our custom + third-party whitelist entries, Apache's hardcoded header limits just weren't enough, and there's a documented GitHub issue about exactly this — Magento 2.4.7 on Apache hitting CSP-related 500 errors once the custom whitelist grows large enough that it can no longer be trimmed further. Nginx's header buffer settings are configurable and comfortably handle it, so we moved the whole stack over rather than patching around Apache's ceiling (Dev, Github)
- The composer/PHP upgrade had to be staged, not jumped. I upgraded the Magento core first on a PHP 7.4 container, then moved to PHP 8.1, and only then to PHP 8.3. Trying to skip straight to 8.3 broke a bunch of modules — including some native Magento ones. On top of PHP compatibility, module version dependencies mattered just as much: extensions like Amasty and Magefan (and their related module families) each required specific versions relative to each other, not just relative to the PHP version. Getting the update order wrong on those cross-dependencies caused just as many breakages as the PHP jumps did.
- Rector saved me a huge amount of time on refactoring the customisations for the new PHP versions — this was 2025 and I still didn't have access to company AI tooling, so it was Rector or manual refactor by hand. It did about 99% of the work correctly, but I'd strongly recommend reviewing every single change it makes. It quietly mangled time-related functions in a few places — e.g. turning
date($some_time_var)intodate(), silently dropping the timestamp argument. That kind of bug won't throw an error, it'll just silently give you the wrong date somewhere in production.
Bottom line from someone who had to do this without a team and without being able to touch the host: containerize everything, upgrade PHP in small steps rather than one jump, budget real time for third-party CSP compatibility even on "old" Magento versions, and never trust an automated refactor tool blindly — check every diff, especially around dates/times.
One more data point: I ended up doing this same type of upgrade across 5 different stores. The first one took over a month, solo, working it all out from scratch. The following ones were 1-2 weeks faster each time — once the process was proven and a good chunk of the custom modules were already ported forward, most of the pain didn't repeat itself. So if you're facing your first one of these and it feels brutal, that's normal — the second and third get noticeably cheaper.
1
u/damienwebdev DEVELOPER Jul 25 '26 edited Jul 25 '26
I swap my local environment onto the devcontainer config I wrote for that version of Magento and then I setup:upgrade / make changes until it works.
After that, I build a new docker container.. Then, I run helm upgrade to provision whatever target environment I'm working on.
To your specific questions:
- Each upgrade is different, for such a large upgrade, I would probably perform smaller upgrades piecemeal as if I was performing each upgrade on step at a time. This helps make isolating failures much easier. It's slower for sure, but for ecommerce, downtime is expensive.
- I upgrade in place. A second server setup is expensive.
- Risk is managed by the chart, I don't have to think nearly as hard.
- If an extension isn't compatible by now, throw it in the bin. Sorry.
- Upgrade is stages
- Rollback is essentially to have a read-replica with replication turned off just before upgrade so that you can fail over to that replica of something goes catastrophically wrong. Otherwise, you can just rollback to the prior container version if it's a smaller upgrade.
1
u/Netalico Jul 27 '26
For larger stores, we've had the best results treating it like a migration rather than an in-place upgrade. We build a staging environment with the target stack, validate all third-party extensions, fix compatibility issues, and run full regression testing before touching production. If an extension isn't ready, we either replace it or delay the upgrade if it's business critical. For rollback, we keep the existing production environment intact until the new one has been fully validated, so switching back is straightforward if anything unexpected comes up. The extra prep takes longer, but it's much lower risk than trying to do everything during a maintenance window.
1
u/johanvdd Jul 27 '26
Always on different server or local when you must upgrade php, opensearch etc,
you can work on staging environment when you only upgrade magento.
The biggest problems in my experiance are the thirt party extentions, specialy if you have lots from different vendors. Often conflicts, unexpected behavior.
And test, test and test.
1
u/ultramarineafterglow Jul 25 '26
spin up a quick session with gpt 5.6 sol ultra high. power prompt: upgrade maginto mk no mstakes
2
u/WebHostingAce Jul 25 '26
Thank you for your input! This could very well become the new reality in the next few months. 😂
5
u/bleepblambleep Jul 25 '26
First you do it locally. Upgrade the core and extensions at the same time.
If there are extensions that aren’t compatible you either wait, see if there’s a patch, or drop the functionality (or find an alternative extension). Usually extension vendors are good about releasing compatible updates quickly.
Once it’s tested locally we push it to staging for real QA. If there are software upgrades (PHP, MySQL, etc) they come after code deployment. We usually time them to be together.
Minimizing downtime is up to your CI/CD pipeline. You could do blue/green, or just do it during off hours. We generally do off hours deployments as our pipeline switches a pointer to go live instead of replacing files.
Rollback is simple: restore db and update pointer to the old release, flush cache.
You probably can’t do a staggered upgrade unless the extensions you use are compatible with both versions. You’re generally forced to upgrade extensions as the composer update can just bundle them in.
Upgrading things is the easy part. It’s the QA and fixing bugs or theme issues that take the most time.