Agentless migration: Replication Fails for All VMs (Error 110034)

Hello Chiara Petrocelli

Thanks for the detailed write-u, the fact that discovery and assessment complete cleanly but every VM fails at the Preparation phase is actually a very useful clue, so let me explain what's happening.

What error 110034 actually means

Error ID 110034 ("Migration requirements could not be retrieved") isn't the root cause by itself — it's a wrapper error. It means Azure Migrate reached out to vCenter to fetch the migration prerequisites for the VM and vCenter rejected or couldn't complete that call. The real detail is always in the Provider error code and Provider error message shown just below it in the failed job.

So the first thing I'd ask you to do is grab that. In the portal:

Azure Migrate → Migration and modernization → Replicating machines / Jobs → open the failed "Enable replication" job → expand the error.

Note down the Provider error code and message — that tells us exactly which vCenter operation was refused.

The most likely cause here

Because it's failing identically for all VMs, this points to the vCenter account privileges rather than anything VM-specific. This is a very common one, and here's why it's easy to miss:

Discovery and assessment only need Read-only + Guest operations. Agentless migration needs a noticeably larger privilege set — snapshot create/remove/revert/rename, changed block tracking, disk lease, datastore browse and file management, and disk random read/access. If the account was set up for discovery only, discovery and assessments will look perfectly healthy while every replication attempt fails at Preparation. In that case the provider error typically reads*"Insufficient permissions to start the replication"* and lists the missing privileges by name.

The exact privilege list is documented here:

• Support matrix for VMware vSphere migration – see the vCenter Server permissions table under "Agentless migration": https://learn.microsoft.com/en-us/azure/migrate/migrate-support-matrix-vmware-migration [learn.microsoft.com]
• Set up least privileged accounts in Azure Migrate: https://learn.microsoft.com/en-us/azure/migrate/best-practices-least-privileged-account [learn.microsoft.com]

The part that's most often the actual problem

Even when the right privileges exist, they're frequently applied only at the VM or folder level. Microsoft's documentation is explicit on this — the account must have permissions assigned at all required levels: datacenter, cluster, host, VM, and datastore, and it specifically notes to apply permissions at each level to avoid replication errors.

If your privileges are only propagating down from a VM folder, the datastore and host-level operations Azure Migrate needs will still fail.

I'd verify this in the vSphere Client under both the Hosts and Clusters view and the VMs and Templates view, and use Propagate to children where applicable.

Two other things worth ruling out

1. Leftover snapshots — check whether the VMs have any existing snapshots from earlier replication attempts or from a backup product such as Veeam. Pre-existing snapshots block agentless replication setup.

Appliance-to-ESXi connectivity — agentless replication needs the appliance to reach the ESXi hosts directly on TCP 902 (vCenter connectivity alone isn't sufficient). From the appliance, run:

Test-NetConnection -ComputerName "<ESXi_FQDN>" -Port 902

Also confirm the ESXi hostnames resolve correctly from the appliance and that there are no stale entries in the appliance's hosts file. You can validate all of this quickly with Diagnose and solve in the Appliance Configuration Manager: https://learn.microsoft.com/en-us/azure/migrate/troubleshoot-appliance-diagnostic [docs.azure.cn]

Suggested order of action

1. Capture the Provider error code/message from the failed job.
2. Compare the vCenter account's role against the privilege table in the support matrix.
3. Confirm the permissions are applied at datacenter, cluster, host, VM and datastore level.
4. Remove any pre-existing VM snapshots.
5. Stop replication on one VM and re-enable it as a test before re-running the full batch.

Further reading

• Troubleshooting replication issues in agentless VMware VM migration: https://learn.microsoft.com/en-us/azure/migrate/troubleshoot-changed-block-tracking-replication [learn.microsoft.com]
• Agentless migration architecture (how replication and permissions work): https://learn.microsoft.com/en-us/azure/migrate/concepts-vmware-agentless-migration [learn.microsoft.com]
• Migrate VMware VMs to Azure (agentless): https://learn.microsoft.com/en-us/azure/migrate/tutorial-migrate-vmware [learn.microsoft.com]

Thanks,

Suchitra.

Hello Chiara Petrocelli,

Greetings! Thanks for raising this question in Q&A forum.

Since VM discovery and assessment are completing successfully, but replication fails for all VMs during the Preparation phase with Error 110034 (Migration requirements could not be retrieved), this points more toward an Azure Migrate replication configuration, appliance connectivity, or a backend validation issue rather than a problem with individual VMs.

1. Check the Provider errors associated with Error 110034 in the Azure Migrate project, as they often contain the specific failure reason.
2. Verify that the Azure Migrate appliance has connectivity to all required Azure service endpoints and that proxy, firewall, or DNS settings are not blocking communication.
3. Review the appliance logs to identify any authentication, permissions, or service registration errors during replication enablement.
4. Confirm that the target subscription, resource group, cache storage account, and migration project resources are healthy and accessible.
5. Since the issue affects all VMs consistently, collect the appliance name, Azure Migrate project name, correlation IDs, and failure timestamps, then open a Microsoft support case for backend log analysis.

The next action is with the customer and Microsoft Support. The expected outcome is a backend review of the replication provider logs to determine why migration requirements cannot be retrieved and to identify any service-side configuration or validation issues affecting replication across all VMs.

If this answer helps you kindly accept the answer which will help others who have similar questions

Best Regards,

Jerald Felix.