Migrating from OpenCart 3 to 4 is not an update—it's a complete rebuild. We've encountered projects where custom extensions and non-standard templates turned the process into a puzzle. Without a detailed plan and testing, you risk losing data and customers. Our team has over 10 years of experience and has completed 40+ OpenCart migrations, so we know every pitfall. Let's break down how to transfer data, adapt code, and maintain performance.
Why migrating OpenCart 3 → 4 is not just an update
OpenCart 4 is a completely reworked platform. It requires PHP 8.0+, templates have moved from PHP to Twig, and the OCMOD extension system has been replaced by the Events System. Direct upgrade is impossible—you need a data migration and a full rewrite of custom code. According to the official OpenCart documentation, the transition requires a thorough audit and testing.
What technical challenges we solve
- PHP incompatibility. OC3 ran on PHP 7.x, OC4 requires 8.0+. Outdated environments are the first cause of failures. We check the server and update the environment.
- Templates PHP → Twig. All
.tpl.phpfiles must be rewritten to.twig. Twig runs faster due to template compilation into PHP code, giving a page load speed boost of up to 40%. - OCMOD → Events. Modifying the core via file patching has been replaced by the event system. Extensions are rewritten without altering source files, simplifying maintenance.
- Storage API changes. The storage folder structure and file handling have been completely overhauled. Paths need to be reconfigured.
Each of these issues requires a separate approach. During the audit, we determine the exact scope of work and risks.
How we perform the migration: a real case
Every project is unique, but there's a proven scenario. We migrated an auto parts store with 5,000 products, a custom module for discounted items, and 1C integration. First, the audit—we identified 12 custom extensions, 3 of which required a full rewrite. Then backup, data transfer via SQL, template adaptation over 2 weeks, testing on a staging server, and launch. Result: page load speed increased by 40% thanks to Twig and PHP 8. The customer experienced no downtime—the launch was seamless.
Adapting extensions to the Events System
Instead of patching files via OCMOD, we use events. Each extension is rewritten as an event handler class. Example: displaying a custom badge on the product page:
class ExtensionMyExtensionEventProductList { public function index(&$route, &$data): void { foreach ($data['products'] as &$product) { $product['custom_badge'] = 'Sale'; } } } This approach eliminates conflicts between extensions and simplifies core updates.
What technical changes occurred in OpenCart 4?
| Feature | OpenCart 3 | OpenCart 4 |
|---|---|---|
| PHP | 7.x | 8.0+ |
| Templates | .tpl.php | .twig |
| Extensions | OCMOD | Events |
| Storage | DIR_UPLOAD | New Storage |
| Admin panel | Old | Completely redesigned |
Twig templates work twice as fast as PHP templates due to compilation, and the Events System makes extensions safer and easier to maintain. Learn more about Twig in the Twig documentation.
What's included in the work?
- Full audit of the current store with a detailed report.
- Export and transformation of data (products, orders, customers, settings).
- Adaptation of templates and all extensions to Twig and Events System.
- Configuration of the new Storage API and file transfer.
- Testing on a staging server with verification of all key scenarios.
- Documentation of changes and team training.
- One month of technical support after launch.
Process and timelines
- Audit of the current store (extensions, settings, data volume).
- Environment preparation (PHP 8.0+, server, staging).
- Data export and transformation for OC4.
- Adaptation of templates and extensions to Twig and Events.
- Import and testing on staging server.
- Launch and monitoring.
| Store type | Timeline |
|---|---|
| Up to 500 products, standard template | 1–2 weeks |
| 1000–10000 products, custom template | 3–5 weeks |
| Large store with custom extensions | 2–3 months |
Guarantees and support
- Full backup and its verification.
- Transfer of products, orders, customers, and all settings.
- Adaptation of templates and all extensions.
- Configuration of the new Storage API.
- Testing of all key scenarios (cart, checkout, personal account).
- Documentation of changes.
- One month of technical support after launch.
Common migration mistakes: ignoring PHP extension incompatibility, skipping payment gateway testing, losing image links due to improper rsync. We ensure data integrity and uninterrupted operation.
Have a complex project? Contact us for an audit—we'll estimate the scope and timeline. Or leave a request for a consultation—we'll discuss the details.