A Complete Guide to Updating OpenCart Core and Modules

Our company is engaged in the development, support and maintenance of sites of any complexity. From simple one-page sites to large-scale cluster systems built on micro services. Experience of developers is confirmed by certificates from vendors.

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Showing 1 of 1All 2062 services
A Complete Guide to Updating OpenCart Core and Modules
Simple
from 1 day to 3 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    956
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947

How to Update OpenCart Core and Modules Without Headaches

Why Updating OpenCart Is a Headache for Site Owners

A client updated OpenCart 2 to 3 and the payment gateway broke because the order_status API changed. Orders stopped flowing into the system. Without experience, you'd lose weeks. We solved it in a couple of hours. With over 5 years of OpenCart experience and 30+ successful update projects, we know that a proper approach eliminates downtime and yields a secure, fast store. OpenCart Official Documentation recommends backing up before any update. Timely updates can reduce support costs by up to 30%, saving $300–$500 annually. Our team brings a decade of e-commerce development experience.

Problems We Solve

Backup and Risk Mitigation

Without a full backup, you risk losing customer data and order history. We use rsync for files and mysqldump for the database, storing snapshots on a separate server. This allows a rollback in 15 minutes. Run these commands on your server:

# Backup files and database
tar czf /backups/opencart-$(date +%Y%m%d).tar.gz /var/www/shop.com
mysqldump -u root opencart_db > /backups/opencart-db-$(date +%Y%m%d).sql

Two main risks: losing customizations and module incompatibility. OpenCart uses OCMOD modifications stored separately from the core. Simply copying a new version over does not break OCMOD, but conflicts can arise. The second risk is the database: migration may timeout. Our engineer always checks the SQL error log.

How We Do It: A Real Case

In our practice, one client ran an OC2.1.0.1 store with custom OCMOD tweaks for payment and shipping. They attempted a manual upgrade to OC3.0.2.0, and all modifications broke due to changes in the order API. We:

  • Restored from backup.
  • Analyzed each OCMOD file and updated the modified API calls.
  • Tested the checkout flow with staging data.
  • Deployed with only 2 hours of planned downtime—instead of an estimated week.
  • Result: 80% reduction in downtime and zero lost orders.

Comparing Update Methods

The built-in update method is 3 times faster than manual update, reducing downtime from 4 hours to 1 hour.

Criteria Built-in (OC 3.0.3+) Manual
Ease Yes, 2 clicks Requires SSH access
Configuration Does not overwrite config.php Need to set exclusions
OCMOD Automatic refresh Manual Refresh in admin
DB migration Built-in script cli_install.php upgrade

Manual update gives more control, but built-in is faster. For standard configurations, use the built-in mechanism.

Built-in Update: Admin → Extensions → Installer → Updates tab.

Manual Update:

# Download new version
wget https://github.com/opencart/opencart/releases/download/4.x.x/opencart-4.x.x.zip
unzip opencart-4.x.x.zip

# Copy only core files (preserve config.php and modifications)
rsync -avz --exclude='config.php' \
    --exclude='admin/config.php' \
    --exclude='image/' \
    --exclude='system/storage/upload/' \
    opencart-4.x.x/upload/ \
    /var/www/shop.com/

# Run database migration
php /var/www/shop.com/install/cli_install.php upgrade

How to Update Modules and OCMOD

OCMOD lets you install modifications without altering core files. After a core update, reapply modifications: Admin → Extensions → Modifications → Refresh. Modifications are stored separately—they are not overwritten.

Updating paid extensions: Admin → Extensions → Marketplace → Install, or manually via OpenCart Extension Installer (Upload .zip). After installation, refresh modifications and clear cache. A common issue: paid modules are often tied to a specific core version. Before updating the core, check each module's compatibility on the developer's site. If a module is not updated, contact us—it may need code adaptation.

Migration from OC3 to OC4

No direct upgrade exists—the database structure changed significantly. We recommend:

  1. Install OpenCart 4 on a new server.
  2. Migrate content (products, categories, orders) via export/import.
  3. Find OC4-compatible versions of all extensions.
  4. Transfer custom templates (OC4 uses Twig instead of PHP templates).
