Query the Date Google Migrates You to AI Max

Google Ads API v25.1, released Wednesday, August 19, 2026, is about as unglamorous as API releases get — a minor version, fully backward compatible with v25, that Google’s own team calls a drop-in upgrade. Yet its release-notes table quietly adds the only two fields in the release with real deadline consequences attached: Campaign.aca_migration_date_time and Campaign.broad_match_migration_date_time.

Here is why those two fields matter. Back in April 2026, Google announced that campaigns using Automatically Created Assets (ACA) and the campaign-level broad match setting will be auto-upgraded to AI Max “starting in September 2026” — a month-level window, with upgrades expected to conclude by the end of September. Until now, an advertiser managing dozens or hundreds of affected campaigns had no way to see anything more precise than “sometime in September.” v25.1 is the first API surface where a per-campaign migration timestamp can be queried at all.

This guide covers what v25.1 actually is (and is not), exactly what the two migration-date fields document — including a genuine ambiguity in Google’s own descriptions that you should not paper over — a runnable GAQL query, the September migration clock for ACA and broad match versus the delayed Dynamic Search Ads timeline, and a triage of everything else in the release.

First, the framing that matters for anyone triaging their sprint backlog: v25.1 is not a migration event for your API integration. Google’s release notes state it plainly: “The following new features and updates were added in Google Ads API v25.1. Minor versions like v25.1 don’t contain breaking changes.” Existing v25 integrations keep working untouched. The release landed exactly four weeks after v25 itself, which shipped July 22, 2026.

The one operational requirement, per the announcement post: “To use the new capabilities, you must upgrade your client libraries and client code.” The two migration-date fields do not exist in v25 or any earlier version — they appear only in the v25.1 delta. If your integration is pinned to an older version, the fields are invisible to you until you bump it.

That version discipline is a running theme — we made the same point about the v23.1 API release and the April 2026 core update: the API surface moves on a fixed cadence, and teams that lag versions quietly lose access to fields that matter. This time, what lagging costs you is visibility into a deadline.

The announcement post’s “New Features” section lists five highlights: Brand Lift and Conversion Lift measurement, BenchmarksService upgrades, Brand Sentiment Insights, loyalty-tier segmentation, and original conversion value. Not one of the five mentions aca_migration_date_time or broad_match_migration_date_time. The two fields appear only in the full release-notes delta table, with a one-line description: “Track the upcoming auto-migration to AI Max.”

That asymmetry is the reason this post exists. The five headline features are either allowlist-gated or additive reporting dimensions. The two unheadlined fields are open to every account on v25.1 and are attached to a dated, involuntary change to how your Search campaigns match and write ads. Anyone triaging the release from Google’s announcement post rather than the full delta table will read v25.1 as a routine minor bump and never learn that a per-campaign migration timestamp now exists.

The documented spec is thin but concrete. Per the Campaign RPC reference, both fields are type string and output only — you cannot set them via mutate operations; they only report what Google’s systems have determined for that campaign. The timestamp renders in the customer’s account timezone in yyyy-MM-dd HH:mm:ss format.

The tense problem Google left open

Here is where honesty beats a clean narrative. Google’s two primary descriptions of these fields do not agree on when the value appears. The release-notes summary is forward-looking: “Track the upcoming auto-migration to AI Max.” The RPC reference’s own per-field description is past tense: the field holds “the timestamp when the ACA campaign was migrated to AI Max.” One reading says the field pre-populates with a scheduled date you can plan against; the other says it fills in only after migration has executed, making it a historical record rather than an early-warning system.

No primary source we could find resolves this. Google also documents nothing about what the field returns for a campaign with no migration scheduled — do not assume null, empty string, or any specific sentinel. The practical move: query the fields against your own accounts and see what comes back today. If values are present ahead of September, you have a planning date. If they are empty, re-query on a schedule — the field is still the surface where the date will land, whichever reading turns out to be right.

Selecting the fields is standard GAQL — a plain SELECT ... FROM campaign against GoogleAdsService.Search or SearchStream, on API version v25.1 or later:

