How to delete / resume failed "Replication Extension"

I'm getting an error at step 12.

https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-vmware-replicate?view=azloc-2511

"Deployment template validation failed. Error message: Replication extension is in a failed or canceled state. Please go back and retry."

Unable to find proper logs, and this error message is saying little to nothing.

Please help. I'm following everything in the instructions to the bit.

when trying powershell method using this method:

https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-via-powershell?view=azloc-2511

downloading the ps1 file https://aka.ms/azlocal-migrate-ps-script

i add the source and destination appliance names but it seems this ps1 wants both source and target be on hyper-v. which is not my case. my source vms are vmware vms. the destionation is obviously azure local.

Error encountered in matching the given source appliance name 'SOURCEAPPLIANCENAME' and target appliance name 'TARGETAPPLIANCENAME'. Please verify the VM site type to be either for
HyperV or VMware for both source and target appliances, and the appliance names are correct.

i tried both vmname and the actual hostnames.

running the diagnostics on the source appliance i get that https://discoverysrv.wus2.prod.migration.windowsazure.com/ is not available. but it is not available from anywhere. (checked multiple "is it down" websites)

Hello GabeCz

Thank you for posting your query on Microsoft Q&A platform.

When the Replication Extension deployment fails in Azure Local Migrate (step 12 in the VMware‑to‑Azure Local workflow), the extension stays in a Failed or Canceled state. Azure Local does not allow a new replication attempt until the stale extension is fully removed.

This is expected platform behavior.

The error you see:

Replication extension is in a failed or canceled state. Please go back and retry.

appears only when a failed extension is still present in the Azure Local resource inventory.

Your VMware appliance is also unable to reach this required endpoint:

https://discoverysrv.wus2.prod.migration.windowsazure.com/

If this endpoint is unreachable, the extension deployment will always fail.

The Azure Local migration appliance cannot reach the required discovery endpoint, If this endpoint is down or unreachable, the replication extension deployment will fail every time.

The failed extension object was not cleaned up automatically. Azure Local will block further replication until you manually delete the failed extension.

As a resolution try below steps:

1. Delete the failed Replication Extension (required): Azure Local keeps extension resources under Resource Explorer.

In the Azure Local portal:

1. Open Infrastructure → Resource Explorer
2. Go to Compute → VirtualMachineReplicationExtension
3. Delete the entry corresponding to the failed VM
4. If deletion fails → restart the Azure Local control plane node and retry.
5. Clean stale replication state on the Migration Appliance:
6. Open the VMware Migration Appliance Portal
7. Go to Configuration → Replication
8. Remove the failed VM entry (if shown)
9. Restart:
   • Migration service
   • Gateway service
10. Fix connectivity to discovery service: Your diagnostics already show the root cause that

discoverysrv.wus2.prod.migration.windowsazure.com not reachable

This endpoint must be reachable on HTTPS 443.

Check:

• DNS resolution
• Outbound internet rules
• Firewall/proxy
• TLS inspection (must be disabled)

Run:

curl -v https://discoverysrv.wus2.prod.migration.windowsazure.com/

If the endpoint is also unreachable from public “is it down” sites → this is a regional platform-side outage, and replication will continue failing until the endpoint is restored.

4. Retry the replication: After removing the stale extension and restoring connectivity:
5. Go back to “Prepare for migration”
6. Select the VMware VM again
7. Start replication
8. Validation will now pass

The PS script (azlocal-migrate.ps1) works for VMware → Azure Local, but it expects the appliance to be fully registered.

Your error:

Please verify the VM site type to be either for HyperV or VMware for both source and target appliances

occurs only when:

• The VMware appliance is not registered (because discovery endpoint is unreachable)
• The script cannot identify the VM site type

Once connectivity is restored, the script works normally per official doc:

https://learn.microsoft.com/en-us/azure/azure-local/migrate/migrate-via-powershell?view=azloc-2511

If you get any other errors, please do let us know.

Thanks,

Suchitra.

hi @Suchitra Suregaunkar thank you the resource explorer is a very helpful tool, and for your through reply.

however i can't find "compute" in it only "subscriptions" as per screenshot. but i'm sure it's there somewhere, as i read the extension can only be removed using API.

i'm sure i'm just looking for it in the wrong spot. if you could help me with this that'd be great, however it doesn't fix my initial problem of the migration failing with a very generic error message of (and i erase the resource id/path)

"message": "At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/arm-deployment-operations for usage details.", "message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."

i'd love to troubleshoot this but i am unable to guess where the actual logs are to find. can anyone tell?

i read that such error / exception i think it was some sort of compatibility issue can happen because ports are not open but both the target and source appliance are on the same vlan.

i may have misread that paragraph and the portal needs access to the target and/or source appliance's ports, because i do not feel comfortable opening up any port to our vcenter. i assume that's what the appliances are there for.

about the curl -v command it does result in 404 when running in powershell but running in cmd it's all good. i'm not feeling very smart right about now.

curl -v https://discoverysrv.wus2.prod.migration.windowsazure.com
* Host discoverysrv.wus2.prod.migration.windowsazure.com:443 was resolved.
* IPv6: (none)
* IPv4: 20.42.131.56
*   Trying 20.42.131.56:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Established connection to discoverysrv.wus2.prod.migration.windowsazure.com (20.42.131.56 port 443) from MYPRIVATEIP port 52091
* using HTTP/1.x
> GET / HTTP/1.1
> Host: discoverysrv.wus2.prod.migration.windowsazure.com
> User-Agent: curl/8.16.0
> Accept: */*
>
* Request completely sent off
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 404 Not Found
< Content-Length: 0
< Server: Microsoft-HTTPAPI/2.0
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Date: Wed, 17 Dec 2025 06:27:21 GMT
<
* Connection #0 to host discoverysrv.wus2.prod.migration.windowsazure.com:443 left intact

@Suchitra Suregaunkar

btw, i am in westus (los angeles), but clusters i guess can only be set up in the eastus region, whereas replication/migrate is automatically placed in the westus2 region.

can that be the root cause? i don't think so as i must not be the only one trying to set this up.

but if so, how can i A) move my migration project to eastus, and/or create a new one in the eastus region, and/or why can't i create everything in the westus2 region where i am actually located at?

thanks again for your continuous help, it means a lot!