Yuvraj Raulji | Magento upgrade
Most Magento platforms fall behind for the same reason: the last upgrade hurt, so the next one gets deferred, and every deferral makes the one after it larger. The way out is not a braver upgrade. It is a smaller one, run against a rehearsed path, with the extension debt dealt with as its own piece of work.
Direct answer
A Magento 2 upgrade moves a store from one Magento version to a newer one, including the move from Magento 1 to Magento 2, which is really a rebuild wearing the word upgrade. The core version change is usually the straightforward part. The work is extension compatibility, custom code that reached into internals it should not have, the regression surface across checkout and pricing, and running the whole thing on a rehearsal environment first so the production window is a repeat rather than an experiment.
Best suited for
- A platform two or more minor versions behind
- Security patches that cannot be applied cleanly
- A PHP version approaching end of life
- Magento 1 stores still trading
What this page is not
This page is about staying on Magento and changing version. Arriving on Magento from Shopify, WooCommerce or a legacy system is a different job, with catalogue remodelling and URL preservation at the centre of it.
The problem
The symptom as the person carrying it would describe it, and the part that shows up in the numbers rather than in the ticket queue.
Security patches will not apply cleanly
What it costs
The platform is carrying known vulnerabilities because the patch conflicts with a customisation nobody wants to touch. This is the point at which deferring stops being a scheduling choice and becomes a risk decision.
Extensions block the version the business needs
What it costs
Three extensions have no compatible release, one vendor has disappeared, and the upgrade is held hostage by code that was bought to save time. Every version deferred makes the eventual replacement work larger.
The last upgrade broke checkout
What it costs
Confidence is gone, so the next upgrade is postponed indefinitely and the platform ages into a rewrite. The cause is almost always an untested regression surface rather than the upgrade itself.
PHP is going out of support
What it costs
The hosting stack forces the timetable, and the deadline arrives whether the extension work is done or not. Started early this is a plan; started late it is an outage with a date on it.
Approach
In this order, and the order is the opinion. Most of what goes wrong on this kind of engagement is a step taken before the one it depends on.
Inventory what is actually installed
Every extension, every core override, every patch applied by hand. On an inherited platform this list is routinely longer than the team expects, and it is what determines the shape of the work.
Decide extension by extension
Upgrade, replace, or remove because nothing uses it any more. Removal is the outcome people forget to consider, and on an ageing platform it is often the largest single reduction in upgrade cost.
Rehearse on production data
The upgrade runs end to end on a copy of the real catalogue and the real order volume. Anything that only fails at scale fails here instead of on the night.
Test the regression surface
Checkout, pricing rules, tax, shipping, approvals and every integration boundary. On B2B platforms the pricing and approval paths matter more than the storefront and get tested first.
Write the rollback before the window
What gets reverted, by whom, and inside what time. A rollback plan authored during an incident is not a plan, and its absence is what turns a bad upgrade into a bad week.
Scope
Version moves
Magento 2.x to currentMagento 1 to Magento 2Adobe Commerce upgradesPHP and stack upgrades
Compatibility
Extension auditCore override reviewCustom module remediationTheme compatibility
Assurance
Rehearsal environmentCheckout and pricing regressionIntegration verificationWritten rollback plan
After
Security patch cadenceUpgrade scheduleDeployment pipelineHandover to the internal team
Proof
A multi-store Magento 2 catalogue, which is the kind of platform where upgrade cost is decided by the extension list.
Magento 2 · Marketplace
Multi-category marketplace
A scalable Magento 2 platform powering a wide multi-category retail catalogue.
Magento 2Multi-categoryScale
Outcome
30%
Reduction in development cycle time
Achieved through structured workflows and approval processes rather than through faster typing. The same structure is what turns upgrading from an event into a routine, because most of the cost of an upgrade is coordination.
Where this came from
From the verified delivery record, while leading Magento 2 platform delivery.
An upgrade path that stays open
The real outcome of the first upgrade is that the second one is small. That comes from removing the extensions nothing uses, keeping customisation out of core internals, and putting a patch cadence in place before the next deferral starts.
There is no published figure here for upgrade duration or defect rate, because those depend almost entirely on what the platform is carrying, and a number quoted before reading the extension list would be a guess.
Questions
- How much does a Magento 2 upgrade cost?
- The version change is a small and fairly predictable part of it. The cost is the extension list, the custom code that reached into core internals, and the size of the regression surface, so an honest estimate follows an inventory rather than preceding one. A platform with few extensions and clean customisation upgrades for a fraction of one that has neither.
- Is Magento 1 to Magento 2 an upgrade or a rebuild?
- Technically it is a rebuild. The data migrates, the extensions do not, the theme does not, and most custom modules do not. It is worth planning it as a Magento 2 build that inherits data, because planning it as an upgrade is how the timeline gets set at half of what it needs.
- Can we skip several versions at once?
- Usually yes, and often it is the right call, because the regression testing is the expensive part and it is paid for once rather than per hop. What decides it is the extension and PHP compatibility across the range, which comes out of the inventory step.
- How often should Magento be upgraded?
- Security patches on release, and version upgrades on a schedule the business sets deliberately rather than when something forces it. The cadence matters more than the frequency: platforms that upgrade regularly find each one small, and platforms that defer find each one larger than the last.
- What happens if the upgrade goes wrong on the night?
- It gets rolled back, using a plan written before the window and rehearsed with everything else. That is why the rehearsal environment carries production-scale data: an upgrade that has only ever run on a small data set has not been tested, it has been demonstrated.
Next step
Describe what is actually in front of you and we will work out whether this is the right piece of work before anyone scopes it. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.