Moving from OpenCart to WooCommerce

Both active branches receive patches, and PHP 8.5 support means the hosting pressure that forces PrestaShop 1.7 stores to move does not apply here in the same way. A pitch that leans on urgency here is working from a false premise: the hosting deadline forcing PrestaShop 1.7 stores off their platform simply does not exist for you. An OpenCart store can be run responsibly for years by someone competent. What it cannot do is get cheaper to run. A stable extension stack with nobody billing you for compatibility work means there is nothing here to act on yet; the costs that grow sit in the software around the core rather than in the core.

OpenCart 4 changed the extension architecture, and extensions built for 3.x do not carry across. So the store on 3.x has the same structural choice a PrestaShop 1.7 store has, just without the deadline: staying means an ageing extension stack, and moving to 4 means every paid extension needs a 4-compatible version that its vendor may never have shipped. This is where the comparison with WooCommerce becomes reasonable rather than opportunistic. If you are rebuilding your extension layer regardless, the question of which platform you rebuild it on is genuinely open.

• Inventory every installed extension and check its vendor's last release date
• Flag anything whose vendor has shipped nothing for 4.x
• Price the 3-to-4 upgrade properly before comparing it to a migration
• Extensions writing to custom database tables are the expensive ones either way

OpenCart stores accumulate modifications that patch core files at runtime rather than replacing them, and after a few years nobody remembers what they all do. Some came from extensions. Some were written by a developer to fix a specific problem and never documented. They are invisible in an ordinary code review because the files on disk do not contain them, and they are the single most common source of "the old site did something we cannot reproduce" during a migration. Dump the modification list, read each one, and identify the behavior it produces. Expect two or three to be doing something the business depends on and cannot describe.

The software is free; running it is not. The real spend on an OpenCart store is hosting, security patching and developer time keeping extensions compatible through each core update — and that last item is the one that grows. The marketplace still works, but quality is uneven and you have to vet each add-on's maintenance status before building on it. Every extension you depend on is a bet that its author keeps shipping. On WooCommerce that bet is not eliminated, but the pool is much deeper, so a dead plugin usually has two or three live replacements rather than none.

The least technical point here, and usually the decisive one. A US store needing OpenCart work faces a small pool, mostly offshore agencies, at prices that reflect scarcity; WooCommerce work can be quoted by many shops and a great many freelancers. Over one project that hardly matters. Over five years it dominates every other line item — and it is why most OpenCart migrations we see start with the developer who maintained the store becoming unavailable, not with a technical failure.

Catalog, customers and orders migrate with recognizable field mappings, though option sets need attention: OpenCart models options and variants differently from WooCommerce variations. Passwords do not transfer at all. SEO keyword URLs live in OpenCart's own table rather than deriving from a slug, so an incomplete export silently drops your friendly URLs and leaves you redirecting index.php?route= paths.

• Transfers: products, categories, manufacturers, customers, orders, customer groups
• Needs remodelling: option sets and their relationship to stock
• Needs explicit export: SEO keyword URLs from OpenCart's own table
• Never transfers: password hashes, vQmod/OCMod modifications, extension configuration

A few hundred products, steady sales, and a developer who knows the store and is staying — that combination does not need a migration, and we would rather say so than take the project. The same holds if your catalog depends on a custom extension that took months to build and has no market equivalent — rebuilding it is the whole project, and the platform change is incidental to it. And if the reason you are considering this is that someone told you OpenCart is abandoned, go back and check the release dates first. Bad premises produce expensive decisions.

Run the catalog import repeatedly against staging until product counts, prices and stock reconcile to the unit against the live store. Build the redirect map from the SEO keyword table plus twelve months of Search Console URLs, not from one or the other. Freeze the catalog, run a delta import, switch, and watch orders rather than analytics for the first day. Keep the OpenCart install running read-only for a month at minimum — with an undocumented modification layer, the questions that arrive in week three are the ones you cannot answer from the new system alone.