Your Google Shopping feed, moved intact.

Moving a Google Shopping feed to a new platform without resetting your item history

If your store advertises on Google Shopping, the product feed is the most fragile thing in a replatform, and it is the thing most migration quotes wave through in a single line. Products, customers and orders can be checked after the fact and fixed. A feed that is rebuilt carelessly hands Google a brand new set of products under new identifiers, loses the performance history attached to the old ones, and can take the whole account down to disapprovals in a few days. This guide sets out what actually breaks, the order the work has to be done in, and the traps that only show up once money is already moving through the account.

The short answer

Google does not identify your products by name, by URL or by barcode. It identifies them by a three part key: language, feed label and offer ID. Change the offer ID and you have not updated a product, you have created a different one. The old item stops being updated and eventually drops out; the new item enters review as a stranger.

Shopify’s own Google & YouTube channel builds offer IDs in a fixed format, shopify_<country>_<productId>_<variantId>, and you cannot change them. So if the store you are leaving used its own product codes as feed IDs, which most non-Shopify feeds do, the native channel cannot keep them. Preserving them needs a feed app that can submit the SKU as the product ID, and a catalog where each SKU has been set to the legacy feed ID before the first sync. That is the whole trick, and everything else in this guide is sequencing around it.

What is actually at stake

Merchants usually hear “the feed will be rebuilt” and think of it as a formatting job. These are the things that are attached to the offer ID and travel with it or die with it.

What is attached to the offer ID	If the ID is preserved	If the ID changes
Item level performance history in Google Ads	Continuous, the same item keeps reporting	Starts at zero, historical rows orphaned under IDs that no longer exist
Product review and rating matching	Unaffected	Re-matched by GTIN where one exists, lost where one does not
Listing group bids keyed on item ID	Keep matching	Fall into the catch-all group, usually at the wrong bid
Review status	Item is already approved, edits are re-checked in minutes	New item, new review, up to three to five business days
Free listings and Shopping tab presence	Uninterrupted	Gap while the new items are reviewed

The second risk is price. Google treats a mismatch between the price in the feed and the price on the landing page as a policy problem, not a data problem, and it can suspend an item or the account. A migration that changes prices, even slightly, and then lets a stale feed keep advertising the old ones is not a data quality issue. It is an account risk.

The clock you are already on

The moment the new store goes live, the old feed starts to decay, and it decays faster than most plans allow for. On a recent Weebly to Shopify move we measured the old Merchant Center feed on the day after launch. Every link and image link in it pointed at the old platform’s paths. The links still worked because the 301s were in place, but the image URLs returned 404 the moment the old site stopped serving them, and 295 of 1,370 matched rows already carried a price that no longer agreed with the storefront. Google re-crawls items continuously, so those rows were being disapproved a few at a time, every day, for reasons that read as “image not available”, “price mismatch” and “page unavailable”.

This is why the “brief parallel run” that most migration plans promise is shorter than it sounds. The parallel run is real and it is worth having, but the window is set by how quickly Google re-crawls the old items, not by when the project plan says the feed work starts. On any store that advertises, the feed belongs in the first days after launch, not in a tidy-up phase at the end.

Three routes, and what each one costs you

Route	Offer IDs	What it costs	When it is right
Shopify’s Google & YouTube channel	Rebuilt as shopify_US_<productId>_<variantId>, not configurable	Item history resets, new items go through review, item-level bids need rebuilding	Stores that never advertised, or whose Shopping history is not worth protecting
Feed app submitting SKU as the product ID	Preserved, if the SKUs are set to the legacy IDs first	A monthly app fee, and a SKU discipline for every product added from then on	Any store with real Shopping spend and item-level history
Leave the old feed running	Preserved, but pointing at a store that no longer exists	Progressive disapprovals, dead images, price mismatches	Never, beyond the first few days

The app we use for the second route is Simprosys Google Shopping Feed, because it offers SKU as the product ID as a first-class setting, reads Shopify metafields for the Google attributes, and is priced sensibly for a catalog of a few thousand products. The important part is not the brand of app. It is that the product ID format is chosen once, before the first sync, because changing it afterwards creates a fresh set of items and undoes exactly what you were protecting.

Catalog preparation, before anything is connected

The feed app can only submit what the store holds, so the store has to be made to match the old feed before a single item is sent. This is the part that is invisible in a quote and is most of the actual work.

• Match the old IDs to the new products on a stable key. Not on titles. On the move described above, the old feed’s link column contained the legacy platform’s product ID, and matching on that was exact. An earlier pass that matched on product titles had produced 29 wrong joins, which would have put one product’s advertising history onto another product.
• Write the legacy ID into the SKU, and keep the old SKU. Migration tools leave placeholder SKUs behind. Those are replaced by the legacy feed ID, and the previous value is kept in a metafield so the whole operation can be reversed.
• Fill every blank SKU and resolve every duplicate. A feed app that submits the SKU as the ID will skip a variant that has no SKU, and two products sharing one SKU is two products fighting over one item.
• Repair the GTINs. Spreadsheets drop leading zeros from UPCs, so barcodes that fail the check digit have to be repaired where they can be and cleared where they cannot. Cleared is better than wrong: an invalid GTIN is a disapproval, a missing one is not.
• Rebuild the apparel attributes. Gender, age group, color and size are required for clothing and accessories, and they almost never survive a migration. The old feed usually still holds them, so they can be written back into metafields the feed app reads.
• Decide what should not be advertised. Gift cards, and anything in a restricted category, are excluded deliberately rather than discovered later through a policy strike.

