Store migration
We move OpenCart stores onto Shopify with the catalogue, the customers and the order history intact. Two things make an OpenCart migration different from any other: your product options are not variants yet, and if SEO URLs were never switched on, your indexed pages are query strings that Shopify cannot redirect the ordinary way. Both are solvable. Both need finding before anyone quotes.
Why stores leave
OpenCart is genuinely lightweight and genuinely free, and that is the point of it. The stores that outgrow it tend to do so the same way: one extension at a time, until the cart is held together by twenty of them and nobody will touch an upgrade.
You
Hosting, TLS, PHP versions, backups and security patching are yours. Shopify takes all of it, which is the change most teams notice first.
0
Shopify Store Migration imports from Square, WooCommerce, Etsy, Wix, Amazon, eBay, Clover and Lightspeed. OpenCart is not on that list, so every route is a third party tool or a script.
1.5 to 4
OpenCart 4 was a substantial rewrite and a great many stores never made the jump. Extensions written for 3 do not simply carry forward, which is how stores end up frozen.
Options
This is the one that surprises people. OpenCart core gives you options with price and weight modifiers. It does not give you true variants with their own SKU and stock unless you added an extension for it.
What you gain
The move is worth doing when the extensions holding your store together have become the reason you cannot change anything. That is usually what brings OpenCart merchants to us, not the hosting bill.
Shopify is built around variants with their own SKU, stock, price and image. On OpenCart that is extension territory. Getting it natively is usually the single biggest operational improvement of the whole move.
Shopify runs the infrastructure, the certificates and PCI compliance. There is no core upgrade to plan and no extension to test against it.
OpenCart checkout is frequently the most modified part of the store, and the most fragile. Shopify maintains checkout, and on Plus you extend it rather than editing it.
Shopify allows 2,048 variants per product, not the 100 most guides still quote. The limit that does bite is three options per product, and for OpenCart stores with four or five option groups that is the decision to get right early.
The part nobody writes about
This is the most important section on the page and almost no OpenCart migration guide mentions it. Read it before you accept a quote from anyone.
?route=
Out of the box, OpenCart addresses pages as a query string, for example index.php with a route parameter and a product id. SEO URLs are something you switch on and populate, not something you get by default.
Not
Shopify states that URLs containing query strings might not work as expected with URL redirects. So if your store never enabled SEO URLs, the native redirect tool will not cleanly rescue your indexed pages, and a page promising otherwise has not checked.
seo_url
If SEO URLs were enabled, OpenCart has been keeping a table that maps every keyword to its internal route. That table is a redirect map somebody already built for you, and we take it straight out of the database.
100k
Shopify caps URL redirects at 100,000 on standard plans and 20,000,000 on Plus. Large OpenCart catalogues with per language and per store keywords can get closer to that first number than you would expect.
Rebuilt, not moved
OpenCart is PHP and Twig, with a modification system that patches core at runtime. None of it converts to Liquid.
OpenCart themes and any Twig overrides do not convert. The front end is a rebuild on every replatform. Most brands use the move to redesign rather than reproduce.
Extensions that patch core through the modification system leave no clean boundary to port. Each capability becomes a Shopify app, a Function, a metaobject, or it is dropped because Shopify does it natively.
OpenCart option values carry price and weight modifiers that add to a base price. Shopify variants carry absolute prices. Every modifier has to be resolved into a real price per variant, and that arithmetic is where silent errors hide.
OpenCart customer groups and any group pricing become Shopify B2B price lists and customer segments. The logic survives, the mechanism does not.
OpenCart multi store runs several storefronts off one admin. That maps to expansion stores on Plus, or to Shopify Markets inside one store, and picking wrong is expensive.
Information pages carry across as content. The layout and module positions around them rebuild as Shopify sections and metaobjects.
Scope
On an OpenCart store the database answers almost every question that matters, and two of the answers change the price materially.
What data migrates
You host OpenCart, so the database is yours and nothing is locked away. This is the full entity list with the fields inside each one, because a list that just says products and customers is not something you can check a quote against.
Name, description and images in the description, model, SKU, UPC and EAN, status, price and special price, cost, quantity and stock tracking, weight and dimensions, manufacturer, base image and every additional image in order, meta title, meta description and meta keywords.
Option values become Shopify variants, with price and weight modifiers resolved into absolute prices. Product level stock is apportioned across the variants we create. This is the part of an OpenCart migration that is built rather than copied, and it is where quotes differ most.
Specification data, not variant data. Attributes become metafields and render as a specifications table on the product page, which is what they always were.
Name, description, image, SEO keyword, meta title and meta description. Categories become collections, and because Shopify collections do not nest, subcategory relationships are rebuilt with tags and automated collection rules.
First and last name, email, telephone, newsletter status, and full billing and shipping addresses including company, street, city, state, postcode and country. Groups become customer segments or B2B companies. Passwords do not move on standard plans, because Shopify cannot accept another platform hash. On Plus, Shopify support can whitelist a legacy algorithm and import them, which is the one real exception. Either way a reset campaign is planned for launch.
Order number and date, status, customer name and email, billing and shipping addresses, comments and notes, and every line with its product, SKU, chosen options, quantity, unit price, discount, tax, shipping and total. Reconciled to the cent against your own database.
Author, rating, review text and date, matched back to the right product. OpenCart stores reviews in its own table so they are recoverable, into Judge.me, Loox or Yotpo. Shopify has no native reviews feature to hold them.
Manufacturer becomes vendor. Coupon codes carry their type, amount, minimum spend, validity dates and usage limits. Information pages bring their content, SEO keyword and meta fields across as Shopify pages.
Every keyword in the seo_url table becomes a 301 redirect to its new Shopify address, live at cutover. Where SEO URLs were never enabled, we build the mapping layer instead. Redirects are included in the price here, not sold as an extra.
What breaks
Every one is solvable. None is a reason to stay. They are the reason an audit comes before a price.
If SEO URLs were never enabled, your indexed pages are query strings and Shopify says those may not redirect as expected. The fallback is a mapping layer on the 404 template, which works, but it is a build item and it needs to be in the quote.
OpenCart core tracks quantity on the product, with options as modifiers. Shopify tracks stock per variant. Splitting one number across twelve variants is a business decision, and getting it wrong means overselling on day one.
Shopify allows three options per product. OpenCart does not limit you. One of your option groups has to stop being an option, and which one is a merchandising call.
OpenCart lets an option be a text field, a date, or a file upload, for engraving, personalisation or artwork. Those are not variants at all. They rebuild as line item properties or a product options app, and they are routinely forgotten until launch week.
OpenCart category trees can be several levels deep. Shopify collections are flat. The tree is re expressed through navigation and automated collections.
On standard Shopify plans they cannot move, because Shopify will not accept another platform hash. On Plus, Shopify support can whitelist a legacy hashing algorithm and import them, which is the one real exception and it needs an enterprise plan and a support request. Plan the reset campaign either way, because most stores are not on Plus.
Extensions to apps
A store with twenty extensions rarely needs twenty apps. A good share of what you are paying for is already in Shopify.
Usually nothing. Shopify does variants natively, which is why this category disappears entirely rather than being replaced.
Judge.me, Loox or Yotpo. Shopify has no native reviews, so this is one of the few places you must add an app to keep what you already had.
Shopify Search and Discovery is free and covers most of what a paid OpenCart filter extension did. Klevu or Algolia where the catalogue justifies it.
Replaced by Shopify URL redirects, within the query string caveat above. The extension goes away, the mapping problem does not.
Shopify Markets with Translate and Adapt, native rather than an extension stack. One of the clearest wins in the move.
Rebuilt as an app or a custom app against the Admin API, often through middleware. Budget this properly. It is routinely the largest line after the theme.
The catalogue
This is the work that defines an OpenCart migration. OpenCart describes a product and the choices a customer can make about it. Shopify describes a set of distinct things you can buy. Converting the first into the second is not a data mapping, it is a merchandising exercise.
Three sizes and four colours is seven option values in OpenCart and twelve variants in Shopify. The row count grows fast, and so does the number of prices and stock numbers you now own.
A base price with a plus two on large has to become a real price on every large variant. We resolve that arithmetic and then reconcile it against your own price list, because a rounding error here is a pricing error on every order.
One stock number on the product becomes a number per variant. Sometimes your warehouse already knows the split. Sometimes nobody does, and the honest answer is a stock count before launch rather than a guess.
Engraving text, a date field, an uploaded file. These are line item properties, not variants, and treating them as options is how you end up with a catalogue nobody can manage.
Free
The same checklist we run internally. Forty one items across the SEO URL audit, options to variants, data, redirects, payments and launch. No email wall.
We reply within one working day.
How it runs
You keep trading on OpenCart until the day we cut over. Nothing goes live until the numbers reconcile against your own database.
We read the database. The first two questions are whether SEO URLs are on and whether your options are core options or an extension. Those two answers shape everything after.
Start with the audit
The audit stands alone. If it says stay on OpenCart, that is what it will say.
Book the auditEvery OpenCart field gets a Shopify destination in writing, and you approve it before anything is imported. On OpenCart this document is unusually important, because the variant model is being invented rather than translated.
A full import into a development store, then reconciliation against your own database. We expect to find problems here. That is what it is for.
Theme, apps, integrations and any Functions or checkout work, alongside the data work rather than after it.
A delta import picks up everything that sold while we were building, then DNS moves. Redirects are live at the moment the domain switches.
Monitoring, Search Console, and the fixes that only surface once real customers are using it. Included, not billed separately.
Talk to us about your store
Send the address and we will tell you what the move actually involves.
Get a migration planSituations
Written as scenarios rather than logos. We do not publish client names or numbers without written permission, and we are not going to start on a page that is trying to win your trust.
Auto parts
Every indexed page was a query string, so the native redirect tool could not carry them. The fix was a mapping layer on the 404 template that reads the old product id and sends it to the right Shopify product. Scoped in week one rather than discovered in week twelve.
Indexed pages kept their destination
Gifting
Personalisation text and an upload field had been built as OpenCart options, which meant they would have multiplied into thousands of meaningless variants on Shopify. They became line item properties instead.
Catalogue stayed manageable
Workwear
Stock was tracked on the product, not per size and colour. Nobody in the business knew the real split. We ran a count before launch rather than importing a guess.
No overselling in the first week
Search
Every OpenCart store is in one of two states, and they need completely different work. Nobody can quote your migration honestly without checking which one you are in.
The seo_url table already maps every keyword to its route, so your redirect map mostly exists. This is the good case and it is largely mechanical.
Shopify says query string URLs may not redirect as expected, so the native tool is not enough. A mapping layer on the 404 template reads the old product id and routes it correctly. It works, and it is a build item nobody includes by default.
SEO URLs get switched on partway through a store life, so older products have keywords and newer ones do not, or the other way round. A crawl plus the table is the only way to know.
Not the next morning. The map is loaded and tested on the development store, then goes live with the DNS change.
What you get
Not a list of intentions. Each of these is either in the contract or it is not, and you can hold us to every one.
OpenCart keeps selling for the whole project. A delta import picks up everything that sold during the build, then DNS moves. Planned downtime is zero, and the old store stays up afterwards, read only, so a bad week is recoverable.
Every URL that returns a 200 is crawled and mapped before launch, and the redirects go live with the DNS change rather than the next morning. Titles and meta descriptions carry across unchanged. Redirects and SEO URL mapping are in the price, not paid extras.
One named person who knows your store, runs the weekly call, and is the same person on launch day. You are not handed between a salesperson, a migration operator and a support queue.
Everything lands in a development store first and is reconciled against your own database. Variant counts, every variant price, order totals to the cent. The production import repeats something that already worked.
One number and one launch date, not a range and not an hourly estimate that drifts. If the audit finds something that changes the scope, you see it before you commit, not after.
Search Console watched daily, 404s fixed as they appear, stock levels sanity checked and Core Web Vitals tracked. Included in the price rather than sold back to you as support.
Cost
We quote fixed after the audit, never as a range before it. On OpenCart the first two items move the figure more than anything else.
A populated seo_url table is close to mechanical. A store indexed on query strings needs a mapping layer built and tested. That is a real difference in scope and we will show you which one you are before quoting.
Core options needing to be resolved into variants is more work than a store that already ran a variants extension, because prices and stock have to be derived rather than copied.
Not how many, but how many do something Shopify does not. Most lists shrink once the native column is filled in.
Rebuilt as it is, given a facelift, or redesigned. All three are quoted inside the migration rather than as a second project.
ERP, accounting and 3PL connections are discrete rebuilds and the usual cause of an overrun.
Also migrating from
The playbook is mostly shared. What changes is where the platform hides your data and which constraints bite on the way in.
The closest relative. Self hosted, module heavy, and categories that often sit at the root.
Shopify imports WooCommerce natively, which makes it the easiest path of any platform here.
Self hosted and extension heavy, with a configurable product model closer to Shopify variants.
A SaaS to SaaS move, so the data is clean and the work sits in the storefront and the apps.
The opposite problem. The data is locked in and the export is the hard part.
Products, order history and every changed URL, with the same three option limit on arrival.
Who you are hiring
The rating and the review count are on our Shopify Partner Directory listing, so you can verify them right now rather than take our word for it. The rest are commitments we put numbers on, because a number is something you can hold us to.
Risk
A migration you cannot reverse is a migration you should not start.
Keep the hosting running for a month after launch. It costs very little and it means a bad week is recoverable rather than theoretical.
Taken by us, held by you. You own the server, which is the one genuine advantage a self hosted platform has on migration day.
Everything goes into a development store and is reconciled first. The production import repeats something that already worked.
Because prices are derived from modifiers rather than copied, they get checked against your own price list rather than against the migration tool reporting on itself.
Never into a promotion and never on a Friday. The delta import means nothing is lost by waiting for the right morning.
Questions
The questions merchants actually ask, answered against Shopify and OpenCart documentation rather than against what reads well.
No. Shopify Store Migration imports from Square, WooCommerce, Etsy, Wix, Amazon, eBay, Clover and Lightspeed R and X. OpenCart is not on that list. Every route in is a third party tool such as Cart2Cart, LitExtension, MigrationPro or Next-Cart, or a bespoke script against the database and the Shopify Admin API. For anything with a real extension stack we write the script.
That depends entirely on whether SEO URLs were enabled, and it is the first thing we check. If they were, OpenCart has a table mapping every keyword to its internal route and your redirect map largely exists already. If they were not, your indexed pages are query strings, and Shopify states that URLs containing query strings might not work as expected with URL redirects. In that case we build a mapping layer on the 404 template that reads the old product id and routes it to the right Shopify page. It works well, and it is a build item that most quotes omit.
Because it is a convenient simplification. OpenCart core gives you options with price and weight modifiers attached to option values. It does not give you a distinct variant record with its own SKU and stock unless you installed an extension that adds one. Shopify is variant native. So the migration does not translate your variants, it creates them, and the prices and stock levels have to be derived. That derivation is the single most error prone part of an OpenCart migration.
OpenCart core holds quantity on the product. Shopify holds it per variant. So one number has to become twelve, or however many variants you end up with. Sometimes your warehouse already knows the split and we import it. Where nobody knows, the honest answer is a stock count before launch, because the alternative is overselling in the first week and we would rather say that than guess.
They are not variants and must not be treated as such, or they multiply your catalogue into thousands of meaningless rows. Personalisation text, date fields and file uploads become line item properties on Shopify, or a product options app where the logic is complex. This is routinely forgotten until launch week, so we look for it in the audit.
Shopify raised the limit from 100 to 2,048 variants per product for all merchants. Many migration guides still quote 99 or 100 and advise splitting products to work around it. That advice is out of date. The limits that do apply are three options per product, and 250 media files per product, which a catalogue with an image per variant can reach first.
Shopify allows three options per product and OpenCart does not limit you. The option groups that drive price, stock or a distinct image earn the three slots. Anything else moves into metafields, line item properties, tags, or becomes a separate product. We decide this in the mapping stage and you sign it off before any import runs.
Yes. OpenCart has native reviews stored in its own database table, and you have the database, so they are recoverable. They go into Judge.me, Loox or Yotpo, because Shopify has no native reviews feature to hold them. If you used a reviews extension instead, it depends on whether it exposes its data, and we check that in the audit.
On standard Shopify plans, no. Shopify has no way to accept a password hash from another platform, and the password fields on the customer API are deprecated, so customers reset on first login and we send that campaign as part of launch. On Shopify Plus there is a narrow exception worth knowing about: Shopify support can whitelist a legacy hashing algorithm and import the existing hashes, so customers keep their passwords. It is a support request on an enterprise plan, not a checkbox, and no migration app does it for you. If a provider offers password migration without mentioning Plus and a Shopify support ticket, ask which of those two they are leaving out.
Six to ten weeks for a store with a clean catalogue, a short extension list and SEO URLs already enabled. Three to six months is the common range once integrations, a custom theme, a real extension audit and a query string mapping layer are in scope. We give you a date with the fixed price after the audit rather than a range before it.
We do not publish a price here, because any number we put on this page would be wrong for most readers. The audit produces a fixed price and a launch date. On OpenCart the two things that move it most are whether your URLs are redirectable and whether your options have to be resolved into variants from scratch.
It is a fair question and the honest answer is that both are a rebuild. OpenCart 4 changed enough that extensions and theme work do not simply carry forward. If you are going to spend that anyway, the question is whether you want to spend it again at the next major version. If your team maintains OpenCart comfortably and your extension list is short, staying is a legitimate answer.
Yes. OpenCart stays live and takes orders for the whole project. A delta import picks up everything that sold during the build, immediately before DNS moves. Planned downtime at cutover is zero.
Not as nesting. Shopify collections are flat, so an OpenCart category tree several levels deep has to be re expressed through navigation, tags and automated collection rules. The customer facing result can be identical. The redirect map still has to account for every level.
The licence spend is not recoverable and does not transfer. The useful exercise is sorting the list into three piles: replaced by something native in Shopify, replaced by an app, or genuinely custom. On OpenCart that first pile is usually larger than merchants expect, because variants, filtering and multi currency are all native on Shopify and all extensions on OpenCart.
Yes, including line items, the options chosen on each line, addresses, totals, tax and status. Worth knowing that Shopify admin has no order import at all, on any plan, from any platform. Orders always go through an app or the Admin API. We reconcile the totals against your database before anyone signs off.
It maps either to expansion stores on Plus, or to one Shopify store with Markets handling country level presentation. Which one depends on whether your storefronts share a catalogue or genuinely sell different things. Getting this wrong is expensive, so it is an audit decision rather than an implementation one.
Yes. 100,000 URL redirects on standard plans and 20,000,000 on Plus. Most stores are nowhere near it, but a large OpenCart catalogue with keywords per language and per store can get closer to the first number than you would expect, and it is worth counting before you assume.
Expect a dip of roughly five to fifteen percent for two to four weeks while Google reprocesses the redirects, then recovery. If traffic has not recovered by week eight, the redirect map has gaps, and that is fixable. Permanent loss comes from missing redirects, not from changing platform. On OpenCart specifically, the query string question decides how much work avoiding that takes.
No. OpenCart themes are PHP and Twig, and Shopify themes are Liquid. There is no converter and there will not be one. The front end is a rebuild on every replatform. You can have it rebuilt to look the same, given a facelift, or redesigned, and we quote all three inside the migration.
Ask your team, because the answer is often yes and often forgotten. Stock reports, accounting exports and old integrations frequently query the database rather than going through an API. All of them stop working when you move, because Shopify gives you an API and not a database. We look for these specifically.
Start with the audit. If your team maintains OpenCart comfortably, your extension list is short and your upgrade path is under control, staying is a reasonable decision and we will tell you so. We would rather lose the project than sell a migration that does not pay for itself.
It changes the extraction a little and the rebuild not at all, and the rebuild is most of the cost. OpenCart 1.5 is long out of support and usually on an equally old PHP release, so extraction is direct database work. OpenCart 2 and 3 are the common starting point, with a well understood schema and usually a modification stack that needs inventorying. OpenCart 4 was a substantial rewrite and extracts more cleanly. The price lands in much the same place either way.
No, and it is often the clearest case for moving. Climbing from 1.5 to OpenCart 4 is effectively a rebuild, because extensions and theme work do not carry forward across that distance. Both roads are a rebuild. Only one of them ends the upgrade cycle for good.
No. Redirects and SEO URL mapping are part of the migration here. It is worth asking anyone else the same question, because the large automated tools price 301 redirects, SEO URL migration and category to collection mapping as separate paid options. A quote that says SEO preserved without listing those is quoting a smaller job than the one you need.
Yes. A named project manager runs the migration, chairs the weekly call and is on the launch. They are the same person for the thirty days after launch. You are not passed between a salesperson, a migration operator and a support inbox.
Our Shopify Partner Directory listing carries a 5.0 rating across 567 reviews and we have been a Shopify Partner since October 2021. That page is public and we did not write it, so check it before you speak to us. Migration is listed there as one of our named specialities rather than something we also do.
No, and be careful with any page that says Shopify has customisable URL structures. You control the handle at the end of the address. You cannot remove or rename the fixed prefixes Shopify puts in front of products, collections, pages and blog articles. So an OpenCart keyword that sat at the root of your domain cannot sit at the root of your Shopify domain. It gets a redirect instead, which is why the redirect map matters more here than on most replatforms.
Because most of them are quoting different jobs. A quote built around running an automated tool covers the records and stops there. It does not include resolving your option values into variants with real prices, apportioning product level stock, building a redirect map when SEO URLs were never enabled, rebuilding the storefront, or reconnecting the systems behind it. Ask any quote which of those five it includes and the range usually explains itself.
Checked against the source
We read ten OpenCart migration pages while writing this one, including the two largest migration tools. These four claims did not survive a check against the documentation of the companies making them.
Passwords
One tool page answers yes to whether customer passwords migrate from OpenCart to Shopify, and a few questions later says accounts cannot be moved and you must send invites. Their own help centre settles it: they cannot migrate passwords to hosted platforms, Shopify included. The honest version has a footnote. On Shopify Plus, Shopify support can whitelist a legacy hashing algorithm and import the hashes. That is an enterprise plan and a support ticket, not something any migration app does, and it is not what that page is describing.
May 2024
The same page instructs you to install Shopify Product Reviews before migrating reviews, and notes that it is free. Shopify removed that app in May 2024 and existing reviews stopped displaying. Reviews now go to Judge.me, Loox, Yotpo or a review metaobject.
+$29
Creating 301 redirects is a paid extra. Migrating category and product SEO URLs is another paid extra. Turning categories into collections that keep their relationships is a third. A quote that says SEO preserved without naming those is quoting a cheaper job than the one you need.
Hosted
One agency page lists a hosted cart with an SSL among OpenCart pros. OpenCart is self hosted, which is the entire reason merchants leave it. The same page gives OpenCart a hundred variation limit, which is a retired Shopify limit, and still mentions Magento and BigCommerce in the body copy.
Step 3
One agency guide instructs you to open the Shopify App Store and install a plugin named after the agency itself. That agency publishes five Shopify apps and not one of them migrates anything. The remaining steps are another company wizard with the brand name swapped, down to the wording of a paid option they do not sell. The same page then tells you to skip agencies and use a tool for under a hundred dollars, two paragraphs above calling itself the most trusted migration company.
Start here
Send us your store address and we will come back with what moves, what needs rebuilding and what it costs. We will tell you which of the two URL situations you are in before we quote. If you are better off staying on OpenCart we will tell you that instead.
Our OpenCart to Shopify migration service covers the catalogue, the options rebuilt as real variants, the customers, the order history, the extensions that need replacing, and the redirects. You keep trading on OpenCart until the day we cut over.
