Azure Resource Mover: Move Failure Due to VM Size Mismatch in Trusted Launch VM

Question

Azure Resource Mover: Move Failure Due to VM Size Mismatch in Trusted Launch VM

Winston Smith 0

Problem description

I am attempting to move a virtual machine from North Europe to South Africa North using Azure Resource Mover. The move operation repeatedly fails during initiation with error code 1400148. The move configuration specifies the target VM size as Standard_E4as_v4, but the replication item in Site Recovery shows Standard_E4s_v3, which is not valid for this workload as the VM is a Trusted Launch Gen2 VM. This size mismatch appears to be the root cause of the failure.

Environment

Azure Resource Mover service, moving a VM from North Europe to South Africa North, involving Site Recovery and replication resources.

What I've already tried

I have verified the target VM size in Resource Mover matches the intended size, and observed that the replication item holds a different size. I reconfigured the resource to use Standard_E4s_v3, which aligns with the replication item, and validated that the replication is complete. I also checked the network settings and availability zone configurations, and attempted to update network configurations via API calls, but the move still fails due to the size mismatch.

Current status

The move operation still fails with error 1400148, indicating a size validation issue related to VM size compatibility for Trusted Launch Gen2 VMs. I am seeking guidance on how to resolve the size mismatch issue, specifically how to synchronize the VM size in the replication item with the Resource Mover configuration, or alternative approaches to successfully initiate the move.

Aliva Mohanty 0 Reputation points Microsoft External Staff

2026-10-21T05:51:28.12+00:00
Hi @Winston Smith,

Thanks for reaching out to Microsoft Q&A.

You're moving a Trusted Launch Gen2 VM from North Europe to South Africa North with Azure Resource Mover. The move fails with error 1400148 because the VM size in Resource Mover (Standard_E4as_v4) doesn't match the size in the Site Recovery replication item (Standard_E4s_v3). Changing the size in Resource Mover didn't fix it.

Why this happens

When you click Prepare, Resource Mover starts replication and saves the VM size at that moment. If you change the size after Prepare, Resource Mover shows the new size but the replication item keeps the old one. That mismatch is why the move fails.

The fix is to reset the VM in the move collection and set the size before running Prepare again.

Reference: https://learn.microsoft.com/en-us/azure/resource-mover/modify-target-settings

Step 1: Check that the VM size is available in the target region

Run this in Azure Cloud Shell:

az vm list-skus --location southafricanorth --size Standard_E4as_v4 --all -o table

The Restrictions column should say None.

Trusted Launch supports E-family sizes, so this size works with your VM.

Also confirm you have enough vCPU quota in South Africa North:

az vm list-usage --location southafricanorth -o table

Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/trusted-launch

Step 2: Remove the VM from the move collection

Go to Azure Resource Mover > Across regions.

Select the VM and click Remove.

Delete any leftover resources in South Africa North that were created during the move.

On the source VM, open Disaster recovery and make sure it no longer shows as protected.

Reference: https://learn.microsoft.com/en-us/azure/resource-mover/remove-move-resources

Step 3: Add the VM back and set the size first

Add the VM back to the move collection.

Click Validate dependencies.

Open Destination configuration and set the VM SKU to Standard_E4as_v4.

Then run, in this order: Prepare → Initiate move → Commit → Delete source (optional)

Note: Replication starts again from the beginning, so allow time for it to finish.

Reference: https://learn.microsoft.com/en-us/azure/resource-mover/tutorial-move-region-virtual-machines

Step 4: If it still fails

Open an Azure support request for Azure Resource Mover and include:

The full error message and the operation or correlation ID

The VM size shown in Resource Mover and in Site Recovery

The VM's current move state

Reference: https://learn.microsoft.com/en-us/azure/azure-portal/supportability/how-to-create-azure-support-request

To help us narrow this down, could you please share:

The full error message for code 1400148, and the operation or correlation ID

Whether the VM size was changed before or after running Prepare

The VM's current state in Resource Mover

The source VM's size, and the target size and security type shown in the Site Recovery replication item

Whether Standard_E4as_v4 shows any restrictions or quota limits in South Africa North

Whether the VM uses disk encryption (Azure Disk Encryption or customer-managed keys) or a target availability zone or availability set

Kindly let us know if the above helps or you need further assistance on this issue.

Please "upvote" if the information helped you. This will help us and others in the community as well.

1 answer

Your answer

Answer 1

Hi @Winston Smith

Thanks for providing the detailed troubleshooting information.

Based on your description, the issue appears to be a mismatch between the target VM size in Azure Resource Mover and the underlying Azure Site Recovery replication configuration.

You mentioned that:

Resource Mover specifies Standard_E4as_v4.
The Site Recovery replication item reports Standard_E4s_v3.
The source VM uses Generation 2 with Trusted Launch.
Changing the Resource Mover configuration to Standard_E4s_v3 hasn't resolved error 1400148.

You may do the following:

1. Validate the exact target VM size

First, verify whether the intended VM size is supported for Trusted Launch in South Africa North.

Microsoft provides the following Azure CLI command to inspect SKU capabilities:

az vm list-skus \
  --resource-type virtualMachines \
  --location southafricanorth \
  --all \
  --query "[?name=='Standard_E4as_v4' || name=='Standard_E4s_v3'].{Name:name,Restrictions:restrictions,Capabilities:capabilities[?name=='HyperVGenerations' || name=='TrustedLaunchDisabled']}" \
  -o json

Check the HyperVGenerations capability and whether TrustedLaunchDisabled is present and set to True.

Also review any regional or subscription restrictions. SKU compatibility and deployment availability are separate considerations.

2. Check the Resource Mover preparation state

Microsoft documents that destination VM settings should be configured before preparing the resource for a move.

Because Resource Mover uses Azure Site Recovery for VM replication, a change made after preparation may need additional handling.

However, I couldn't verify a supported procedure that automatically synchronizes an already-prepared Resource Mover VM size change with the underlying Site Recovery replication item.

Therefore, avoid modifying the Site Recovery replication configuration independently unless Microsoft confirms that doing so is supported for this Resource Mover operation.

3. Review the failed move operation

In Azure Resource Mover, review the failed operation details and capture:

The complete error message accompanying 1400148.
The Resource Mover operation or correlation ID.
The current move state of the affected VM.
The target VM size shown in Resource Mover.
The target VM size and security type shown in the associated Site Recovery replication item.

These details can help determine whether the failure is caused by unsupported SKU capabilities or inconsistent target settings between the services.

4. Consider a supported re-preparation path

If the intended target SKU is confirmed to support Trusted Launch, but the replication item continues reporting a different size, the next question is whether the move resource must be prepared again using the correct destination configuration.

I don't recommend deleting the replication item, disabling replication, or recreating the move collection without first confirming the supported recovery sequence.

Those actions could affect replication progress and require a new replication cycle.

5. Escalate the configuration mismatch

If the mismatch persists, I recommend opening an Azure Resource Mover support request.

Ask Microsoft to verify whether the target VM size stored in the underlying Site Recovery replication configuration is consistent with Resource Mover's destination settings, and to provide the supported procedure for correcting it without unnecessarily restarting replication.

Could you confirm whether the target VM size was changed before or after the Resource Mover Prepare operation?

Also, could you share the complete error message associated with 1400148?

Those details will help distinguish a Trusted Launch compatibility issue from a target configuration synchronization issue.

Hope this helps!

References:

Help make this community better for everyone: If this answer helped or resolved your issue, please accept it or upvote it. If not, share more details in a comment so we can continue the discussion and find the right solution. Thank you.