Azure Migrate VMware agentless replication fails with AccountKindNotSupported – Storage GPv1

Migrare 0 Reputation points
2026-10-12T07:51:21.7466667+00:00

Hello,

We are experiencing an issue with Azure Migrate – VMware agentless migration to Azure.

When attempting to enable replication for an on-premises VMware virtual machine, Azure Migrate automatically initiates an ARM deployment to create a storage account. The deployment consistently fails.

Error details:

  • Operation: Microsoft.Storage/storageAccounts/write

HTTP status: 400 BadRequest

Error code: AccountKindNotSupported

Error message: Account Kind Storage is not supported.

Region: North Europe

Storage account SKU: Standard_LRS

Storage account kind requested by Azure Migrate: Storage (General-purpose v1)

What we have already verified:

The Azure subscription is active, and we have Owner permissions.

The Microsoft.Storage resource provider is registered.

Storage account quota is available in North Europe.

We successfully created a StorageV2 account manually in the same subscription and resource group.

Azure Migrate continues to attempt creating its own storage account with kind Storage, instead of using StorageV2.

The Azure Migrate automated diagnostics completed with "No issues detected".

Impact:

We cannot start replication of the VMware virtual machine, and therefore cannot proceed with a test migration.

The source VMware VM must remain operational. We are not attempting a production cutover.

Questions:

Why is Azure Migrate automatically deploying a legacy General-purpose v1 storage account?

Is this storage account kind no longer supported for Azure Migrate in North Europe or for certain subscriptions?

Is there a supported way to configure Azure Migrate to create or use a StorageV2 account instead?

Is there a known issue or workaround that would allow VMware agentless replication to start without recreating the existing Azure Migrate project?

We would appreciate guidance from the Azure Migrate engineering team.

Thank you.Hello,

We are experiencing an issue with Azure Migrate – VMware agentless migration to Azure.

When attempting to enable replication for an on-premises VMware virtual machine, Azure Migrate automatically initiates an ARM deployment to create a storage account. The deployment consistently fails.

Error details:

Operation: Microsoft.Storage/storageAccounts/write

HTTP status: 400 BadRequest

Error code: AccountKindNotSupported

Error message: Account Kind Storage is not supported.

Region: North Europe

Storage account SKU: Standard_LRS

Storage account kind requested by Azure Migrate: Storage (General-purpose v1)

What we have already verified:

The Azure subscription is active, and we have Owner permissions.

The Microsoft.Storage resource provider is registered.

Storage account quota is available in North Europe.

We successfully created a StorageV2 account manually in the same subscription and resource group.

Azure Migrate continues to attempt creating its own storage account with kind Storage, instead of using StorageV2.

The Azure Migrate automated diagnostics completed with "No issues detected".

Impact:

We cannot start replication of the VMware virtual machine, and therefore cannot proceed with a test migration.

The source VMware VM must remain operational. We are not attempting a production cutover.

Questions:

Why is Azure Migrate automatically deploying a legacy General-purpose v1 storage account?

Is this storage account kind no longer supported for Azure Migrate in North Europe or for certain subscriptions?

Is there a supported way to configure Azure Migrate to create or use a StorageV2 account instead?

Is there a known issue or workaround that would allow VMware agentless replication to start without recreating the existing Azure Migrate project?

We would appreciate guidance from the Azure Migrate engineering team.

Thank you.

Azure Migrate
Azure Migrate

A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Migrare 0 Reputation points
    2026-10-12T08:16:30.79+00:00

    Thank you for your response. This is our first replication attempt in this Azure Migrate project. No VMs have been replicated successfully so far. We have already created a StorageV2 account manually, but Azure Migrate continues to deploy a GPv1 account and fails with AccountKindNotSupported. Is there a supported way to fix this in the existing project without recreating it?

    Was this answer helpful?

    0 comments
  2. Rukshan edirisinghe 1,885 Reputation points
    2026-10-12T08:13:13.6733333+00:00

    Hi @Migrare

    Your diagnosis is spot on, and the timing explains it. Microsoft is retiring general-purpose v1 storage accounts, and according to the GPv1 retirement page, creating new GPv1 accounts was disabled in September 2026, with full retirement this month. So any deployment that still asks for kind "Storage" now fails with AccountKindNotSupported, no matter what region or permissions you have. It isn't something in your subscription.

    Since the cache storage account is created by Azure Migrate itself, the fix has to come from the Azure Migrate side. Here's how I'd move it forward:

    1. Open a support request in the Azure portal for Azure Migrate (VMware agentless replication).
    2. Paste the full ARM deployment error and mention that the requested kind is Storage (GPv1), which can no longer be created after the GPv1 retirement milestone.
    3. Ask whether your project can use a StorageV2 cache account, or whether a fix to the replication deployment is rolling out.

    Your source VM isn't touched by any of this, since replication never started.

    Did this project replicate any VMs successfully before September, or is this the first replication attempt in it?

    If this resolved your question, please consider accepting it as the answer. If support comes back with a workaround, let me know and I'll be happy to keep helping.

    Reference:

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.