OpenCart Update: Upgrade to the latest version without losing your store
Updating the version of OpenCart between major branches is not a button in the admin: the structure of the base, the system of extensions and the system of templates are changed, so the old modules and the old theme simply do not start on the new platform. This makes the question "to update or not" actually sound different: what will happen to my modules, theme and page urls. We respond to it before the work begins - we disassemble the assembly piece by piece, transfer the data to the test site and compare the number of products, orders and customers before and after. The combat site is trading all this time.
15–45 working days; the switching itself is one evening
after a free audit
Price
30
Guarantee
days after project sign-off
15–45
Term of works
working days; the switching itself is one evening
a test site, a copy of a combat one; the store does not stop
Where the update takes place
reconciliation of products, categories, orders, customers and reviews before and after
Main check
3-5
Assembly audit
working days, free of charge, the document remains with you
kernel edits and the fate of each module, not the directory size
What drives the estimate
payment by stages, warranty period of 30 calendar days
Conditions
Process steps
Transparent stages with approval at every step
Total duration:15–45 days
1
Assembly audit
3-5 working days
We remove the current version, look for changes in the core by comparing it with a clean build, compile a list of modules with the fate of each, look at the theme and environment. The output is a document and two assessments: update the current store or compile a new one on the current version with data transfer.
2
Test site and first transfer
2-4 working days
We upload a copy on a separate domain, closed from indexing, install a new version of the platform, transfer the database and count the numbers for the first time. The first transfer almost always gives a discrepancy - this is where it becomes clear where there are anomalies in the data.
3
Core and modules
5-15 working days
The longest stage. We put versions of extensions under the new platform, select analogues, add our own code to why there is no replacement. Edits from the core move to modifiers — so that the next update does not start with the same archeology.
4
Theme for the new template system
4-10 working days
We transfer or reassemble the main, category, card, basket and checkout. We compare the combat site page by page: the goal is to make the difference visible only in the code, and not on the buyer's screen.
5
Acceptance on the test
3-5 working days
You click the store with your hands: order from the basket to the letter, payment, delivery, administration, export. At the same time, the final reconciliation of quantities and verification that the addresses of the pages coincide with the current ones is taking place.
6
Switching and 48 hours after
1 evening + 2 days of observation
The evening of the agreed day: freezing of changes, the last data transfer, switching, going through the checklist. The old assembly remains elevated under the rollback plan. We watch error logs, orders, scans and background tasks for two days.
Technologies & integrations
What we build on and what it connects to
Stack
OpenCart 4.x is a branch under development; honest limitation: part of the Ukrainian modules has not yet come under it
OpenCart 3.x — when a module critical to you exists only under it, this is a deliberate stop on the previous branch
PHP 8.x, MySQL / MariaDB current versions - without this, the new branch will not start
OCMOD modifiers instead of modifications in the platform files - so that the next update does not start with a search for changes
Git — so that at any moment it is visible what exactly has changed, and there is a place to roll back
Test site on a separate domain, closed from indexing
Before-and-after quantity reconciliation scripts—they, not gut feeling, confirm that the data is in place
Limitations of the stack: OCMOD does not cover everything - some changes cannot physically be carried out of the kernel, and we call such places in the document a separate list
Integrations
LiqPay
WayForPay
monobank
Nova Poshta
Ukrposhta
1C / BAS
XML feed to marketplaces
Google Tag Manager
GA4
Google Search Console
What's included
Complete list of work and what you get as a result
We set up the test site as an exact copy of the store: all work is done there, your site accepts orders all the time.
We transfer the data and compare the numbers - products, categories, orders, customers, reviews are counted before and after, the discrepancy should be zero.
We analyze each edit in the core: we reproduce the necessary business with a standard modifier, we refuse the rest in writing, not silently.
We go through the modules one by one - a version for a new platform, an analogue or our own code; you make a decision on each at the audit.
We assemble the theme under the new system of templates so that the buyer does not notice the substitutions: the same appearance, a different code underneath.
We save page addresses, and where this is technically impossible, we put 301 and show the full list before switching, not after.
We will run the entire buyer's journey on the test: catalog, filter, basket, checkout, payment, delivery, order letter.
We check the exchange with the accounting system and uploading to the sites — after changing the platform, it breaks most often.
We upload the version of the language and base on the server as part of the work: without this, the new branch will not start at all.
We switch to your window with a ready rollback plan; the old assembly remains in place until you accept the new one.
We keep the first 48 hours under supervision: errors, orders, indexing, background tasks.
Terms: payment by stages, warranty period of 30 calendar days after acceptance.
When this service isn't right
What's not included — so there are no surprises at delivery
Licenses for new versions of paid modules are purchased by you
Redesign: An update keeps the look, not changes it
A promise that an analogue will be found for modules removed from support
Catalog filling and content works
Hosting, domain, acquiring
Who it's for
Situations where this service delivers results
Scenario 1 of 4
Hosting has warned that it is removing the old version of the language
The most common reason and the worst time to start. In the stores we measure on OpenCart 3.x, we regularly see PHP 7.3.33, the unsupported version as of December 2021. As long as the provider keeps it, everything works; the day he turns it off, the store will give a blank page. Updating in quiet mode and updating twelve hours before an outage are different amounts of money and different amounts of risk.
We'll review your situation in a free audit
Scenario 2 of 4
You need a module that is no longer released for your version
Authors of extensions gradually stop supporting old branches: a new integration is released immediately under the current version, and under yours - "on request" or never. If you are convinced that the required payment or logistics module for your assembly does not exist, updating the platform becomes not hygiene, but a condition for a specific business task.
Scenario 3 of 4
The store was assembled a long time ago and managed directly in the platform files
Classic legacy: The function works but lives in a modified kernel file. Such edits do not move by themselves and are not visible from the admin panel - they are found by comparing them with a clean build. It is the number of these edits, not the number of goods, that stretches the deadline from the lower limit to the upper limit.
Scenario 4 of 4
You got the store together with the business
You don't know what's inside, who compiled it, or if there are any originators of the theme. In the watering shop we measured, we found in the chameleon theme four hidden links to a third-party domain before the body closure, with the display:none style and off-screen - the backlines of the template author, which the owner did not know about. An update is a good time to see these things and decide what to do about them.
Update the current store or build a new one on the current version
How this option differs from the alternative
New build with data migrationOur approach
What happens to edits in the kernelare not transferred at all: the required functions are re-formulated as requirementsdisassemble piece by piece and transfer to modifiers - for a long time, but the logic of the store is preserved
Modulesthe list is rearranged for the new platform — what is is listed, not what wasthe list remains the same, the versions change; holes are closed with analogues
Topicthe look can be made the same, but at this stage it is usually changed anywaywe transfer the appearance, including the little things that the buyer is used to
Page addressesare stored only if it is included in the task; otherwise a redirect map is requiredare stored, this is a condition of works
When it's cheaperan assembly with dozens of built-in modules and without theme originsthe build is close to clean, there are few edits, the modules have versions for the new branch
Free pre-upgrade build audit
Before updating, you need to know three things: what is non-standard, whether there is a replacement for each module in the new version, and how many changes have been made to the kernel. The audit responds precisely to them.
What we measure
Current version and how to install itWhat build is there and has it been updated before? Prefab assemblies with "already built-in" modules are much more difficult to update than clean ones.
Edits in the coreHow many platform files are changed directly. Each such modification will not move by itself: it must either be recreated by a modifier, or consciously abandoned.
List of modules and their fateFor each extension, whether there is a version for a new platform, whether there is an analogue, or whether the function will have to be written anew. This is the main multiplier of the estimate.
TemplateAre there origins of the theme and does it exist under the new version. The templating system changes between major versions, and third-party themes are often not ported.
Database status and data volumeThe number of products, orders and customers that must be moved without loss. These numbers are checked before and after - this is the main test of success.
EnvironmentLanguage and database version. In the stores we measure, we regularly see PHP 7.3.33 and frontends on ten-year-old libraries — for example, a build with jQuery 2.1.1 and the third version of the layout framework. The new version of the platform will require a more modern environment.
What you get
Build document: version, core edits, list of modules with the fate of each, theme status.
Evaluation in two scenarios: updating the current store versus building on a new version with data migration.
A list of functions that will have to be recreated, with a score for each.
Conversation for 30–40 minutes on the document.
Timeline: 3-5 working days
Why is it free
Because the fate of each module is the update estimate, and it can only be checked individually. The document is yours regardless of whether we update it or not.
What's next
After the audit — the amount and term by stages, the contract, the bill, the act. Sometimes it becomes clear from the list of modules that reassembling the store on a new version is cheaper than updating the old one; then we will show both numbers.
Short form: your contact and site URL
Did not find your case?
Describe how it works on your side — we will tell you whether “Update OpenCart version” fits and what it means in your situation. No brief and no call: one question, one answer.
Contract, act and 30-day warranty
Every project gets a written contract: scope, deadlines, amount, acceptance procedure. After delivery — act and invoice, then 30 calendar days of warranty.
Sole proprietor & bank transfer
The contractor is a registered sole proprietor. Payment by invoice with closing documents.
Rights & access — yours
Code, design and materials transfer to you after full payment. Domain, hosting, repository and analytics are registered to you.
Client portal instead of email chains
During the project you get access to a portal: contracts, invoices, acts and project status in one place.
European clients
Among our work — projects for Norway, Bulgaria, Moldova and Spain.
Verifiable numbers
Every case in the portfolio comes with a link to a live site and a technical measurement.
Audit first, then pricing
There is no price list on the site intentionally: the scope of the same work differs multiples between clients.
We say "no" when unsure
If the task isn't ours or the deadline is unrealistic — we tell you upfront.
What affects the price
Why two seemingly identical tasks are priced differently
Edits in the corePrime factor. Each modified file of the platform must be found, understood why it was edited, and decide whether to recreate it with a modifier or remove it. A shop without edits and a shop with two dozen edits have the same catalog and different deadlines at times.
The fate of each moduleAn extension with a ready version for a new platform is an hour of work. An extension without an analogue, the function of which has to be written anew, is a separate project within the update. Therefore, the estimate is calculated based on the list of modules, not the number of products.
Topic and availability of sourcesThere are sources and the topic exists under the new version - we transfer it. There are no sources or the author of the topic has disappeared - we reassemble the look under the new template system. This is the part where the range is the widest.
Data purityA catalog with duplicates, empty categories, and goods outside categories is more expensive to transfer: each anomaly must be analyzed, otherwise it will move along with everything else and spoil the inventory.
Server statusIf the version of the language and base can be raised on the current hosting, it is a few hours. If the ISP keeps the old build tight, the move to another environment is added to the upgrade.
Is it possible to freeze changes?While work is underway on the test site, each new batch of goods and each order on the battlefield is a difference between two copies. The agreement on the window of silence costs zero, and saves data transfer for nothing.
Cases
Tasks and results in numbers — all metrics measured by us
a store of automatic irrigation systems with a catalog of 300 items
Task
Capture the actual state of the build before talking about upgrades: what's inside, how much data, and what will have to be recreated by hand.
Solution
The catalog was enumerated by two independent methods — traversing the root categories by pagination and combining the output of an internal search for 18 different queries. Next, speed measurements for five repetitions, analysis of the page code and server headers.
Result
300 products in 40 categories at 4 levels of nesting, both methods yielded the same set of IDs - 0% discrepancy, and this figure becomes the control after migration. First response 235ms (median of 5 measurements), full HTML 262ms, main weight 143.6KB and 22.5KB in brotli. In the checkout, there are 6 delivery methods from 2 carriers and 3 payment methods — all this will have to be reproduced individually on the new version. Technical build: OpenCart 3.x with jQuery 2.1.1 and layout framework version 3, chameleon theme. Separately, we found 4 hidden links to a third-party domain in the topic before closing the body with the display:none style - when the topic is rebuilt, they do not move, and this is a rare case when an update removes the problem by itself.
online store of the official seller of garden tools
Task
Assess the technical condition of a store with a catalog of more than a thousand items — in particular, how urgently it is necessary to change the environment.
Solution
Speed and weight measurements, analysis of the site map for address uniqueness, verification of server headers and structured data.
Result
The environment is PHP 7.3.33, without support from December 2021: the question is no longer "whether to update", but "to what date". The site map has 1,300 unique addresses — about 1,213 product cards and 70 categories — with a total of 4,236 records, that is, about 3.3 duplicates per address. First response 625ms, full load 752.5ms with 350.4KB markup. A new protocol and strict secure connection are enabled. There is no structured product data on the main page, the H1 tag is missing. Clarification: the version update itself will not remove either the 3.3 duplicates per address, or the missing H1 - these are separate works that we bring out in a separate line, and not hidden inside the upgrade.
What we need from you
We can't start without this — best to prepare in advance
1Access: admin, files, database, hosting panel.
2List of modules you pay for, with licenses.
3Sources of the topic, if any.
4Decisions on functions for which there is no ready replacement: reproduce or abandon.
5Agreed switching window.
6One person with the right to accept work at the test site.
If something is missing — let us know, we'll help you gather it or do it as a separate task.
FAQ
Most frequently asked questions — with concrete answers
Is it possible to update with one button from admin?
Between small versions of the same branch - often yes, and this is normal hygiene. Between large branches - no. The base structure, extension system, and template system have been rewritten there, so old modules and the old theme do not start in principle. What is commonly called an upgrade is technically a store build on a new platform with data migration and feature replication. Hence the rule of estimation: we count by the list of modules and edits, not by the size of the catalog.
Will I lose products, orders and customers?
They should not, and this is not a question of trust, but a question of numbers. The data is transferred to the test site, after which products, categories, orders, customers and reviews are counted - before and after. The difference should be zero. The first transfer almost always gives a non-zero result: in the measured irrigation store, the control number is 300 products in 40 categories, and until exactly it appears on the test one, we do not move on. We find out the reason before switching, not after.
What will happen to my modules?
Each is analyzed separately, and this is the longest part of the audit. There is a version for the new platform - we are installing it. There is an analogue - we show how it differs from the usual one. There is nothing - we evaluate the implementation of the function with our own code or offer to abandon it. You decide on each point: we see the labor intensity, you see if the business really needs this function. Licenses for new versions of paid extensions are purchased by you, not by the contractor.
Will the design be preserved?
Appearance - yes, this is the goal of the work. Technically, the theme is often reassembled, because the system of templates between branches is different, and third-party themes for the new version were often simply not released. We reproduce the view, not copy the files. Our recommendation, and we insist on it, is not to confuse an update with a redesign. When the platform and layouts are changing at the same time, any post-launch problem has two possible sources and is more time-consuming to sort out than doing both separately.
And if you just don't update?
If the environment is still supported by the provider, the store sells, and you do not need new modules - this is a working option, and we will say so. There is an expiration date in such a solution: the garden tool store we measured has PHP 7.3.33, a version without support since December 2021, and the day when the hosting will remove it is set by the provider, not you. The difference between a scheduled update and an emergency update is the pace, price, and amount of nerves.
Will page addresses be saved?
Yes, and this is a condition of work, not a wish. If the addresses change during the transition, it is already a move: a redirect card is required, some items are lost, and recovery takes months. We preserve the structure of the addresses, and in isolated places where this is technically impossible, we close the old addresses with a 301-redirect and show the list before switching. After launch, we look at the scan errors in the Search Console - access to it is required for this.
How long does it last and how long will the store be closed?
Works — 15–45 working days. Simple - evening. The lower term limit means a build without changes in the core and a small set of standard modules; the upper one — dozens of changes in the platform files and paid extensions, some of the functions of which have to be rewritten. The rest happens on the test ground, so the battle site trades until the last day. We put the switch on the quietest evening for your store, and the old assembly remains raised just in case.
Will the update fix the SEO problems I already have?
No, and it would be dishonest to promise otherwise. The new version of the platform does not remove duplicate addresses, does not add texts, and does not add structured data. In the measured garden tool store, the sitemap has 4,236 records for 1,300 unique addresses — about 3.3 duplicates per address; after the update, there will be exactly the same number, if you do not deal with it separately. We include such works in a separate line of the estimate. And immediately a fair limit: cleaning duplicates does not add traffic, it stops scattering it, and the number of pages in the index may even drop for a while - this is an expected course of events, not a deterioration.
Send admin access and a list of modules you pay for.
In response - a document on the build: edits in the core, the fate of each module, the status of the theme and two ratings, updates against the new build. If you don't need to update now, you will hear it in the first email.
There is no price list on the site on purpose: the same work differs several times over between two clients, and a “from” figure explains nothing in that case. First a free audit — we count your pages, duplicates and speed — then we name the sum and the deadline and fix both in the contract.