Magento 2 upgrades,
without the drama.

Every Magento 2 release has an end-of-support date, and once your version passes it, Adobe stops shipping security patches for it. That is the real cost of running behind: not missing features, but unpatched vulnerabilities on a platform that processes card payments. Add PHP versions reaching end-of-life underneath you, extensions that quietly stop supporting your release, and PCI assessors who ask harder questions every year — and an upgrade stops being housekeeping and becomes risk management. I upgrade Magento 2 stores for a living, from a single overdue patch release to multi-version jumps on heavily customised builds.

• 01Fixed or capped price after a short compatibility audit — no open-ended day rates
• 02Security patches, core upgrade and PHP version jump handled together
• 03Every extension and custom module tested against the target release
• 04Rehearsed cut-over on staging, with a rollback plan that has been tested

Why upgrade now

Adobe publishes a support window for every Magento 2 release, and when your version leaves that window the security patches stop — quietly. Meanwhile the PHP version underneath your store has its own end-of-life clock, hosts and payment providers tighten their compliance requirements, and extension vendors drop support for old releases one changelog at a time. Stores that defer upgrades do not save money; they accumulate a bigger, riskier jump plus months of unpatched exposure. Upgrading on your schedule, while the store is healthy, is always cheaper than upgrading after a security incident or a failed PCI scan forces your hand. I maintain a live page tracking the latest Magento version and support dates if you want to check where your release stands today.

The upgrade process

Every upgrade runs the same disciplined sequence, whether it is one patch release or a multi-version jump. Nothing touches production until it has worked on staging.

• 01Compatibility audit — a fixed-price review of your current version, PHP, extensions, custom modules and integrations. You get a written upgrade plan with a real number attached.
• 02Compatibility matrix — every extension and custom module mapped against the target release: compatible, needs an update, needs a patch, or should be retired.
• 03Upgrade on staging — core upgrade, PHP version jump and database schema updates run on an exact copy of production, not on your live store.
• 04Fix and verify — theme breakages, deprecated code paths and extension conflicts resolved; checkout, payments, shipping and integrations regression-tested end to end.
• 05Cut-over — a timed deployment window with before/after benchmarks and a rollback plan that has actually been rehearsed, not just written down.
• 06Aftercare — thirty days of post-upgrade support and handover notes, so the next patch release is routine instead of a project.

What the upgrade includes

• 01Magento core upgraded to the latest supported release, security patches applied
• 02PHP, Composer dependency and search-engine version jumps handled together
• 03Extension compatibility work — updates, patches and replacements where vendors have lapsed
• 04Custom module and theme fixes for deprecated or removed core code
• 05Full regression pass across checkout, payments, shipping, emails and admin
• 06Performance benchmarked before and after — an upgrade should never make the store slower

Security patches vs full upgrades

Not every gap needs a version jump. If you are on a supported release and simply behind on Magento security patches, a patch-only engagement gets you current quickly and cheaply — and when Adobe publishes an urgent security bulletin, that speed matters. But patches only exist for supported versions: once your release leaves Adobe's support window, patching is no longer an option and a proper upgrade is the only way back to a defensible security posture. The compatibility audit tells you honestly which situation you are in, and quotes the smaller job when the smaller job is enough.

Stuck several releases behind?

Plenty of the stores I upgrade have not been touched in years — the agency moved on, the in-house developer left, and each skipped release made the next one look scarier. Multi-version jumps are absolutely doable; they just need more care: intermediate upgrade steps where the data demands it, a harder look at abandoned extensions, and more rehearsal time on staging. If the store is also unstable or half-broken, that is rescue territory — I do that too, and the audit will say so plainly rather than pretending an upgrade alone will fix it.

Still on Magento 1?

This page covers Magento 2 version upgrades. If you are still on Magento 1, that is a platform migration rather than an upgrade — a different project with its own process, covered on my Magento 1 to Magento 2 migration page. The audit works the same way: a fixed price, a real plan, and an honest read on whether Magento 2 or another platform is the right destination.