Catalogue quality: the audit before the migration

Migration quotes get written against a product count. Fourteen thousand products, so many weeks. The count is the wrong variable, because the platform does not care how many rows it imports — a bulk import runs the same whether the descriptions are good or empty. What costs money is the subset of rows a machine cannot resolve, and that subset is invisible until somebody counts it.

Here is the shape of it. A product with a missing SKU is not a data problem on the old platform, where nothing enforced SKUs. On the new one it is a stock sync that silently drops a line, a 3PL that cannot receive the order, and an afternoon of someone reconciling by hand. Multiply by however many rows are like it. That number is knowable in a morning and almost nobody produces it before signing.

The audit also changes what you build. A catalogue where 60% of products have one image and no lifestyle shot does not need the theme with the gallery. Knowing that before design starts is worth more than knowing it during UAT.

The list of products you are not migrating is the highest-value artefact of the whole project, and the most politically difficult. Every discontinued line, every one-off, every product that exists because someone added it in 2019 and nobody deleted it — each one carries a description to check, images to resize, a category to assign and a redirect to write.

The objection is always the same: someone might search for it. Sometimes true, and the answer is a redirect to the collection or the successor product, not a live page for something you cannot sell. A 404 on a product nobody has bought in two years costs you nothing. A thin, image-less page for it costs you a slot in a crawl and a reason for a shopper to leave.

Run the cut as three buckets rather than a debate. Migrate and improve: the products that earn revenue or traffic. Migrate as-is: everything currently selling that is not worth rewriting. Do not migrate, redirect instead: the rest. Get the merchandising lead to sign the third bucket, because they are the one who will be asked about it later.

Some defects announce themselves at import. The ones worth auditing are the ones that import perfectly and fail later.

Option names and values. Shopify builds variants from options, and the number of options a store may use is set per shop — the API exposes it as Shop.resourceLimits.maxProductOptions rather than hardcoding a figure, so check your own store rather than trusting a blog post. What catches people is not the ceiling but the semantics: a legacy catalogue that used a fourth option for "Pack size" has to express that as a separate product, a metafield, or nothing.

Variant count per product. Shopify's own documentation notes that when you query a single product at the root of a GraphQL query you can fetch up to 2,048 variants, which is a useful signal of the order of magnitude the platform is built around. A configurable product with tens of thousands of theoretical combinations is not a variant problem, it is a configurator problem, and it needs deciding before migration rather than after.

Handles. Shopify generates a handle from the title, lowercased, with whitespace and special characters replaced by a hyphen. If your old URLs were built from a different rule — and they were — then every product URL changes unless you set handles explicitly. Decide early: keep the legacy path as the handle where you can, and redirect the rest with urlRedirectCreate.

Rich text in descriptions. Old descriptions carry tables, inline styles, font tags and absolute image URLs pointing at the platform you are leaving. They will import. Then the images 404 six months later when the old host is switched off, and the inline styles fight your theme on mobile. Strip and re-mark-up as part of the migration, or accept that you are inheriting somebody else's CSS.

Category and taxonomy. Shopify has a standard product taxonomy, and populating it properly feeds search, feeds and market-specific tax treatment. A migration is the one moment when assigning it is cheap, because you are touching every product anyway.

The instinct is to fix data during the migration, in the transform step, because that is where the developers are. Resist it for anything a merchandiser can do.

A transform script that normalises "navy" is a rule that has to be written, tested, reviewed and maintained through three rehearsals, and it only ever runs once. The same fix done in the old admin by the person who owns the catalogue is permanent, visible, and tested by them. It also means the two systems agree during the parallel-running period, which matters more than anyone expects when you are comparing exports at 2am.

The exception is anything mechanical and reversible: casing, trimming whitespace, deriving a missing handle from a title, mapping one closed vocabulary to another. Put those in the transform, keep the mapping in a file somebody can read, and re-run it every rehearsal so the script is exercised as often as the import is.

When you do import, use the bulk path rather than looping the API. Shopify's bulk import flow stages a JSONL file — one set of mutation variables per line — and runs it asynchronously. The documented constraints are worth knowing before you design around them: the JSONL file cannot exceed 100MB, the operation has to complete within 24 hours, and from the 2026-01 API version each app can run up to five bulk mutation operations per shop simultaneously, where earlier versions allowed one of each type at a time.

The part that matters for an audit is the error reporting. Failures come back line by line in the output file, each with the line number from your input, and the operation as a whole only fails on something systemic. That means a dry run gives you a defect list keyed to the source row — which is the same list your spreadsheet audit should have predicted. If the import's error file finds classes of problem your audit did not, the audit was not thorough enough, and that is the signal to go back rather than press on.

Run it against a rehearsal store at least twice before the real cutover, and diff the counts: products in, variants in, images attached, redirects created. A migration is judged on numbers matching, not on a site that looks right.

Not every data problem is worth solving before launch. Rewriting every description is the classic trap — it is a six-month content project wearing a migration costume, it blocks a cutover that has a commercial deadline, and the descriptions for your long tail will not move a number. Migrate them as they are, fix the top few hundred by revenue, and put the rest on a rolling schedule after launch.

Equally, do not build a PIM because the audit was painful. A PIM is a reasonable answer to a governance problem that recurs, not to a one-off clean-up, and buying one mid-migration means two implementations at once. If the audit showed that four teams edit product data with no agreed ownership, the cheap fix is writing down who owns which field — and Shopify metafield definitions with validation will enforce more of it than people assume.

We would rather spend your budget on the redirect map and the images than on either of those. Those two are the things that are expensive to retrofit and visible to customers on day one.

• Shopify migration services
• The migration dry run: rehearsing a cutover
• Product data governance: who is allowed to change what