There is a particular feeling that comes with running an online store on a big platform. Every so often a new version lands, and you know that at some point you are going to have to move onto it. Not because anything is broken, but because staying on the old one slowly stops being safe. Security fixes dry up. Plugins stop being supported. The clock just keeps ticking.
For years that upgrade was the job I quietly dreaded. I made a string of videos about it on my old Magento channel, the kind with titles like "watch this before you upgrade", because I knew how many people were sat there with the same knot in their stomach. I want to walk through what that used to feel like, including the time it went badly wrong, and then how I do it now so that the dread has more or less gone.
How I used to do it
An upgrade was never one button. It was a project. First you plan it, because you are about to change the engine of a live shop and you do not get to switch it off while you work. You take a copy of the site locally, never on the live server, and you start the move there. A jump like 2.4.3 up to 2.4.6 means the platform deletes and rewrites about a thousand files, swaps the PHP version underneath you, and pulls in a stack of new dependencies all at once.
Then things break. Every time. The errors almost always came from the same place: old plugins that had not kept up. A checkout add-on, a logging library that no longer matched, a WordPress bridge built for an older version. So you sit there working through them one by one. Switch a module off, note it on a pad, run the upgrade again. Wait. Hit the next error. Switch that off, note it down, run it again. Clear the caches, rebuild the code, redeploy the static content, and watch for the deploy to fall over so you can do it again. An hour of this is normal. The whole time the message I kept repeating to people was the same: keep your upgrades tight, do them often, because the longer you leave it the more painful the day becomes.
I recorded a lot of these as they happened, warts and all, so people could see what the process actually looks like rather than a tidy demo. I have left the original video below.
The upgrade that went very wrong
One of my old upgrade videos, recorded live as it happened. This is the one where it did not go to plan, which is exactly why I am showing it to you.
I am not going to pretend every one of these went smoothly, because one of them really did not. I started filming partway through an upgrade and hit an error with a dependency that should have been sorted out years earlier. One fix caused another problem. I ended up wiping the whole vendor folder, deleting the lock file, manually editing packages by hand, and rebuilding from scratch to get it back. At one point I genuinely was not sure the store would build again. I said on camera that I had probably made a mess further up the chain and should have watched my own advice.
I am telling you that on purpose. The whole reason those videos worked is that I owned the bad days as well as the good ones. If a developer tells you upgrades are always fine, they have either not done many or they are not being straight with you. I have been burned by one, in production, and the honest version is the one worth trusting. That experience is a big part of why I do things differently now.
How I do it now
The thing that made Magento upgrades so scary was that everything was one giant lump. The shop window, the stockroom, the checkout, the admin, the plugins, all welded together into a single monolith that had to move forward in lockstep. Touch one part and you risk the lot. So the upgrade was all or nothing, and it had to happen on a day you scheduled and braced for.
A headless setup pulls those pieces apart. The site people actually load is a fast, prerendered front end. The content and the store data sit in a separate system behind an API. The payments run through Stripe. Each piece does one job, and each piece updates on its own. There is no single monolith that has to be upgraded all at once, so there is no annual day where the whole business holds its breath.
In practice the updates happen quietly, in the background, in small pieces. A dependency gets a security patch and it goes in without anyone needing to clear their diary. The front end gets rebuilt and redeployed without the store data being involved. Nothing has to move in lockstep with anything else, so nothing has to break together either.
What changed, and why it matters to you
The honest summary is that the upgrade stopped being an event. With Magento I was planning a project, warning people, testing for days, and still bracing for something to break, sometimes in production. With a headless build the pieces update independently and quietly, so there is no single scary version jump that the whole business depends on.
For a business owner that is the bit that matters. Your site does not need a nerve-wracking overhaul every year just to stay secure and current. You are not held hostage to one big upgrade day where, if it goes wrong, your shop is down and you are losing sales while someone untangles it. The security fixes and the platform changes happen in the background, in small steps, instead of being saved up into one frightening leap.
If you sell online and you want this without running any of it yourself, that is what HD Commerce is for. It is a managed subscription. We build your store headless from the start and we keep it current for you, the quiet background updates included, so you never have to schedule a dreaded upgrade day or wonder whether your platform is falling behind. Keeping it up to date is our job, not yours.
Originally published as a series of videos between 2021 and 2023, rewritten here.