Two deliberate limits in that query. First, it filters only on campaign.status — not on either migration field. Because the generated field metadata for the two new fields had not appeared when we checked, whether they are filterable in a WHERE clause is unconfirmed; select them and filter client-side rather than gambling a scheduled job on an undocumented capability. Second, it selects across all enabled campaigns rather than trying to pre-guess which ones use ACA or broad match — let the field values (or their absence) tell you which campaigns Google considers in scope.

If you already run scheduled reporting against the API, this is a one-query addition. If you don’t, this release is a good reason to start — automating Google Ads API queries like this one is exactly the kind of low-effort, high-information monitoring that pays for itself the first time a platform deadline moves. Pull the fields daily into a sheet or warehouse, diff against yesterday, and alert on any change. Whichever way the population semantics resolve, a daily diff catches it.

The migration these fields report on was announced well before v25.1. Google’s April 15, 2026 blog post on the AI Max transition — updated June 11, 2026 — set the schedule: campaigns using Automatically Created Assets and the campaign-level broad match setting auto-upgrade to AI Max starting in September 2026, with Google expecting “all upgrades for eligible campaigns to conclude by the end of September.” Trade press has glossed the start as September 1 — Search Engine Land reported it that way on August 6 — but Google’s own post commits only to the month, not a day. Which is precisely the gap the new fields close: a per-campaign timestamp inside a month-wide window.

The same June update that reconfirmed the September window also did something that has confused a lot of coverage since: it delayed a different legacy feature. Dynamic Search Ads’ sunset and auto-upgrade — originally on the same September timeline — was pushed to February 2027. A reader who saw DSA headlines and concluded “the AI Max migration got delayed” would be exactly wrong about their ACA and broad-match campaigns. We covered the DSA delay to February 2027 separately; this table is the reconciled view of all three clocks.

Two more things the primary sources establish about what lands in September. Google frames the change as an in-place upgrade — “AI Max will be enabled with settings configured to mirror your legacy setup once the auto-upgrades are complete” — not a campaign rebuild. And no primary Google source documents an opt-out from the migration itself: the April post describes a voluntary-upgrade phase followed by automatic upgrades for remaining eligible campaigns, with advance in-account notifications. The new fields reveal the date; they do not give you a lever to avoid it. Worth noting for expectation-setting: Google’s own April post carries a footnoted claim that the full AI Max feature suite drove roughly 7% more conversions or conversion value at similar CPA/ROAS versus search term matching alone — that is a vendor-stated figure whose methodology the post does not disclose, so treat it as Google’s claim rather than an audited benchmark. For what actually changes in your ads once a campaign lands there, see AI Max’s text and brand-safety guidelines.

The rest of the release is genuinely substantial — it just carries no deadline. The most useful lens for a busy PPC lead is not “what shipped” but “what can I use today without asking Google for anything.” By that lens the release splits cleanly into four tiers: the two open-to-everyone migration fields, an allowlist-gated measurement build-out, additive planning and reporting surfaces, and housekeeping.

Note the pattern: everything Google chose to headline sits in the middle two tiers — gated, or additive with no clock attached. The top tier, open to everyone and deadline-bound, went unheadlined. Per the announcement itself, both lift-measurement features “are available only to allowlisted Google Ads accounts” — which makes the editorial choice stranger, not less: the item given top billing is one most advertisers cannot touch without asking Google first, and the fields every advertiser can query today were left out entirely.

The window between this release and the start of the announced migration is short. Here is how we are sequencing it for managed accounts — the same sequencing our paid media team applies whenever a platform sets an involuntary change against a date.

Looking forward, the more interesting signal is the mechanism itself. Google had communicated this particular forced upgrade as a blog sentence and an in-account notification; v25.1 puts the same schedule behind a queryable, per-campaign API field. We have not audited every earlier release for a comparable field, so we are not claiming a first — only that it is a notably different delivery mechanism for a deadline. If the pattern holds — and the broader AI Max transition playbook suggests several more legacy surfaces will eventually take the same road — then “watch the Campaign resource for new migration fields” becomes a standing item in API release triage. Teams that build the monitoring muscle now, on two fields, will already have the pipeline when the next forced migration ships its own timestamp. That is speculative on our part, clearly labeled — but it is the direction the tooling points.