Custom Cart to Shopify Migration

There is no vendor to call, no version number, no support contract and no upgrade path. When something breaks you find whoever is available and they read the code until they work it out. That is not a criticism of the system, which has probably paid for itself many times over. It is a description of where you are.

Moving that to Shopify is a different project from moving off a named platform, and most of what you will read about it is written as though it were the same.

Search for this and the first result will offer to migrate your custom cart from a CSV file.

Read that again. The entire premise is that you already have a clean export of your products, customers and orders, correctly structured, ready to upload. If you had that, you would not be reading this page. Producing a correct, complete export from a database nobody documented is the migration. Everything after it is routine.

The same is true of the other promises. Every migration page in this category lists 301 redirects as a feature. None of them explains how you build a URL inventory when there is no route table to read, no sitemap that reflects reality and no developer who remembers why the category pages have three different URL patterns.

So this page is about the part that is actually hard.

The first phase is not building anything. It is establishing what exists.

The database. Where it lives, what access still works, and what the tables actually mean. A custom cart has no entity relationship diagram, so product, variant, price, customer and order structures get identified by reading the schema and then testing assumptions against the live site. A table called prod_opts might be variants, or might be a discontinued feature from 2017 that still has rows in it.

The extraction route. Direct SQL against a copy is the clean version. Where database access has been lost with the developer, an authenticated crawl of the live site becomes the fallback, because a page that renders a price to a logged in customer is evidence of that price whether or not you can reach the table behind it.

The hosting. Frequently the least documented thing of all. Who has the account, what the server actually runs, whether anything else is running on it, and what happens to email and DNS at cutover.

None of this is glamorous and all of it decides the schedule.

This is the part that catches people out, and it is why a custom cart migration cannot be scoped from a data export alone.

In a packaged platform, pricing rules are configuration. You read them out. In a custom build, they are code. The rule that a particular account gets a different price above a certain quantity, or that a product cannot be ordered in fewer than a case, or that orders above a value need internal approval, is very often an if statement written years ago by someone responding to a phone call.

None of it exports. It gets recovered three ways: by reading the application code where it is legible, by interviewing the people who take the orders, and by analyzing order history for behavior the data cannot otherwise explain. A customer who has never once ordered fewer than twelve of something is telling you about a rule.

We budget for this explicitly, because the alternative is discovering it after launch from a customer who has just been quoted the wrong price.

Your rankings live in URLs you cannot list. That is the SEO problem in one sentence.

The inventory gets assembled from whatever still exists. Server access logs are the best source, because they show what was actually requested rather than what someone intended to publish. Google Search Console export shows what earns impressions. Any sitemap is a starting point rather than a truth. A full crawl finds what is linked. Archive snapshots find what used to be linked and may still hold links from other sites.

Those sources get merged, deduplicated and ranked by value, and then mapped to Shopify's fixed path structure. Shopify does not let you invent arbitrary URL shapes, so some patterns map cleanly and some need a decision about what matters. Making that decision deliberately, against traffic and link data, is the difference between a migration that holds its rankings and one that explains a drop afterward.

Shopify models B2B as companies, with company locations underneath them and contacts attached. If your custom cart has a flat customer table with a wholesale flag and some pricing columns, that structure has to be rebuilt rather than mapped across.

Most of the real work is in the shapes that do not transfer cleanly. A buying group with several ship-to sites. A parent account whose branches each have their own terms. A contact who buys for two different companies. Those all exist in Shopify, and they exist differently from how a bespoke system almost certainly did them.

Customer-specific pricing moves into catalogs, and there is a plan constraint worth knowing before anyone designs around it. Shopify's own documentation states: "On the Basic, Grow, and Advanced plans, you can assign up to 3 active catalogs across all your B2B markets. The Shopify Plus plan offers an unlimited number of catalogs and direct assignment to companies and locations."

If you have forty accounts on negotiated pricing, that sentence decides your plan.

Ask what your custom cart integrates with and you will get a short answer. Then the migration starts and the list grows.