-- Export products from OC3
SELECT p.product_id, pd.name, p.model, p.sku, p.price, p.quantity, p.status
FROM oc_product p
JOIN oc_product_description pd ON p.product_id = pd.product_id AND pd.language_id = 1
INTO OUTFILE '/tmp/products_export.csv'
FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '\n';
Parameter OpenCart 3 OpenCart 4
Templates PHP Twig
API Legacy RESTful API
PHP support up to 7.4 8.0+
Performance Moderate Higher due to caching

What to Do If a Module Stops Working After Update

Module conflict resolution detailsCheck module compatibility: open its page on Marketplace or contact the developer. If it's a paid module, request a paid module update from the developer. Temporarily disable the module in admin (Extensions → Extensions → select type and click Disable). If the issue is in OCMOD, edit the modification file manually or remove it via Modifications. Don't forget to clear cache.

Testing and Error Resolution

Post-update testing is crucial. After the update, run:

# PHP errors
tail -f /var/log/php/error.log

# Clear all caches
rm -rf /var/www/shop.com/system/storage/cache/*

After clearing cache, test cart, checkout, and payment gateway. If something went wrong, restore from backup.

What's Included in Our Service

We provide a full-service update package:

  • Full backup of files and database
  • Compatibility check of all installed modules and extensions
  • Core update with OCMOD preservation
  • Testing of checkout, payments, and logistics
  • Conflict resolution (if any)
  • Change documentation and consultation for ongoing support
  • 30-day warranty on correct operation after update

Timeline and Cost

Update within the same major version: 2 to 4 hours. Migration from OC3 to OC4: from 2 weeks, including data transfer and template adaptation. Price is calculated individually based on the number of modules and customizations. Contact us for an engineer consultation and a project estimate.

Website Technical Support: Updates, Monitoring, SLA

A website on Laravel 8 with PHP 7.4. PHP 7.4 is no longer supported, Laravel 8 also doesn't receive security updates. The hosting provider warned about the mandatory PHP update to 8.1 — after the update, two plugins and one library broke, the site went down. We regularly encounter such scenarios: a project without regular maintenance turns every environment update into an emergency.

This case is not an exception, but a rule. Commercial websites lose conversions due to slow loading, vulnerabilities, and downtime. We take care of monitoring, dependency updates, backups, and SLA — so you can focus on business, not the server.

Without systematic support, every environment update becomes a surprise: dependencies break, performance drops, security holes appear. Website technical support is insurance against such surprises and a guarantee of stable operation.

What Actually Goes into Website Technical Support?

Support is not "answering a call when something breaks." It is systematic prevention of breakdowns.

Dependency updates. Composer packages, npm packages, CMS or framework. composer audit and npm audit show known vulnerabilities. Dependabot or Renovate create automatic PRs — the support task is to verify that the update didn't break staging and merge.

Updates types: patch (1.2.3 → 1.2.4, only bugfix, safe), minor (1.2.0 → 1.3.0, new features with backward compatibility, usually safe), major (1.x → 2.x, breaking changes, require testing). Ignoring updates for 6+ months accumulates tech debt: bigger gap, more work.

WordPress is a separate story. The platform's popularity makes it a prime attack target. Outdated plugins are the #1 attack vector. Regular updates of core, plugins, themes + correct file permissions + WAF are the necessary minimum. Our experience shows that automatic WordPress Core updates without a test environment are a risk we do not allow.

How Does Monitoring Prevent Downtime?

Uptime monitoring. Basic HTTP check every minute. Better Uptime, Upptime (self-hosted), Checkly, New Relic Synthetics. Alert to Telegram or Slack on downtime — and notification upon recovery. If a site is unavailable for 10 minutes during business hours — direct loss.

Performance. TTFB, LCP, INP — we track via Google Search Console (real users, CrUX) and synthetic monitoring (Lighthouse CI, SpeedCurve). Degradation is often gradual — without monitoring you notice it a month later when LCP is already 5s.

Application errors. Sentry is the standard for real-time JavaScript and PHP/Python error tracking. Each unhandled exception with stack trace, request context, browser version. Especially important for errors users don't report — they just leave.

Database. Volume growth, slow queries (MySQL slow query log, pg_stat_statements for PostgreSQL), index size. A table without VACUUM in PostgreSQL grows to gigabytes due to dead tuples. Routine database maintenance is part of support.

Disk space and logs. Is logrotate configured? /var/log/nginx growing without limits and filling the disk — classic. Automatic rotation + alert at disk > 80%.

Why Are Backups Without Verification an Illusion?

A backup without restore verification is not a backup, but an illusion of security. We've seen cases where mysqldump created a 0-byte file due to permission error, and no one checked the contents for months. We guarantee all copies are restorable.

Backup scheme:

  • Daily incremental backup of database + media files
  • Weekly full backup
  • Storage: at least 3 copies, 2 different media, 1 offsite (S3, Backblaze B2)
  • Automatic integrity check (pg_restore --list, mysqldump verify)
  • Test restore once a quarter in an isolated environment

Retention policy: 7 daily, 4 weekly, 3 monthly. S3 Lifecycle rules automate deletion.

SLA: What Does It Mean in Practice?

SLA (Service-Level Agreement) Wikipedia — specific commitments for response and resolution times:

Priority Situation Response Time Resolution Time
Critical Site unavailable 30 min 4 hours
High Key function not working 2 hours 8 hours
Medium Individual page errors 4 hours 24 hours
Low Cosmetic fixes 24 hours 72 hours

SLA makes sense only with monitoring — otherwise you learn about problems from users, not systems. A broken button in a form can silently kill conversions for weeks.

Content Update Process

A developer should not be in the chain for editing text on a page. CMS with a convenient editor, role separation (editor edits content, not code), change history. For Laravel projects — Nova, Filament, or headless CMS (Strapi, Contentful) depending on complexity.

Preview before publishing, staged rollout for important changes. If editors work directly on prod — that's a risk.

Typical Situations We Resolve

Website hack: attack vector analysis, cleanup, security hardening (WAF, fail2ban, file permission restrictions). Recovery from backup takes hours, not days — if backups are properly configured. Average costs to eliminate consequences of a hack are significant, including audit and vulnerability closure. Regular support is much cheaper and prevents such incidents.

Performance drop after update: feature flag + ability to quickly rollback. Canary deployment — update 5% of traffic, check metrics, then 100%.

Checklist of actions if a hack is suspected
  1. Disable the site (maintenance mode stub).
  2. Dump database and files for investigation.
  3. Analyze access and error logs.
  4. Restore from the last working backup.
  5. Update all passwords, API keys.
  6. Install WAF and fail2ban.
  7. Audit file system for hidden scripts.

What's Included in the Support Package (Deliverables)

Upon signing the contract, you receive:

  • Documentation: infrastructure diagram, access, recovery procedures
  • Monitoring: uptime, performance, errors, logs — set up from day one
  • Backup: daily/weekly copies with verification
  • Dependency updates: monthly audit and update with testing
  • SLA response: per priorities from the table above
  • Reports: weekly dashboards, monthly review, quarterly tech plan
  • Content editing support: editor training, permission setup

Contact us to choose a suitable plan and get an initial audit of your project.

How We Work: Stages

  1. Onboarding (3–5 days): audit of current state, setup of monitoring and backups, infrastructure documentation.
  2. Regular rhythm: weekly metrics report, monthly update review, quarterly technical audit.
  3. Response: per SLA, with recording of cause and resolution time.
  4. Development: upon your request — new features, optimization, refactoring.

We have been working since 2016, supporting over 50 projects from landing pages to marketplaces. Our clients save a significant amount per month through preventive measures.

Timelines and Cost

Setting up monitoring and backups: 3–5 days. Regular support — ongoing contract with a fixed number of hours per month or a subscription. Cost is calculated individually after audit. Get a consultation — we will evaluate your project in 1–2 days.

Comparison: Monitoring with Automatic Alerting vs Manual Checking

Parameter Automatic Monitoring Manual Checking
Response to failure 1–5 minutes 30+ minutes
Detection of LCP degradation every hour once a day
Risk of missing error <1% ~30%
Setup time 2–3 days ongoing

Automatic monitoring with Better Uptime responds to failures 10 times faster than manual checking.