Migrate a Custom Ecommerce Site to Shopify: Data, URLs and Cutover

When it makes sense to migrate a custom ecommerce site to Shopify

Migrating a custom ecommerce site to Shopify makes sense when most of your code is commodity commerce plumbing: cart, checkout, payments, tax, order admin, security patches. Shopify runs all of that as a managed service, so the engineering hours you free up go back into the parts of the business that actually differentiate you.

It is the wrong move when the custom behavior is the business. Contract pricing engines, product configurators and quote workflows can be rebuilt on Shopify, but you are rebuilding them, not migrating them.

The middle path is worth knowing about: a headless build keeps your own frontend and talks to Shopify for catalog, cart and checkout. It costs more than a theme-based store, so choose it for a reason, not by default.

What data moves to Shopify and what does not

Before touching a CSV, know which data has a native route into Shopify and which needs an API script or an app. This table is the scoping tool: every row that says "no native import" is engineering time on your quote.

Map your custom database to Shopify's data model first

Most migrations that go wrong fail at the mapping stage, not at the import button. Write a field-by-field map from your tables to Shopify objects before exporting a single row.

Here is a short export script that turns one-row-per-variant data into Shopify's product CSV. Only the first row of each product carries the title, description and image; the remaining rows add variants. Split the output into files under 15 MB.

import csv
from collections import defaultdict

rows = load_variants()  # your own DB export, one dict per variant

by_product = defaultdict(list)
for r in rows:
    by_product[r["product_slug"]].append(r)

cols = ["Handle", "Title", "Body (HTML)", "Vendor", "Published",
        "Option1 Name", "Option1 Value", "Variant SKU", "Variant Price",
        "Variant Inventory Tracker", "Variant Inventory Qty", "Image Src"]

with open("products_001.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.DictWriter(f, fieldnames=cols)
    w.writeheader()
    for slug, variants in by_product.items():
        for i, v in enumerate(variants):
            first = i == 0
            w.writerow({
                "Handle": slug,
                "Title": v["title"] if first else "",
                "Body (HTML)": v["html"] if first else "",
                "Vendor": v["vendor"] if first else "",
                "Published": "true" if first else "",
                "Option1 Name": "Size",
                "Option1 Value": v["size"],
                "Variant SKU": v["sku"],
                "Variant Price": f"{v['price']:.2f}",
                "Variant Inventory Tracker": "shopify",
                "Variant Inventory Qty": v["qty"],
                "Image Src": v["image_url"] if first else "",
            })

Run a test import with five to ten products first and open them in the admin. Price format (a dot, no thousands separator), the inventory tracker value and option names are where most first imports break.

Large catalogs have one more constraint to plan around. Once a store holds more than 50,000 variants, Shopify throttles the creation of new variants to 1,000 per day unless the store is on Plus. Check the current rule for your plan before you promise a launch date for a 100,000-SKU catalog.

Import products, then customers, then orders

The order matters because each step references the previous one. Orders point to products and customers; customers are matched by email. Importing out of order means re-linking data by hand later.

1. Products first. Orders reference SKUs and handles, so the catalog must exist before anything else.
2. Customers second. Deduplicate on email and phone before exporting. Shopify skips duplicate emails and phone numbers during import and keeps only the last profile for a duplicated email, so silent data loss is easy. Carry over marketing consent honestly: set Accepts Email Marketing to yes only for customers who actually opted in.
3. Orders last. There is no order CSV import in the Shopify admin, so history goes in through the Admin API or a migration app. Disable customer and staff notifications for the run so nobody gets an email about an order from two years ago.

Two details from Shopify's customer import documentation change your launch communications. First, passwords cannot be migrated, so every returning customer has to be invited to set a new one; plan that email. Second, the Total Spent and Total Orders columns are not imported, so lifetime value on a customer profile rebuilds only from the orders you import.

If your order history or catalog is too big or too irregular for CSV tooling, a scripted import over the Admin API with retry logic and a reconciliation report is the safer route. That is the kind of job covered by Netalith's eCommerce data migration service.

Keep your SEO: build the 301 redirect map before launch

Shopify fixes its URL structure: products live under /products/, collections under /collections/, pages under /pages/ and blog posts under /blogs/. Unless your custom site already used those patterns, almost every indexed URL changes, which makes the redirect map the real SEO migration.

Build the list from the sources that show which URLs matter: your sitemap, your database, Search Console performance data and backlink exports. Every URL with traffic or links needs a destination. Then check the constraints in Shopify's URL redirect documentation: the limit is 100,000 redirects per store (20,000,000 on Plus), and a redirect only fires from a URL that is currently broken. If an old path matches a live Shopify path, the redirect is ignored.

This script writes the import file and refuses the mistakes that cause silent failures:

import csv

mapping = [(p["old_path"], f"/products/{p['slug']}") for p in load_products()]
live_paths = {new for _, new in mapping}
seen = set()

with open("redirects.csv", "w", newline="", encoding="utf-8") as f:
    w = csv.writer(f)
    w.writerow(["Redirect from", "Redirect to"])
    for old, new in mapping:
        assert old not in live_paths, f"old path is also a live path: {old}"
        assert old not in seen, f"duplicate source: {old}"
        seen.add(old)
        w.writerow([old, new])

Redirects only work on requests that reach the Shopify store, so you cannot fully test them until the domain points at Shopify. Test the mapping on a staging domain with the same file, then re-verify on launch day by crawling your old URL list and confirming each one returns a 301 to a page that returns 200. Keep titles, headings and body copy unchanged where you can; changing URLs and content in the same release makes any ranking drop impossible to diagnose.

Rebuild custom features the Shopify way

Audit every custom feature and tag it one of four ways: native Shopify, an app, a custom app, or drop it. A surprising share of custom code is a workaround for something the old stack lacked and Shopify already ships.

Do this audit before you quote the project. The import is a few days of work; the custom features decide whether the migration takes weeks or months.

Plan the cutover so you can roll back

A safe cutover keeps the old site intact until the new one has proven itself.

1. Build and QA on the Shopify store behind its storefront password, with test orders through the full checkout and fulfilment path.
2. Announce a freeze window and stop catalog and customer edits on the old site.
3. Run a delta import: products changed, customers created and orders placed since your first export.
4. Lower the DNS TTL a few days ahead, so the switch and any rollback propagate quickly.
5. Point the domain at Shopify, import the redirect file, and crawl your old URL list to confirm every 301 lands on a 200.
6. Submit the new sitemap in Search Console and watch 404s, indexing and orders daily for the first two weeks.

Rollback is simply repointing DNS to the old site, which works only if that site stays running and unchanged. The real cost of a rollback is reconciliation: any order placed on Shopify in the meantime has to be copied back, so decide your go or no-go criteria before launch day rather than during it.

Get your migration scoped

If you want a second set of eyes on the data mapping, the redirect file or the custom-feature audit before you commit, send the details through Netalith's free quote form. Pricing is set to scope, so the more precisely you list data volumes and custom features, the more accurate the estimate.