The common ones are an ERP or accounting system, a warehouse or third party logistics provider, a CRM, a tax engine, carrier rating, EDI to larger customers, and punchout to procurement systems. The awkward ones are the scripts. A nightly job that writes a file somewhere. A webhook nobody remembers configuring. A report that finance receives every Monday and would notice immediately if it stopped.

On a custom build the storefront is frequently the integration hub rather than a participant in it, which means those flows do not simply reconnect to Shopify. They get rebuilt, usually with the ERP taking the central role the website used to hold. Mapping every flow before cutover is not optional, and it is the part most likely to be underestimated.

Every other migration we do can be scoped from the outside. A Magento project has a known data model, a documented export, a predictable extension ecosystem and a published end of life date. We can look at a Magento store and quote it.

We cannot do that here, and neither can anyone else. A fixed price quoted against an undocumented system is either padded heavily enough to cover the worst case or it is a number that will move. Both are worse for you than the honest version.

The honest version is a paid discovery phase that produces the specification. Blueprint is that engagement: the schema mapped, the business rules documented, the URL inventory built, the integration flows drawn, and a plan with a real number attached. It is yours whether or not you build with us, which is the point. If you take it elsewhere, it still works.

After discovery, the migration itself is scopeable like any other, because by then it is no longer undocumented.

Full data migration of products, variants, customers, pricing and order history, extracted from your database rather than from an export you were supposed to produce.

Business rules rebuilt in Shopify after being documented rather than guessed at, including minimums, pack sizes, account pricing and approval workflows.

A B2B account structure using companies, company locations and contacts that matches how your customers actually buy.

A complete URL inventory and 301 map, built from logs and search data rather than from a sitemap that may never have been accurate.

Integrations rebuilt with the ERP as the system of record, including the scripts and scheduled jobs nobody had written down.

A parallel environment and a cutover plan with a rollback, so go live is a DNS change rather than an event.

Four questions, and the answers tell you quickly whether they have done it before.

How will you extract the data if the database credentials are gone. How will you build the URL inventory without a sitemap. Where do you expect the pricing rules to live, and how will you find them. And what happens to the nightly job that sends the file to the warehouse.

A vendor who answers the first one with "you provide a CSV" is quoting a different project from the one you have.

Bring whatever you have. Access to the site, access to the server if it still exists, a rough idea of how many customers are on negotiated pricing, and the names of the people who take orders by phone. That last one matters more than it sounds.

Book a strategy session, or start with a Blueprint, the paid discovery engagement that produces the specification this project needs before anyone can price it honestly.

Uncap has been a Shopify Platinum Partner since 2013, and migrations from Magento, BigCommerce, WooCommerce and ten other platforms sit alongside this one.

Plenty of custom stores started life on an open source cart and were modified until the original platform was hard to recognize. None of the platforms below has a page of its own on this site, and the method on this page applies to each of them: establish what the database holds, recover the rules from the code, build the URL inventory, then migrate.

• Drupal Commerce to Shopify migration. Commerce built on the Drupal content management system, where the catalog and the site content share one database and custom modules usually carry the business rules.
• PrestaShop to Shopify migration. A PHP cart extended through modules and theme overrides, so the installed modules get inventoried before anything is exported.
• OpenCart to Shopify migration. A lightweight PHP cart where changes are often made through OCMOD modifications or direct edits to core files, which is why the code gets read rather than assumed.
• osCommerce to Shopify migration. One of the original open source carts, still running long-lived stores whose code has been patched for years.
• Zen Cart to Shopify migration. A descendant of osCommerce with the same history of long-running, heavily modified installs.
• VirtueMart to Shopify migration. The ecommerce extension for Joomla, where the store shares its users and content with the Joomla site around it.
• Sylius to Shopify migration. An open source ecommerce framework built on Symfony, usually chosen for bespoke builds, so most of the business logic is code written for that one company.
• Spree Commerce to Shopify migration. An open source Ruby on Rails platform, typically extended with custom Rails code and bespoke integrations.
• Saleor to Shopify migration. A headless, GraphQL-first platform built in Python and Django, where the storefront and the commerce engine are separate codebases to inventory.
• Medusa to Shopify migration. Open source headless commerce built in Node.js, usually paired with a custom storefront and custom modules.