OpenCart to Shopify migration

OpenCart is free, lightweight and self-hosted, which is why many stores started on it. Over time the costs shift: PHP and server upgrades, security patches, extensions built as OCMOD or vQmod modifications that conflict or stop being maintained, and core upgrades between OpenCart 2, 3 and 4 that break those extensions. Small teams often end up staying on an old version because upgrading is harder than it should be. Shopify removes hosting and platform patching, and most extension functionality is replaced by apps.

Shopify is not automatically the answer. If your store relies on custom checkout logic, unusual option pricing, or B2B rules coded into OpenCart, part of that work moves into apps, custom apps or a higher Shopify plan. If the real problem is an outdated OpenCart install with a clean catalog, an upgrade may cost less. We lay out both paths in the audit.

In OpenCart, a product has options (select, radio, checkbox, text, file, date and others). Each option value can carry its own quantity and a price, weight or points adjustment, but there is no combination record: a T-shirt with size and colour options has stock per size and per colour, not per size-colour pair, and no SKU for the combination. Shopify works the other way round. A product has up to three options, and every combination is a variant with its own SKU, barcode, price, weight and inventory.

So the migration has to create data that OpenCart never held. For each product we decide which options become Shopify variant options, generate the combinations, compute prices from the base price plus adjustments, and decide how to set stock when OpenCart only knew it per option value. Often the answer comes from an ERP or warehouse file rather than OpenCart. Options that are not purchase choices in the variant sense, such as checkbox add-ons, gift-wrap, engraving text or file uploads, become line-item properties handled by the theme or a product-options app. Products with more than three variant-like options are split or restructured. OpenCart 4 introduced a master and variant product concept; if your store uses it, those products map more directly, and we check this during the audit.

OpenCart attributes, the specification table grouped by attribute group, map to Shopify metafields. OpenCart filters and manufacturers map to metafield-based filters in Shopify Search & Discovery and to the vendor field. Special and discount prices by customer group need a decision, because Shopify handles them through compare-at prices, discounts or B2B features depending on the plan.

OpenCart categories form a tree and products can sit in several categories, with separate category assignments per store in a multi-store setup. Shopify uses collections, manual or rule-based, and menus to express hierarchy. We rebuild important categories as collections with handles, descriptions and SEO fields, merge thin categories, and use automated collections where tags, product type or metafields give clean rules. Category descriptions and meta fields move with them.

Customers, addresses, newsletter status and customer groups move to Shopify, with groups usually becoming tags or segments. Customer passwords cannot be imported into Shopify, so customers set a new password through Shopify's account invitation or activation flow; we plan the message and timing with you. Reward points and store credit held in OpenCart customer transactions need a replacement app and a decision on whether balances are carried over.

Orders are imported as historical orders linked to customers, with products, totals, taxes, shipping and OpenCart order statuses mapped. They are records for customer accounts and reporting and do not re-trigger payments, fulfilment or emails. Returns and order history comments are reviewed and moved where they matter to your support team.

OpenCart builds friendly URLs from SEO keywords defined per product, category, manufacturer and information page, stored in a keyword table (url_alias in older versions, seo_url in newer ones, per store and language). With SEO URLs switched off or missing, pages fall back to query strings like index.php?route=product/product&product_id=42. A product can also be reachable under several paths, for example through different category paths or the manufacturer page, so an OpenCart store often has more indexed URL variants than products. OpenCart 4 changed the URL format again, including a language segment.

Shopify uses fixed paths: /products/{handle}, /collections/{handle}, /pages/{handle} and /blogs/{blog}/{handle}. We pull every keyword from the database, crawl the live store, add URLs from the sitemap, Search Console and analytics, and map each one to its Shopify target, reusing the OpenCart keyword as the handle where it is clean. Redirects are loaded as Shopify URL redirects, which apply only when the old path no longer resolves. Query-string URLs need testing on your store, because how they match depends on the exact pattern, and we verify them before DNS moves. After launch we recrawl and watch Search Console for 404s and coverage changes. Redirects protect URL continuity; rankings are not guaranteed.

Each installed extension and modification gets a decision: replaced by a Shopify feature, replaced by an app, rebuilt as a custom app or theme code, or retired. Common candidates are payment and shipping extensions, product-option extensions, SEO and sitemap tools, feed exporters for Google Shopping and marketplaces, reviews, blogs, and ERP or accounting connectors. Extension data often lives in its own tables, so it is exported separately and moved only where the replacement app accepts it.

The theme is rebuilt on Shopify's Liquid theme system; OpenCart Twig or TPL templates do not convert. Checkout on Shopify is standardised, with deeper customisation on Plus through Checkout Extensibility and Shopify Functions. Taxes, shipping zones and payment providers are configured in Shopify, and stored payment tokens are not migrated.

OpenCart can run several storefronts from one admin, sharing a catalog with per-store settings, and each store can carry several languages and currencies. Shopify has no multi-store mode inside one store. Shopify Markets covers several countries, currencies and languages from one store; separate Shopify stores suit different brands or catalogs. We choose based on how your OpenCart stores actually differ, then import translations per language and check localized URLs and hreflang after launch.

Audit: we read the OpenCart database and admin, the version, installed extensions and modifications, option structures, stores, languages and URL keywords, and list open decisions. Mapping: options to variants, attributes to metafields, categories to collections and URLs to redirects, in a document you sign off. Trial migration: a full run into a development Shopify store, with checks on variant counts, prices, stock, customers, orders and redirects, and a difference list for your review.

After sign-off we agree a freeze window, run the final migration and a delta migration for new orders, customers and stock, then launch with DNS, redirects, apps and payment tests. Post-launch QA covers product and collection pages, search, checkout, emails, feeds and Search Console. Scripts compare the data; a person approves every production decision.

Combination-level stock and SKUs may not exist in OpenCart, so someone has to supply or decide them. Customer passwords do not move. Checkbox, text and file options depend on a product-options app or theme work. Reward points, store credit and gift vouchers need an app and a decision on balances. Custom extension logic is replaced, not copied. And search engines re-evaluate a site after a platform change; we check URLs, metadata and indexing, but do not promise traffic or positions.