Skip to main content

What We Learned Migrating 8,000 SKUs to Shopify

Large-catalog Shopify migrations expose problems that small stores can hide: redirect mapping, product modeling, crawl control, QA, and cutover sequencing.

Migrations9 min read
Samuel Noriega
By

Published

ShareXLinkedIn
Structured large Shopify catalog migration workflow

A migration with a few hundred products can sometimes survive manual cleanup. At roughly 8,000 SKUs, the same shortcuts turn into systems problems.

That was one of the clearest lessons from a recent large-catalog Shopify migration. The visible storefront was only one workstream. The harder part was making sure thousands of products, URLs, attributes, images, collections, redirects, analytics events, and search signals landed coherently.

This is not a replacement for our Shopify migration guide. It is the field-note version: the things that become disproportionately important once the catalog is large enough that nobody can reliably inspect every row by hand.

1. The redirect map becomes a data product

On a small migration, redirects can look like a spreadsheet task. At scale, they behave more like a data pipeline.

You need an inventory of old URLs, a deterministic rule for each URL class, explicit exceptions, and validation against the destination site before launch. Product URLs, collection URLs, content pages, old campaign pages, discontinued items, locale paths, and parameterized URLs rarely fit one universal rule.

Google's own site-move documentation recommends preparing an old-to-new URL mapping before the move, testing redirects, updating internal links, and monitoring the transition afterward. Shopify likewise recommends setting up URL redirects before moving the domain so bookmarked and externally linked pages do not fall into 404s; its migration guide also supports importing redirects in bulk.

For large catalogs, we treat the redirect map as something that can be tested, not merely reviewed. Our deeper technical process is documented in Shopify 301 redirects for large catalogs.

2. Product modeling decisions compound fast

A field that seems minor on one product can affect thousands of records after import.

Before migration, we decide what belongs in:

  • Shopify variants and options;
  • product or variant metafields;
  • tags used for internal workflows;
  • collections and merchandising rules;
  • metaobjects for reusable structured content;
  • search and filtering attributes.

The point is not to use every Shopify primitive. It is to give each piece of data one clear job.

Changing that decision after import is expensive because the change propagates into templates, filters, feeds, apps, analytics, search, merchandising, and potentially structured data. This is why we prefer to model representative product families before bulk loading the catalog.

3. Catalog size magnifies crawl problems

Eight thousand products do not necessarily mean eight thousand crawlable URLs.

Filters, sorting parameters, collection paths, market/language paths, pagination, variant parameters, and app-generated URLs can multiply the number of discoverable combinations. Google's ecommerce URL guidance explicitly warns against unnecessary alternate URLs for the same content and recommends consistent canonicals, internal links, and sitemap URLs.

For stores with complex filtering, the issue becomes more visible. Google's separate guidance on faceted navigation crawling explains why filter combinations can create a very large crawl space.

Our approach is to decide which URL families deserve organic visibility before launch, not after Search Console starts showing thousands of unwanted discoveries. The more detailed framework lives in our Shopify faceted navigation and crawl-budget guide.

4. QA has to be sampled intelligently

Nobody should pretend that manually opening 8,000 product pages is a serious QA strategy.

We build test sets around risk:

  • products with the highest organic traffic;
  • top revenue products and collections;
  • products with many variants;
  • products with unusual media or custom fields;
  • discontinued or replacement products;
  • edge cases in pricing and availability;
  • representative examples of every product family.

Then we add automated checks for the things machines are better at verifying: status codes, redirect destinations, canonical consistency, missing metadata, broken images, duplicate identifiers, structured-data validity, and inventory/data completeness.

The goal is not “test everything manually.” It is to make sure every pattern is tested and every high-risk URL is accounted for.

5. Launch day should be boring

A good migration launch is mostly the execution of decisions already made.

Before cutover we want the redirect map validated, the new sitemap ready, analytics tested, key conversion paths exercised, critical integrations checked, and the highest-value URLs reviewed. We also avoid combining unnecessary changes into the same event. Google recommends changing one major thing at a time when possible because it makes migration effects easier to isolate.

After DNS and storefront cutover, the work shifts immediately to observation: redirect errors, 404s, indexing behavior, sitemap processing, organic landing pages, conversion events, and integration failures.

6. The first month is part of the migration

A launch is not the finish line for search visibility.

Google notes that rankings can fluctuate while old URLs are recrawled and new URLs are indexed. For larger sites, processing can take longer. That is why the post-launch window belongs in the project plan rather than being treated as optional support.

We keep the old-to-new mapping, migration crawl, launch crawl, and Search Console observations together so an unexpected URL can be traced back to a decision instead of investigated from scratch.

Our next field note covers exactly that: what we watch during the first 30 days after a Shopify migration.

The main lesson

At 8,000 SKUs, the migration is no longer “move products and rebuild the theme.” It is a coordinated data, SEO, engineering, merchandising, and release-management project.

The teams that reduce risk earliest are usually the ones that inventory URLs and model product data before the storefront work gets deep. Theme implementation is important, but the architecture underneath it determines whether the launch is merely attractive or actually durable.

For the full planning framework, start with our Shopify migration guide. For a real project example, see the Llantas Cavazos migration case study.

ShareXLinkedIn

Keep exploring this topic

Deeper references from the Shugert library and the service that turns this work into a fixed scope.

Shopify migration

Planning a migration to Shopify?

We scope and execute migrations from WooCommerce, Magento, BigCommerce, custom platforms, and legacy Shopify builds. The destination can be standard Shopify or Shopify Plus, depending on the actual operating requirements.

On this page