Enhancements

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.

See how it works

Price: after a free audit
Guarantee: 30 days after project sign-off
Term of works: 18–45 working days; the switching itself is one evening

Price: after a free audit
Guarantee: 30; days after project sign-off
Term of works: 18–45; working days; the switching itself is one evening
Where the update takes place: a test site, a copy of a combat one; the store does not stop
Main check: reconciliation of products, categories, orders, customers and reviews before and after
Assembly audit: 3-5; working days, free of charge, the document remains with you
What drives the estimate: kernel edits and the fate of each module, not the directory size
Conditions: payment by stages, warranty period of 30 calendar days

Process steps

Transparent stages with approval at every step

Total duration:15–45 days

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.
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.
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.
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.
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.
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

Update the current store or build a new one on the current version

How this option differs from the alternative

	New build with data migration	Our approach
What happens to edits in the kernel	are not transferred at all: the required functions are re-formulated as requirements	disassemble piece by piece and transfer to modifiers - for a long time, but the logic of the store is preserved
Modules	the list is rearranged for the new platform — what is is listed, not what was	the list remains the same, the versions change; holes are closed with analogues
Topic	the look can be made the same, but at this stage it is usually changed anyway	we transfer the appearance, including the little things that the buyer is used to
Page addresses	are stored only if it is included in the task; otherwise a redirect map is required	are stored, this is a condition of works
When it's cheaper	an assembly with dozens of built-in modules and without theme origins	the build is close to clean, there are few edits, the modules have versions for the new branch

Free audit

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 and paperwork

We work officially

Contract, act and invoice — for every project, not just large ones.

Trusted by6 brands

Terms fixed in writing8 points

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.
Sites in nine countries
Our sites run in nine countries: besides Ukraine — Poland, Germany, Austria, England, 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.

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.
Sites in nine countries
Our sites run in nine countries: besides Ukraine — Poland, Germany, Austria, England, 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.

We sign NDAs on request. After completing the work, we delete our access to your services ourselves.

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

Access: admin, files, database, hosting panel.
List of modules you pay for, with licenses.
Sources of the topic, if any.
Decisions on functions for which there is no ready replacement: reproduce or abandon.
Agreed switching window.
One 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 — 18–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.

View cases

Reply within 2 hours
No commitment
We work under a contract

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.

OpenCart Update: Upgrade to the latest version without losing your store

Transparent stages with approval at every step

Assembly audit

Test site and first transfer

Core and modules

Theme for the new template system

Acceptance on the test

Switching and 48 hours after