Google Merchant API Migration: A No-Surprises Checklist

If your Shopping or Performance Max campaigns rely on an API-fed catalog, the Merchant API migration is a delivery dependency, not routine backend maintenance. Letting a legacy Content API connection reach its cutoff can interrupt campaigns that depend on its product feed.

The dangerous version of this failure is not always an obvious API error. Products may arrive through the new connection while feed labels, campaign structure, or bidding logic no longer match. Your migration is complete only when the new API writes the right product data and the campaigns consuming that data still behave as intended.

Confirm whether your account is exposed

Start in Merchant Center Next. Open Settings > Data sources and inspect the type shown for every product source. Any source marked Content API belongs in your migration inventory. Do not assume that an ecommerce app, scheduled file, or newer integration elsewhere in the account means the legacy connection has already been replaced.

For each Content API source, record:

• The Merchant Center account and data source name.
• The application, connector, platform, or custom code that writes the product data.
• The person or provider able to change and deploy that integration.
• How updates are triggered, including scheduled jobs and manual runs.
• The Shopping and Performance Max campaigns that consume the products.
• Every feed label associated with the source and what that label controls.
• The evidence you will require before declaring the migration complete.

If a third-party platform manages the connection, ask for more than a general confirmation that it supports Merchant API. You need four explicit answers: which connection will be replaced, when the change will reach your account, whether feed labels will be recreated or mapped, and whether you must reconnect anything inside Merchant Center Next. The provider may own the deployment, but you still own campaign validation.

The transition began in mid-2024, and the communicated migration path cited February 28 for beta participants and August 18 for other Content API users. Those month-and-day references are not safe planning dates without the applicable year and account context. Use the dated notice attached to your own account as the operative cutoff. If nobody can produce that notice, treat the connection as an active risk rather than assuming you have more time.

Preserve feed labels before moving product data

Feed labels can be part of your campaign architecture. They may separate inventory or support bidding decisions, yet they do not transfer seamlessly during this migration. That creates a misleading success state: the new connection works, products appear, and the technical ticket closes, but a label-dependent campaign no longer addresses the same inventory.

Build a label map before changing the connection. For each existing label, capture:

• The exact current value, including spelling and capitalization.
• A small set of representative products that should carry it.
• The campaign structure or bidding rule that depends on it.
• The value expected after migration.
• The person responsible for checking it in the advertising account.

Include products from every label and at least one product that intentionally has no label. That last case helps you distinguish a valid blank value from a failed transfer. Compare the same products before and after cutover instead of checking whichever items happen to be easiest to find.

Do not rename, consolidate, or reorganize labels during the API migration unless the old structure makes the cutover impossible. Combining cleanup with migration destroys your baseline: when inventory changes, you will not know whether the API, the new label design, or the campaign edit caused it. Move the existing behavior first, prove parity, and schedule cleanup as a separate change.

Run the migration as a controlled cutover

A useful migration plan separates preparation, technical cutover, and advertising validation. It also names the person who can stop or reverse the change. Use this sequence:

1. Assign two owners. The technical owner changes the integration. The paid media owner verifies labels, inventory coverage, and campaign behavior.
2. Freeze unrelated changes. Avoid simultaneous feed restructures, label renaming, and major campaign edits from baseline capture through validation.
3. Capture the baseline. Save the current data source type, label map, representative products, update process, and dependent campaigns.
4. Configure the Merchant API connection. Update the system that actually writes product data, then reconnect the data feed where the migration flow requires it. A code deployment alone does not prove that Merchant Center is receiving the new writes.
5. Preserve rollback material. Keep the previous configuration, mappings, and baseline evidence until validation finishes. Do not allow two uncontrolled connections to write conflicting versions of the same products.
6. Send a controlled update. If the integration permits it, change a representative product through the real production path. Choose a field whose before-and-after state is easy to verify.
7. Check every label path. Compare the representative products against the label map and confirm that dependent campaign structures still include the intended inventory.
8. Observe a scheduled run. A successful manual request does not prove that the recurring job, connector, or automation has been migrated.
9. Retire the legacy connection only after sign-off. Require approval from both the technical owner and the paid media owner.

Define rollback triggers before cutover. Missing labels, a test update that never reaches Merchant Center, or a campaign structure that loses its intended inventory are reasons to stop and investigate. A rollback should restore a known configuration, not blindly reactivate every old process.

Validate business behavior, not just API success

An authenticated request proves only that one request was accepted. End-to-end validation has three layers: the connection, the product data, and the campaign consuming that data.

Connection validation

• Confirm that Merchant Center Next shows the intended new data-source connection rather than the legacy Content API source.
• Verify that a deliberately changed product value arrives through the new path.
• Run or observe the normal scheduled process and confirm that it uses the same path.
• Record the time, product tested, expected result, actual result, and validator.

Product and label validation

• Check the same representative products captured in the baseline.
• Compare each expected label character for character.
• Confirm that intentionally unlabeled products remain unlabeled.
• Test an ordinary product update after the initial migration so you know the connection handles ongoing changes, not only the first import.

Campaign validation

• Inspect every Shopping or Performance Max structure that relies on a migrated feed label.
• Confirm that each label still selects the intended inventory and that no expected subset has become empty.
• Check that bidding logic tied to those labels still points to the right product group.
• Have the paid media owner sign off independently of the developer or integration provider.

Do not use immediate spend or revenue as your only acceptance test. Auction results vary, and business metrics can lag behind a configuration error. Structural checks – the right products, labels, and campaign relationships – reveal migration mistakes sooner. Performance monitoring should follow, but it cannot replace those checks.

Keep the validation record with the integration documentation. It should show the old and new connection, the label mapping, the test products, the scheduled-run result, the dependent campaigns, and both approvals. That evidence gives you a precise starting point if a later feed or campaign problem appears.

Key takeaways

• A data source marked Content API in Merchant Center Next is a migration dependency that needs a named owner.
• Moving products is not enough. Feed labels require an explicit before-and-after mapping because they may not transfer cleanly.
• Separate the API cutover from feed cleanup and campaign restructuring so you retain a useful baseline.
• Validate the new connection, a normal scheduled update, representative products, labels, and every dependent Shopping or Performance Max structure.
• Use the dated notice for your own account to determine the applicable cutoff rather than relying on an unqualified calendar date.

Open Merchant Center Next and inspect Data sources now. If Content API appears, assign a technical owner and a paid media validator in the same work item. Close that item only after a scheduled product update reaches the new connection and the label-dependent campaigns still address the inventory you intended.

References

• CrushPress.AI – Urgent: Switch to Google’s New Merchant API or Risk Ad Interruptions