OpenCart migration: moving off OpenCart safely

OpenCart is self-hosted open-source ecommerce software built on PHP and MySQL. It is light and cheap to start with, which is why many stores began on it. The reasons we see for leaving are consistent: an old version that cannot be upgraded because of core modifications, extensions that are no longer maintained, PHP version pressure from the host, and the effort of keeping a self-hosted store secure. Most OpenCart stores we assess move to Shopify, WooCommerce or, in Czechia and Slovakia, Shoptet.

Moving onto OpenCart is less common but happens, usually for a small catalog where the merchant wants full code access at low running cost. The same data questions apply in reverse.

When not to move: if the store works, is on a supported version and the pain is one extension, replacing that extension is cheaper than a replatform.

We read OpenCart data straight from the MySQL database, because the admin has no complete built-in export for products, customers and orders. The key tables are product, product_description per language, product_option and product_option_value for options, product_special and product_discount for prices, customer and address, and order with its related total, product and history tables.

The pitfalls come from the ecosystem. Extensions installed through VQMod or OCMOD may add columns or tables that the admin never shows. Some stores have edited core files directly. Options can carry their own price, weight and stock adjustments without a separate SKU. And the version matters: table names and the SEO URL table changed between 2.x and 3.x, and 4.x changed the extension structure again. We confirm the version and schema before writing any mapping.

Going into OpenCart there is no general-purpose import in core, so we load data with scripts against the database or through an import extension, after the categories, option types and customer groups exist. The model expects options to be defined once and attached to products, SEO keywords to be unique per store and language, and each product to belong to at least one category and store.

If the source store uses real variants with their own SKUs, stock and images, OpenCart's options will hold price and stock adjustments but not a full variant record, so some variant data has to be stored in extension fields or simplified. We agree that trade-off with you before import.

The main transformation leaving OpenCart is turning options into variants. Each combination of option values becomes a variant with its own SKU, price and stock, which means we generate SKUs where OpenCart only had option values, calculate prices from base price plus adjustments, and decide what to do with options that are not variant-like, such as text inputs, file uploads or checkboxes. Those usually become line-item properties or product customisation apps on the target.

Other common transformations: product_special and product_discount become sale prices, customer-group pricing or discounts; manufacturers become vendors or brand fields; attributes become metafields or filterable attributes; information pages become CMS pages. Description HTML from older editors is cleaned so it renders on the new theme.

OpenCart stores rely on extensions for payments, shipping, feeds, filters, reviews, blogs and one-page checkout. Extension data does not move by itself. We list every installed extension and modification, check which tables and settings each one uses, and decide per extension whether its data is exported, replaced by an app on the target or retired.

Themes do not transfer, and themes built for 1.5 or 2.x are also incompatible with 3.x and 4.x, so the storefront is rebuilt on the target. Payment gateways, shipping rates and tax classes are configured again and tested with real test orders. Integrations such as accounting, ERP or marketplace feeds are reconnected and checked with live data before launch.

OpenCart SEO URLs work only when Use SEO URL is enabled in the store settings and the web server rewrite rules are in place. Keywords are stored in a lookup table (url_alias in older versions, seo_url from 3.x) and resolved on each request. Stores without that setup serve URLs such as index.php?route=product/product&product_id=42, and many stores have a mix: products with keywords, some without, and category paths that include the parent category.

We crawl the live store, export the keyword table, and combine both with Search Console and analytics data so the redirect map covers every indexed product, category, manufacturer and information page, including query-string URLs. After launch we re-crawl to catch 404s and redirect chains. We do not promise rankings; we make sure old URLs land on the right new page.

Customer passwords: OpenCart hashes vary by version, and hosted targets do not accept them, so customers usually set a new password through an activation or reset email. Stored cards stay with the payment provider. Options that were never meant as variants, such as engraving text, cannot become variants and are rebuilt as product customisation.

Old installs often hold inconsistent data: products without SKUs, duplicate SEO keywords, orders pointing to deleted products. We report these in the audit and fix them in mapping. Multi-store OpenCart setups with shared catalogs may map to one target store with markets, or to several stores; that choice changes the redirect plan.

We start with an audit of version, extensions and modifications, catalog and options, SEO URL setup and integrations. Then we write the data mapping, including the option-to-variant rules and SKU generation, and agree it with you. A trial migration loads the full catalog, a sample of customers and orders, and the redirect map into a staging store for your review.

After sign-off we set a short catalog freeze, run the final migration plus a delta of new orders and customers, switch DNS, activate redirects and run post-launch QA: test orders, redirect checks, Search Console monitoring and integration checks. One named lead owns the whole project.