Why it can’t be done by following instructions — and what to do instead
The first question a store owner asks: “How do I update OpenCart myself?” The short answer is: almost no way. If the site has a custom theme and at least a couple of modules, and almost every store does, updating by the instructions will most likely break something, from the layout to checkout. In practice this work is done by a programmer by hand, not by a “download, upload, done” checklist.
What an OpenCart update consists of
An update affects not only the engine itself but several layers at once, and each one needs separate attention:
| What is updated | What it means in practice |
|---|---|
| Core | The system/, catalog/ and admin/ files are replaced with new ones, but the configuration and the places with custom edits have to be preserved manually. |
| Theme | If the theme was built for a specific store rather than being a standard one, it is ported and adapted anew, file by file. When moving from 2.x to 3.x the template engine also changes, from .tpl to Twig, so the theme is rewritten, not copied. |
| Modules and extensions | Each module is checked for compatibility with the new core version separately. There is no general way to do it all at once. |
| Database | The table structure differs between versions. Changes are made by hand, taking into account what has already accumulated in the specific store: orders, products, settings. |
Updating OpenCart 3.x: why it’s not “download and upload”
Technically, the core of OpenCart 3.x can be replaced with the files of a new version. But in a real store, that is only where the questions begin. The theme breaks if it wasn’t built strictly to the engine’s standards. Modules based on OCMOD conflict with the changed core files. And the database structure has to be carefully put in order by hand, without touching the orders and settings already accumulated in the store. This is a programmer’s manual work, not a single operation that can be done from a template.
If the move is from an older OpenCart 2.x, one more barrier appears: the change of the template engine. In 2.x, themes were written in .tpl (ordinary files with PHP inserts), while in 3.x the engine switched to Twig, a separate template language with a different syntax. A theme written for 2.x simply won’t open in 3.x: it isn’t ported by copying but rewritten from scratch for Twig.
Updating OpenCart 4.x: essentially a migration, not an update
OpenCart 4.x is built on a different architecture: the template system has changed, and OCMOD, which kept modules compatible in 3.x, simply doesn’t exist in 4.x. If your store is currently on 3.x and you need to move to 4.x, this is not a file update but a migration of the store to a new platform: the theme is built anew, modules are looked up in a 4.x version or reworked, and the data is transferred by hand, step by step.
Why you shouldn’t update it yourself
- The theme breaks: non-standard edits in the template almost never survive the replacement of core files.
- Modules crash with errors: a payment or delivery module may simply stop working.
- The database requires manual decisions: there are no two identical stores, so the structure is adjusted for the specific case, not from a general template.
- A mistake is expensive: if something breaks on a live site, it means stopped sales.
What I do when I take on an update
- I deploy a copy of the store, files and database, on a test server, so that nothing on the live site is touched until the work is finished.
- I update the core and manually put the database structure in order, checking every affected section.
- I port and adapt the theme to the new version, rebuilding it from scratch if needed.
- I go through every installed module: check compatibility, and update or rework the code by hand.
- I test the key scenarios: checkout, payment, delivery, the admin panel, and the preservation of SEO URLs.
- I switch the live site to the updated version only when the test copy has run without errors.
What I need from you to get started
- Access: to the hosting (FTP or file manager), to the database, and a login to the admin panel.
- Where you are moving to: within one version or from 3.x to 4.x. The scope of work depends on it.
💡 My principle: never touch the live store directly. I always start with a test copy and switch the site only after everything has been checked there, from the theme to payment.
Frequently asked questions
Can I update OpenCart myself?
If the store uses a standard theme and has no modules, you have a chance. But most stores have some customization, and in that case a DIY update usually ends with a broken theme or a disabled module. It’s simpler and faster to contact me and get an estimate for your specific case.
How do I update OpenCart from 3 to 4?
This is not a file update but a migration of the store to a new architecture: the theme, modules and part of the data are transferred by hand. I estimate the scope of such work individually, after I’ve looked at what is installed on the site.
What will happen to the theme and modules after the update?
Without preparation, most likely they will stop working correctly. Porting and adapting the theme and modules is part of the work itself, not a separate stage “afterwards”.
Does the database need to be updated separately?
Yes, and it’s manual work: I go through the table structure and carry over the changes, taking into account what has already accumulated in your store: orders, products, settings.
How often should OpenCart be updated?
Updates that fix vulnerabilities, as soon as possible, especially if the store accepts payments. A move to a new version, for example from 3.x to 4.x, is a separate project that should be planned in advance rather than done at the last moment.
In short: you can’t update OpenCart “by the instructions”, except on a bare engine with no theme and no modules, which is almost never the case. If you have an OpenCart store and an update is due, write to me: I’ll look at what is installed and tell you how much time and money it will take.
