The Azure Copilot migration agent (ACMA), covered by InfoQ in March and documented on Microsoft Learn, is a conversational layer sitting on top of Azure Migrate: agentless VMware discovery with dependency maps and 6R recommendations, Cloud Adoption Framework-aligned Terraform or Bicep landing zone templates generated on request, and wave plans — all built from data you've already put into an Azure Migrate project. It doesn't execute anything; replication, test migrations, and cutover stay manual, in the Azure Migrate portal. For a sovereign migration specifically — the kind where the landing zone has to be right before wave one starts, not patched up after — that's precisely the planning work worth automating.
Two data categories, two different promises
ACMA's own common-questions page answers the residency question by splitting the agent's data into two buckets, and it's worth quoting both halves exactly as written:
For EU customers, both processing and storage of migration‑related data occur within EU regions. For all other geographies, Azure Copilot migration agent may process and store migration‑related data in any Azure region, depending on service architecture and optimization. This applies only to Azure Migrate related conversational data used by the agent.
Azure Migrate project data such as discovery metadata, assessment metadata, and project configuration is always stored in a region within the geography that you selected when creating the project. Azure Migrate doesn't move or store customer data outside of the region allocated, guaranteeing data residency and resiliency in the same geography.
Read side by side, the structure is clear: your underlying Azure Migrate project — the VM inventory, the assessments, the configuration — carries the older, stronger, geography-wide guarantee it always has. The new layer sitting on top of it, the Copilot conversation where you ask the agent to reason about that data and hand you a landing zone template, only gets the equivalent guarantee automatically if you're in the EU. Everyone else's "may process and store... in any Azure region, depending on service architecture and optimization" is not a residency commitment in the sense Azure Migrate's own FAQ uses that word two paragraphs later for the project data itself.
Why this is a gap worth naming, not a scandal
This isn't Microsoft burying something — it's documented plainly, in a preview feature's own FAQ, in language precise enough to quote. The gap is structural: ACMA is new, it's Copilot-based, and Copilot-based features generally inherit a different, more flexible regional processing model than a decade-old discovery service built explicitly around geography pinning. What's worth flagging is that the FAQ's phrasing — "this applies only to... conversational data used by the agent" — is doing real work. It's quietly conceding that the rock-solid promise you've relied on for Azure Migrate itself doesn't extend to the new interface for interacting with that data, unless you're specifically in the EU. A UK, Swiss, or Gulf-region customer building a sovereignty-conscious migration plan with ACMA is, by this FAQ's own wording, in the "any Azure region" bucket for every prompt and response in that planning session.
Separately, InfoQ's reporting noted the agent is "unavailable to tenants using Bring Your Own Storage for Copilot conversation history," without further explanation in that article. I haven't found that restriction stated on Microsoft's own ACMA documentation, so treat it as InfoQ's reporting rather than a confirmed Microsoft commitment — but if accurate, it would be a notable added wrinkle: tenants who've already taken the extra step of controlling where their Copilot conversation data lives are the ones currently locked out of the feature, rather than the ones the EU-style guarantee was extended to.
What's not answered yet
- No definition of "service architecture and optimization." The FAQ doesn't say which factors decide where a non-EU customer's conversational data actually lands, or whether that's disclosable per session.
- No mention of Azure Local or on-premises migration targets. ACMA's documented scope is VMware discovery and landing zone generation; Azure Local as a migration destination isn't addressed in the material I reviewed.
- The Bring Your Own Storage restriction InfoQ reported is unconfirmed on Microsoft's own pages as of this writing — worth verifying directly with your account team before assuming it applies to your tenant.
- No committed GA date. ACMA remains in public preview, so both scope and these data-handling answers can still change before general availability.
Who should care
If you're running a sovereign migration and considering ACMA to generate the landing zone template or wave plan, check which residency bucket you fall into before you put anything sensitive into a prompt — EU customers get the stronger guarantee by default, everyone else currently doesn't, regardless of where their underlying Azure Migrate project already sits. The underlying Azure Migrate data itself remains exactly as region-locked as it's always been; it's specifically the new conversational layer where the promise changes shape.
I'm tracking ACMA toward GA, including whether the residency language changes and whether the Bring Your Own Storage restriction gets documented one way or the other. If you're evaluating it for a live migration right now, subscribe to Sovereign Cloud Watch or find me on LinkedIn.