- A migration splits cleanly into fields a model may rewrite and fields that have to arrive unchanged. Sort the columns before you touch anything.
- Product ids must stay consistent across updates. Regenerating them during a move is the quietest way to lose your ads history.
- Identifiers break in spreadsheets, not in databases. A twelve digit code opened as a number loses its leading zero and stops validating.
- Keep permanent redirects for at least a year, which is longer than most shops keep the old platform running.
- Run the whole thing on 50 products first. Everything that goes wrong at 2,000 goes wrong at 50, and costs nothing there.
The export lands as a single file: 2,000 rows, 41 columns, and a header row somebody named in 2019. The new platform wants 26 columns with different names. Somewhere in there are the variants, which the old system stored as separate rows and the new one expects nested, and a column called attribute_3 that contains sizes for half the catalogue and fabric composition for the rest.
This is the job people now hand to a model, and reasonably so. Reading a messy column and working out what it means is exactly the sort of pattern work that used to cost a fortnight. The mistake is handing over the whole file, because roughly a third of those columns are not text to be interpreted. They are identifiers, and an identifier that gets improved is an identifier that is wrong.
What does AI actually do well here?
Interpretation, normalisation and drafting. Three jobs where the input is ambiguous and a plausible answer is genuinely useful.
Interpretation is the column mapping itself. Given your 41 headers and the target's 26, plus twenty sample rows, a model produces a mapping and flags the columns it cannot place, and it will be right about most of them. Normalisation is the cleanup underneath: sizes recorded as M, Medium, med and MED collapsing into one value, colours in three languages resolving to one vocabulary, weights arriving in grams when half the file used kilos. Drafting is descriptions, which is the part everyone thinks of first and which matters least, because a thin description costs you a little conversion while a wrong price costs you a refund.
Category assignment sits alongside those and deserves its own care, since a mapped category drives both your navigation and your feed. We went through what that costs when it goes wrong in the anatomy of a feed rejection across two thousand rows.
The six columns to move byte for byte
Identifiers, money, stock and history. The rule is simple: if another system keys on the value, it is not yours to improve.
| Field | Rewrite allowed? | What breaks if it changes | How to verify after |
|---|---|---|---|
| Product id | Never | Ads history, analytics, feed matching, reorder links | Row count of ids present in both files must match exactly |
| GTIN, MPN | Never | Marketplace matching, and the product becomes a different product | Recompute the check digit; count values with the wrong length |
| Price, tax class | Never | Margin, refunds, and a mismatch against your checkout | Sum the price column in both files and compare totals |
| Stock quantity | Never | Overselling, which costs the customer rather than the order | Compare against a live count taken the same hour |
| URL slug | Only with a redirect | Rankings and every link anybody ever sent | Crawl the old sitemap and confirm each URL lands somewhere |
| Title | Carefully | Feed matching and search recognition | Spot check 20 against the old file for meaning drift |
| Description | Freely | Little, beyond tone | Read ten and check for invented specifications |
The last two rows are where judgement lives. A description can be rewritten because nothing else keys on it. A title cannot be treated the same way, because it is matched against by shopping surfaces and recognised by returning customers, and because a model asked to improve titles will helpfully append words that make two variants look like one product.
Why do identifiers break in a spreadsheet and not in a database?
Because a spreadsheet decides your identifier is a number. A twelve digit code beginning with a zero opens as an eleven digit number, the leading zero having been discarded as insignificant, and every downstream system now rejects it.
It is worth knowing what those codes are. A Global Trade Item Number comes in four lengths, 8, 12, 13 and 14 digits, and the final digit is a check digit computed with a modulo 10 calculation over the others. That last fact is the gift: you can verify a whole column mechanically. Recompute the check digit for every value, and anything that fails has been mangled in transit rather than mistyped by a supplier.
Two habits prevent almost all of it. Open the export as text rather than letting a spreadsheet guess column types, and store identifiers as strings everywhere, including in whatever intermediate file your tooling produces. If you must work in a spreadsheet, format the column as text before you paste, not after, because after is too late.
The same failure hits postcodes, phone numbers and any reference beginning with a zero. If your customer export goes through the same pipeline as your product export, check it with the same suspicion.
What happens to your URLs?
They change, unless you have deliberately arranged otherwise, and that is the part of a migration that costs traffic rather than money. Google's guidance on a site move with URL changes is a five step sequence, and the step people skip is the one that has to happen before anything else: build a mapping from every old URL to its new equivalent.
Assemble the old list from more than one place. Your sitemap misses pages nobody linked internally. Your analytics finds the ones that actually earn traffic. Your server logs find the ones that get requested by machines and old bookmarks. Combine those, and the list is longer than the count of products in your catalogue, because it includes categories, filters that got indexed, and the campaign landing page from two Christmases ago.
Three specifics from the same documentation are worth pinning to the wall. Use permanent server side redirects, meaning a 301 or a 308 response. Keep chains to three hops or fewer, since a chain built by redirecting the 2019 URL to the 2023 URL to the new one is exactly how a shop ends up at five. And keep the redirects in place for at least a year, which is the instruction most likely to be quietly broken by a business that cancels the old hosting after two months to save the subscription.
Expect movement afterwards. The guidance is explicit that significant changes bring ranking fluctuations while pages are recrawled and reindexed, with several weeks a reasonable expectation for a medium site. Plan the move for a quiet trading period rather than the week before your busiest month, and where the whole domain is changing, submit a change of address in Search Console.
Will the feed still work afterwards?
Only if the identifiers survived. The Merchant Center product data specification requires id, title, description, link, image_link, availability and price, and the id carries a rule that decides the whole question: use a unique value for each product, maximum 50 characters, and keep it consistent across updates.
Read that last clause next to what platforms do during a migration. Many assign their own internal identifier on import, and if you let the feed use the new one, every product looks new to the shopping surface. Performance history detaches. Any campaign structured around product ids stops matching. The fix is unglamorous: carry your old id into whatever field the new platform exposes to the feed, even if it is now a custom attribute, and check the exported feed rather than the admin screen.
Other specifics from the same page are worth checking in your export rather than discovering in a rejection email. Title is capped at 150 characters and description at 5,000. Availability accepts four values, in_stock, out_of_stock, preorder or backorder, so a platform exporting Available or Yes produces a file that fails on every row. Condition is required for used or refurbished goods. Price must match your landing page and your checkout, which sounds obvious until a currency or a tax inclusive setting differs between the two systems by a rounding step.
What about variants and structured data?
Variants are where the two systems disagree most, and where a model is most likely to invent a tidy answer. One platform stores each size as its own product with a parent reference; another stores one product with an option matrix; a third does both depending on which import you use. Decide the target shape yourself, write it down as a rule, and have the tooling apply the rule rather than infer it row by row.
The vocabulary for expressing that on the public side is standardised. The schema.org Product type carries sku and gtin alongside brand and offers, and expresses families through isVariantOf and hasVariant, with variants inheriting from the base model unless they define their own values. If your new templates emit that correctly, both search engines and the assistants your customers ask about products can tell that six rows are one shoe in six sizes rather than six shoes.
That is the moment to fix things you have been meaning to fix, because you are rewriting the templates anyway. Structured data, image descriptions and form labels all cost less to get right during a rebuild than to retrofit later, which is the same argument we made about what a shop should repair before a customer using assistive technology reaches checkout.
Who should do a product data migration by hand?
Anyone under about 200 products, and nobody above about 2,000. Between those numbers it depends on how consistent the catalogue already is.
Under 200 rows, a careful person with a spreadsheet and an afternoon beats any pipeline, because the failure modes of a catalogue migration are mostly one off oddities and a human notices those in passing. Over 2,000 rows the tedium wins, attention degrades around row 400, and the errors introduced by fatigue are worse than the ones introduced by a model. In the middle, the deciding question is whether your data is already regular. A catalogue where every product was entered the same way maps mechanically. One assembled over eight years by four people needs interpretation first, which is exactly the part a model does well.
Whichever route you take, the csv export is the artefact to preserve. Keep the untouched original file, dated, somewhere you will find it. Every intermediate version is disposable; the original is the only record of what you actually had, and you will want it the first time somebody claims a product used to say something different.
The nine checks before you switch DNS
Nine, because that is how many fit on one screen and none of them takes more than a few minutes.
Confirm the row counts match. Confirm the count of distinct ids matches. Confirm the price column totals agree. Confirm every required attribute in the product feed is populated on a sample of 50, and that the seven required attributes are present in the exported file rather than merely in the admin. Confirm the url mapping covers every URL from the old sitemap. Confirm the redirects return a permanent redirect status rather than a temporary one, which is a single command line check per URL. Confirm no redirect chain exceeds three hops. Confirm at least one product of each type renders correctly on a phone. Place a real order and refund it.
That last one catches a category of problem no data check reaches, because it exercises tax, shipping rules, payment and email templates in one pass. Shops that skip it discover the confirmation email is still branded for the old platform on the day real customers start receiving it.
The order of operations that survives contact
Fifty products, end to end, before anything else. Pick them deliberately: a simple product, a product with variants, one with a long description, one with an unusual character in its title, one that is out of stock, one on promotion, one with no image. Push those through the entire pipeline, export the feed, view the pages, place a test order.
Then compare rather than eyeball. Row counts on both sides. The sum of the price column. The count of distinct ids. The count of products with a valid identifier. Four numbers, computed twice, and any mismatch investigated before the full run. This takes twenty minutes and it is the only part of a migration that reliably catches the errors nobody predicted.
Sequence the full move by what breaks revenue soonest. Stock and price first, because those are wrong in a way customers feel immediately. Identifiers and URLs next, because those are wrong in a way you discover three weeks later when traffic drops. Descriptions and images last, because those are wrong in a way you can fix on a Tuesday afternoon without anybody noticing. Rewriting product copy is genuinely a good use of a model, and it is the one job that can wait until after launch, which is worth remembering when you are choosing what to spend the pre launch week on. We covered how much editing that copy typically needs in how much editing AI copy needs before it ships.
After the switch
Watch three things for a month. Crawl your old sitemap weekly and confirm every URL still resolves to something sensible, because a redirect rule that covers 90 percent of paths looks fine on the day and leaves the rest as quiet 404s. Watch the feed rejection count rather than the total product count, since a feed can be accepted with a third of the catalogue disapproved. And watch orders per day against the same period last year rather than against last week, because the week before a migration is never a normal week.
Set a calendar reminder for eleven months out, titled with the reason: the redirects are still needed. It is the single cheapest insurance in this whole exercise, and the only thing standing between you and a decision made in a hurry by whoever is paying the hosting bill next year.
Keep the old system readable for as long as you can afford, in whatever cheapest form is available, even a static database dump. The questions that arrive two months later are always about a specific order or a specific product, and answering them from an export takes minutes while reconstructing them from memory takes a morning. If you are still weighing where the catalogue should land, our comparison for merchants leaving a hosted platform sets out what actually transfers.
None of this argues against using a model for the work. It argues for pointing it at the right columns. The pattern recognition that maps a messy header to a clean field is genuinely valuable and genuinely tedious to do by hand. The same tool applied to a check digit produces a plausible number, and plausible is the one thing an identifier must never be.