Magento upgrades

Security patches stop, and that is the part that matters. Your store keeps trading, so the risk feels theoretical right up until it is not, an unpatched commerce platform holding card and customer data is a compliance problem as much as a technical one. The secondary cost is compounding: every month you wait, the extension and PHP version gap widens and the eventual upgrade gets more expensive.

A single minor version on a clean build can be weeks. A major version jump on a store carrying years of custom modules is a project, not a task, and the variable is almost never Magento itself. It is the extensions, the theme overrides and the custom code written against APIs that have since changed. An audit tells you which of those you are dealing with before anyone commits to a date.

Upgrade when the platform still fits the business and the cost is the version gap. Replatform when you are paying to maintain capability you do not use, or when the operational overhead of running it is the actual complaint. The mistake is treating an expensive upgrade quote as automatic evidence for replatforming, a migration is usually the larger project, and it carries risks an upgrade does not.

Some have compatible versions, some are abandoned, and some turn out to be doing something a stock feature now covers. The audit that matters most is not technical: it is which extensions anyone still uses. Upgrades get expensive carrying modules nobody has opened in three years, and the cheapest work in the project is often deletion.

Yes, most of the upgrades we do are on platforms we inherited. We get it running locally first, because how long that takes is itself the most informative measure of how the build has been maintained. Then we assess what is safe to change before proposing a plan.

Reduce custom code that duplicates stock behaviour, keep extensions to ones that are maintained, and get test coverage around checkout and pricing so changes can be verified rather than hoped for. Most of what makes an upgrade expensive is accumulated decisions, and the interval between upgrades is when it accumulates.

Yes. Upgrades run on a parallel environment with production untouched until cutover, which is also the only way to test honestly. A code freeze helps but is rarely mandatory, where a business genuinely cannot pause, the work is sequenced around it rather than the other way round.

Our head office is in Sydney and we work with clients across Australia (Melbourne, Brisbane, Perth, Adelaide and regional NSW included) as well as in New Zealand, where the duty free stores across the major airports have run on a platform we build and support since 2021. Delivery has been remote-first for years, so a project runs the same way whether you are ten minutes away or across the Tasman: scheduled calls, a shared board you can see at any time, and one named point of contact. We are happy to meet in person in Sydney.