Is the OpenCart 4 upgrade finally worth doing? Shop owners have been asking me this since version 4.0 appeared at the end of 2022 – and for the first couple of years my answer was a firm “not yet”. The early 4.0 releases were rough, the extension marketplace was a ghost town, and the popular themes only existed for 3.x. Anyone who waited made the right call. In 2026 the picture has genuinely changed: current 4.x releases are stable, the ecosystem has filled in, and at the same time the ground under OpenCart 3 is getting thinner with every PHP version your host retires. I build and maintain shops on both branches, and I develop OpenCart modules myself – so here is my honest assessment: where 4.x really stands, what happens to your extensions and theme, and when the switch pays off.
Where OpenCart 4 actually stands in 2026
Technically, OpenCart 4 is the modernisation the platform needed: PHP 8 throughout, a cleaner namespaced architecture, Twig templating, a Bootstrap 5 admin and a reworked event system for extensions. The modification system was rebuilt from the ground up – which means many of the old OCMOD tweaks that quietly ran 3.x shops for years will not survive the move without rework. That rework, not the core software, is where most of the migration effort hides.
I actively talked clients out of the early 4.0 releases: too many regressions, too few compatible extensions. Today’s 4.x versions are a different animal – stable in daily operation, noticeably snappier in the admin, and backed by a marketplace where the categories that matter (payment, shipping, SEO, filtering) are now reasonably stocked. Meanwhile OpenCart 3 is in de-facto maintenance mode: no new features, rare releases, and all development attention on the 4.x branch.
What changes in your day-to-day admin work
Here is the good news for you as a shop owner: the daily routine changes far less than the technical list suggests. Product editing, order processing, categories and coupons follow the same logic as on 3.x – anyone who could operate the old admin will feel at home in the new one after an afternoon. What you do notice: the backend is properly usable on a phone, noticeably faster to work in, and a few long-missed conveniences in product management finally exist. So the learning curve is no reason to fear the switch – the real effort sits underneath, in the technology, not in the user interface.
The real deadline, though, is not set by OpenCart – it is set by your hosting company. Hosts across the DACH region are retiring old PHP versions on a schedule. A well-maintained 3.0.4.x shop still runs acceptably on current PHP 8, but older 3.x installations and many of their extensions throw errors the moment you move to PHP 8.2 or 8.3. And if your shop is still pinned to PHP 7.4, you no longer have an OpenCart question – you have a security problem.
The crux: extensions and themes
OpenCart 4 is not backwards compatible. Not a single 3.x extension runs unchanged on 4.x – the architectures are too different. For your migration this means every extension needs one of three things: a 4.x version from the same developer, a replacement from another one, or custom development. The same applies to your theme. The popular 3.x themes – Journal above all, which runs on what feels like every second OpenCart shop – cannot simply come along; you will need the theme’s 4.x edition or a new theme entirely, including reconfiguring years of accumulated settings.
Developing OpenCart modules myself, I know first-hand what a clean port costs in effort – we built our own Buntweb Filter product filter from scratch to work without core hacks and to integrate cleanly with the shop’s theme. That is exactly what to look for when buying any extension: modules that patch core files are a liability at every update, and doubly so on 4.x.
Audit your extension list in one hour
- Export the full list of installed extensions and modules – including the disabled ones.
- Sort them into three buckets: business-critical (payment, shipping, ERP integration), useful, and legacy nobody actually uses. In most shops a third of the list lands in the last bucket.
- For every critical extension, check the marketplace or the developer’s site for a 4.x version – and look at the date of the last update rather than the star rating; it tells you far more about whether the developer is still around.
- Budget replacements or custom work for everything without a 4.x version – including new licences, because 4.x editions are almost never free upgrades.
Migrating from 3.x to 4: not an update – a relocation
Let me correct the biggest expectation first: there is no reliable one-click upgrade path from 3.x to 4.x. Every serious migration I have done runs as a rebuild: a fresh OpenCart 4 installation on staging, data carried over (products, categories, customers, order history, SEO URLs), a new theme, new extensions, then thorough testing. Shop migrations like this are core web development work for me, and the effort is entirely plannable if you calculate it honestly: a manageable shop without exotic customisations relocates in three to five working days; a shop with heavy customisation, ERP connections and years of accumulated OCMODs can take several weeks.
Plan a data cutover, too: between exporting the data and switching the new shop live, orders keep arriving in the old one. In practice you solve this with a second, incremental sync shortly before the switchover – or, for smaller shops, an announced maintenance window of a few hours. Skip this step and you will be hunting for the weekend’s orders after the move.
Two things decide between a smooth switch and a painful one. First, SEO: the URL structure must survive intact or be redirected cleanly via 301s – otherwise you burn years of rankings in a week. Second, order history: your customers expect their accounts and past orders to still exist after the move, so that belongs in the test plan alongside the homepage. As for budget, the mechanics are the same as with any development project – I broke down how such project costs are actually calculated elsewhere; with shop migrations, extension licences and testing time are the two extra line items.
Wait or switch? A decision guide
There is no universal answer, but the patterns are clear. This is how I decide it with my clients:
| Your situation | My recommendation |
|---|---|
| Shop runs stably on 3.0.4.x with current PHP 8, no issues | No acute pressure – schedule the migration within the next 12–18 months, don’t rush it |
| Your host has announced the retirement of your PHP version | Act now: bring 3.x fully up to date first, and put the 4.x migration on the calendar in parallel |
| You are building a new shop | Start on OpenCart 4.x, no exceptions – launching on 3.x in 2026 means migrating twice |
| Many custom OCMODs and niche extensions | Treat the migration as a proper project with a realistic budget; run the extension audit first |
| A redesign or relaunch is planned anyway | Combine the two – build the new theme once, on 4.x, instead of twice |
The pre-upgrade checklist
- Full backup of database and files – stored off-server and restore-tested, not just created.
- Extension inventory with a 4.x compatibility status for every single module.
- Theme decision made: the 4.x edition of your current theme, a new theme, or custom development.
- Staging environment running the same PHP version as future production.
- Migration plan for products, customers, orders and SEO URLs – including a 301 redirect map.
- Test plan covering checkout with every payment method, shipping calculation, customer accounts, search and filtering, and all shop languages.
- A frozen switchover window – outside your peak season, with a rollback path to the old shop.
- Post-launch monitoring: rankings, 404 errors and incoming orders checked daily for the first two weeks.
Planning an OpenCart project? Read more about my OpenCart development services — shops, custom modules and migrations.
Conclusion
In 2026, OpenCart 4 is no longer a gamble – the software is mature, the ecosystem is usable, and the 3.x branch is visibly winding down. But the upgrade is not a button press; it is a relocation project whose cost hangs almost entirely on your extensions and theme. If you run stably on 3.0.4.x, you may still wait – deliberately, with a date in the calendar. If you are starting fresh, facing PHP pressure from your host, or planning a relaunch anyway, take the step now: with an inventory, a staging environment and an honest budget instead of a leap of faith.
Not sure where your shop stands? Send me your shop URL and I will tell you concretely what a migration means in your case – which extensions are critical, what needs replacing and what it realistically costs. Get in touch via the contact form and we will go through the details together.
