Moving a catalog off your old platform

Nobody migrates a catalog for fun. It happens because a platform priced itself out, or couldn’t do the thing you needed, or the relationship soured. Whatever the reason, the mechanics are less mysterious than vendors make them sound: a bulk import, an ERP feed, and a small adapter that maps one shape to another.

The anatomy of a catalog move

Strip a migration to its parts and there are only three:

1. Get the data out. Export the catalog from wherever it lives — the old platform, a spreadsheet, or the ERP that’s really the source of truth. This is where owning your database pays off: exporting rows you control is trivial; reverse-engineering a SaaS export format is where weeks disappear.
2. Reshape it. The old field names, category structure, and option model won’t match the new one. A small adapter script maps columns, normalizes units, and flags the rows that don’t fit. This is the actual work, and no importer erases it.
3. Load it. Push the reshaped data through a bulk import endpoint, in either replace-everything or upsert-what-changed mode, and reconcile what failed.

Anyone promising a one-click importer is quietly assuming your data already matches their model. Real catalogs never do. The honest framing is: the tooling makes steps 1 and 3 fast, and step 2 is a script you or a partner writes once.

The ERP is usually the real source

For B2B especially, the storefront isn’t where the truth lives — the ERP is. Pricing tiers, inventory, customer-specific catalogs, and quoting logic all originate there. A migration that copies the storefront and ignores the ERP feed just moves a stale snapshot.

The durable pattern is an ongoing feed, not a one-time dump: the ERP posts catalog and inventory changes to a bulk endpoint on a schedule, and the store stays in sync. If your ERP can emit JSON or CSV over HTTPS, this is a solved problem. The details — gzip the payload, cap the batch size, make the load idempotent so a retried feed doesn’t duplicate — are exactly the structured-contract disciplines that make a store agent-ready too. Migration and agent-readiness turn out to want the same plumbing.

Where the real work hides

• Option and variant models. Every platform models size/color/material differently. Mapping one to another is the single most underestimated task.
• URLs and SEO. If product URLs change, you need redirects, or you throw away years of ranking. Plan the redirect map before launch, not after.
• Media. Images often live somewhere separate and need to be re-hosted and re-linked, which the catalog export rarely handles.
• The long tail. The last 5% of products — the weird ones, the bundles, the discontinued-but-still-linked — take as long as the first 95%. Budget for them.

When it’s bigger than a script

Sometimes the catalog move is the small part and the real project is a platform change with integrations, redesign, and data cleanup underneath. That’s a different animal — a B2B replatforming effort, with discovery and staging and a cutover plan — and pretending it’s a weekend import is how migrations go sideways. Knowing which one you’re actually doing, early, is most of the battle.

How Wardenclyffe handles import

The Wardenclyffe AI Engine ships a bulk import endpoint built for the anatomy above: it accepts gzip/brotli/deflate bodies up to 200 MB, runs in replace-by-product or upsert mode, and loads idempotently so a re-sent ERP feed doesn’t create duplicates. There’s no turnkey “migrate from platform X” button, and we won’t pretend there is — but the import side is fast and predictable, which leaves your effort where it belongs: on the adapter that only you can write, because only you know what your data means. Our own sample store, friskycorset.com, was loaded exactly this way.