One thing to tell the merchant before the SKU rewrite: order line items and packing slips will show the legacy code as the SKU from then on. In practice this is an improvement, because it is the merchant’s own catalog number rather than a tool’s placeholder, but it is a visible change and it should not be a surprise.

The order of operations

Sequence is where feed migrations go wrong, because several of these steps are irreversible or destructive if taken in the wrong order.

1. Get read access first. Merchant Center, Google Ads, Search Console and Analytics. Half the decisions below cannot be made without seeing what is actually configured.
2. Inventory the existing feed. The data source type, its feed label, its language and country, its fetch schedule, and the exact ID format it uses.
3. Fix the website claim before anything else. See the trap below. This is the step most likely to take the account down if it is done casually.
4. Prepare the catalog as above, with a backup taken first and a restore path tested.
5. Install the feed app, set the product ID format, and only then let it sync.
6. Verify a sample in Merchant Center by ID. Open five known items and confirm the link, image, price and attributes are the new store’s.
7. Point the campaigns at the new items before removing anything. See the feed label trap.
8. Confirm the new items are serving and taking impressions, usually the next day.
9. Only now delete the old data sources, and do it the same day, before their next scheduled fetch.
10. Fix conversion tracking, which has usually been dead since go-live.
11. Reconcile shipping and tax in Merchant Center against what checkout actually charges.
12. Watch the disapprovals for two weeks and clear the residue.

The traps

Changing the store address drops the claim

A migration usually changes the canonical domain, often from www to the apex. Merchant Center will let you edit the online store address, and it warns, correctly, that the claim will be lost and the products will be disapproved until the site is claimed again. If nobody in the account is a verified owner of the domain in Search Console, that claim may not come back quickly, and the account is advertising nothing in the meantime.

The safe order is to make one of the Merchant Center users a verified owner of the domain in Search Console first, using a DNS TXT record, and only then change the address in Merchant Center. Done that way the new address verifies automatically and the claim comes back immediately. Keep every verification TXT record in place afterwards, including the old one: each record belongs to a different Google login, and deleting one revokes that login’s ownership.

The feed label decides whether anything you do is visible

A new data source gets its own feed label, and that label is part of the product’s identity. In the move described above the old sheets carried the label US and the new app source came in as USD-US-EN. The offer IDs were identical, but to Google these were two separate sets of products.

That is good news and bad news. The good news is that the parallel run becomes genuinely safe: the two sources cannot fight over the same items, and the old source’s nightly fetch stops being a threat. The bad news is that a Shopping campaign using the legacy “country of sale” feed selector will serve only the old label, so the new items sit there approved and invisible. The campaign has to be switched to use all available feeds, or to the new label explicitly, before the old sources are deleted. A data source’s feed label cannot be edited after it is created, so matching the old label is not an option.

Whichever source updated last owns the item

If two sources do submit under the same label and the same IDs, Google keeps the version from the source that was updated most recently. Leave the old scheduled fetch in place and it will take the items back overnight and push the dead URLs and old prices back into the account. This is why the old sources are deleted on the same day the new feed is confirmed, and before their next fetch, and why a copy of the old feed is archived first as the rollback.

Conversion tracking is usually already dead

The old platform’s Google tag left with the old platform. On most of these projects Ads conversions have been recording nothing since go-live, which nobody notices while the campaign bids to clicks rather than conversions. Reinstating it has its own trap: the Ads account often holds both a website conversion action and an Analytics import action, both marked primary, and turning tracking back on in two places makes every sale count twice and quietly corrupts the bidding.

The rule we work to is one instance per tag, and one place per job. Ads conversions and remarketing in one place, Analytics events in another, and the imported action demoted to secondary. It is worth verifying rather than assuming, because a shop platform’s pixel sandbox can hide a second tag instance that is firing page views you never configured.

Merchant Center has to agree with checkout

Shipping and tax in Merchant Center are quoted to the shopper before they reach the store, so a mismatch is both a bad experience and a policy exposure. Free shipping thresholds, weight bands, carrier services and any handling fee added at checkout all have to be reflected. A handling fee that exists at checkout and not in Merchant Center means every advert understates delivery.

Rollback

Because the offer IDs never change on this route, rollback stays simple throughout. Until the old sources are deleted, pausing the app’s sync is enough: the old source reclaims the items at its next fetch. After deletion, re-adding the archived copy of the old feed brings them back under the same IDs. Nothing is lost in either direction, which is precisely the property that a rebuilt feed with new IDs gives up.

What we do on a migration

Every store we move is asked early whether it advertises on Google Shopping, and if it does, the feed is scoped as part of the migration rather than as an afterthought. That means we inventory the existing feed and campaigns before launch, prepare the catalog so the legacy IDs can be preserved, run the two feeds in parallel for as long as it is useful, switch the campaigns over, retire the old sources at the right moment, and verify that conversion tracking, shipping and prices agree with the live store. The work is documented as it goes, with the before and after counts, so the merchant can see what changed and hand it to whoever runs their advertising.

If the store does not advertise, we say so and skip the app: the native channel is free, it is good enough for free listings, and there is no history to protect.

If you are planning a move and the store advertises on Google, start with the migration survey and tell us so in the notes. It changes the sequence of the project, not just the checklist. For the wider picture, see how our migrations run, the migration tools comparison, and the SEO evaluation we deliver after go-live.