Create Deployment failed during Execute Migration (Microsoft.MigrateV2-ExecuteMigrate-InMageRcm)

Hi Bingxue Zhang& thx for join me here at Q&A portal,

This error is too high-level to find the real cause.

Create Deployment only says the ARM deployment failed. It doesn’t tell why replication failed. The real error is usually inside the deployment operation details or the Azure Migrate job details.

Ask them to check

Azure Portal > Resource group rg-team-5027 > Deployments > Microsoft.MigrateV2-ExecuteMigrate-InMageRcm-20266711747 > Operation details

That should show the actual failed resource and message. For GCP Linux agent-based migration, common causes are missing permissions, unsupported Linux/kernel config, agent install issues, appliance connectivity, target region/quota, or disk/network settings. https://learn.microsoft.com/azure/migrate/tutorial-migrate-physical-virtual-machines & https://learn.microsoft.com/azure/migrate/troubleshoot-changed-block-tracking-replication may help u.

If the inner deployment error only shows code 322009 with no useful details, this needs Azure Migrate support. Include the migration project, machine name, job ID, deployment name, timestamp, and correlation ID.

rgds,

Alex &

pls if my answer was helpfull mark it as an answer & follow me here and at my blog https://ctrlaltdel.blog/

Hi @Bingxue Zhang The failure you are seeing at the ARM deployment stage (Microsoft.MigrateV2-ExecuteMigrate-InMageRcm-…) with error code 322009 – "Replication could not be enabled" known issue during agent‑based (InMageRcm) migration of GCP Linux VMs to Azure. It indicates that the Execute Migrate ARM deployment couldn't create one or more of the target resources (target VM, disks, NIC, VNet association, etc.), rather than a problem with the appliance or Mobility Service itself.

Since GCP VMs are treated as physical servers in Azure Migrate's agent-based flow, please validate the following areas in and you should be able to point out the exact blocker.

Get the real exact error details from the ARM deployment:

The "Create Deployment Failed" message is a generic wrapper. The actual reason is inside the deployment's operation details.

In the Azure portal, open Resource group → Deployments → Microsoft.MigrateV2-ExecuteMigrate-InMageRcm- → Operation details / Error details, or run:

1. az deployment operation group list \
2. --resource-group <resource group name> \
3. --name Microsoft.MigrateV2-ExecuteMigrate-InMageRcm-20266711747 \
4. --query "[?properties.provisioningState=='Failed'].{resource:properties.targetResource.resourceType, name:properties.targetResource.resourceName, error:properties.statusMessage}" -o table

This will tell you exactly which child resource failed (e.g., Microsoft.Compute/virtualMachines, Microsoft.Network/networkInterfaces, Microsoft.Compute/disks) and the underlying reason (quota, policy, SKU, auth, etc.).

Validate the common root causes for error 322009:

1. Missing permissions on the target subscription/RG The Azure Migrate service (and the user/SPN triggering the migration) needs Contributor on the target resource group and Virtual Machine Contributor + Network Contributor on the target VNet/subnet. Missing role assignments cause AuthorizationFailed inside the inner deployment.
2. Quota / capacity limits in the target region Check vCPU family quota, managed disk quota, public IP quota, and NIC quota in the region you selected. If capacity or a specific VM SKU is not available, the inner error will be SkuNotAvailable, AllocationFailed, or QuotaExceeded.
3. Azure Policy blocking the target resource Any deny‑policy on the target subscription/RG (e.g., allowed regions, allowed SKUs, required tags, disallowed disk types) will fail the Execute Migrate deployment. Review Policy → Compliance filtered on rg-team-5027.
4. Target configuration mismatch Under Migration and modernization → Replicating machines → Compute and Network, confirm:

• Target VM size is available in the chosen region and supports the disk count from the source.
• Target VNet/Subnet exists and is in the same region as the target RG.
• Availability Set / Zone selection matches a supported region.
• OS disk type (Standard HDD / SSD / Premium) is supported for the target VM SKU.

5. Source OS / kernel not supported For GCP Linux VMs, ensure the distro and kernel are on the supported list for the physical server (agent‑based) workflow — unsupported kernels can cause replication to be rejected at the Execute Migrate stage.
6. Mobility Service / appliance heartbeat Confirm the source VM is showing a healthy heartbeat under the replication appliance and that the appliance itself is in Connected state in the Azure Migrate project. If the machine was recently re‑registered or the passphrase changed, retry after a fresh heartbeat.

Please refer the official documentation for more details:

• Discover, assess, and migrate GCP VMs to Azure — https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-gcp-virtual-machines?view=migrate-classic
• Azure Migrate replication appliance (agent‑based) — https://learn.microsoft.com/en-us/azure/migrate/migrate-replication-appliance?view=migrate-classic

After you have completed the steps above, if the issue still persists, please send us the details requested in a private message so we can look into it further.

If you have further questions regarding this answer, feel free to click "Comment". If you find the answer helpful, please click "upvote" and "accept". This helps the community by allowing others with similar queries to easily find the solution.