Google is migrating Search campaigns to AI Max all through September, and the ones that came from ACA get copy rewriting left on
On September 1, 2026, Google started automatically moving Search campaigns still running Campaign-level Broad Match or standalone Automatically Created Assets into AI Max. There is no button to click and no per-campaign warning before it happens. The migration is rolling out gradually across the whole month, so an account can wake up on any given September day with some campaigns already migrated and others not, with nothing in the interface flagging it as an event.
This is part of a pattern this blog keeps running into: it is increasingly common for the text published on an ad account to have been written by someone other than whoever pays for it. With this migration, that pattern extends into Search, and it hinges on a configuration detail most accounts never looked at on purpose.
Two starting points, two different outcomes
Not every migrated campaign ends up in the same place, and that is the part worth checking closely.
Campaigns that came from Campaign-level Broad Match end up with Text Customization off, Final URL Expansion off, and Search Term Matching on by default. Brand lists (the inclusions and exclusions an account had configured) are preserved and move in-place with the campaign, so that control does not get lost in the transfer.
Campaigns that came from standalone Automatically Created Assets end up different: Text Customization on by default, Final URL Expansion off, and Search Term Matching on by default. Text Customization is the feature that gives Google permission to rewrite or adapt the ad's text. For this second group, the migration does not just change the matching engine underneath: it leaves copy rewriting active, without anyone having asked for it. It is the same underlying shift already visible in language targeting on Search: a control that used to require an explicit choice from the advertiser now resolves on its own, on the platform's side.
Google frames the move as an in-place migration "to equivalent settings" meant to minimize performance volatility. That is a reasonable description of intent, but it says nothing about whether the outcome is actually equivalent in any given account, and that assessment falls on whoever manages it.
How to check whether it already happened to you
Google published a GAQL query to detect migrated campaigns, and it is worth running in every account rather than assuming September has not reached it yet:
The query, as Google published it, selects campaign.id, campaign.name, campaign.aca_migration_date_time and campaign.broad_match_migration_date_time from campaign, filtering on both migration timestamps being greater than '1970-01-01 00:00:00'.
There is a detail in how this query is built worth flagging, because it changes what it actually catches: the two conditions are joined with AND, so it only returns campaigns that migrated for both reasons at once. A campaign that migrated only because of ACA, or only because of broad match, will not show up in that result as written. Covering the full set of migrated campaigns requires running the two conditions separately, not joined. This is not a claim that Google got it wrong, nor is there any way to know whether it was intentional; it is simply what the query, as published, returns.
What you can no longer create, and what stays alive a while longer
Since August 3, 2026, even before the migration began, creating new Campaign-level Broad Match or legacy standalone ACA configurations has been blocked. The block applies evenly across the interface, Google Ads Editor, and every API version: there is no alternate path to configure these entities from scratch.
API versions published after September 1, 2026 remove the legacy entities entirely; they do not even show up as an option. API versions already published before that date keep supporting them until their normal sunset, which lands around September 2027, when they are removed for good. Any integration that depends on these legacy objects has, then, a concrete window to migrate, separate from whatever happens to each individual campaign inside the interface. It is the same kind of clock already running for any account reporting off its own exports, as covered when Merchant Center changed its performance reporting: a history the platform can rewrite or discontinue stops being reliable if nobody saved it independently before the cutoff.
The exception pushed to 2027
Dynamic Search Ads is excluded from this round. Google rescheduled its migration for February 2027, between the 1st and the 28th, with pre-migration banners appearing in the interface during September 2026 and an official notice landing on January 15, 2027. Anyone running DSA campaigns has nothing to check on this specific front for now, beyond noting that the window is already set.
Who this is for
This matters, first, to anyone managing Search campaigns in accounts more than a year old, since that is where Campaign-level Broad Match or standalone ACA configured long ago and never revisited is most likely to be found. It is worth running the detection query (the two conditions separately, not the one Google published as-is) and noting which campaigns already migrated and to what configuration.
It matters in particular to anyone managing accounts that came from ACA, because there Text Customization ends up on by default: Google may be rewriting the copy of ads going into production without an explicit decision to allow it. Checking that setting and actively deciding whether to leave it on or turn it off is this month's concrete task.
It matters less, for now, to anyone running Dynamic Search Ads: that migration has been pushed to 2027 and there is still time to plan it calmly.
And it matters to any team operating accounts through scripts or custom integrations, because the legacy API clock runs in parallel to the interface one, with a different sunset (September 2027) worth tracking separately. It is the same discipline worth applying to any data feeding a marketing mix model: if a platform is going to discontinue an object your pipeline depends on, the integration has to move before the cutoff, not after.
Sources
Built with AI. Reviewed by humans. If any data point ages badly, blame the ecosystem, not us.