New-AzMigrateProject throws "Internal server error" from API call

Question

New-AzMigrateProject throws "Internal server error" from API call

Marian Romascanu 0

Facing a strange issue, help / advice appreciated

It seems API-related but no detail is provided in the API response beyond this "Internal server error"

PS C:\tmp\AZM_tests\working> $PSVersionTable.PSVersion

Major Minor Patch PreReleaseLabel BuildLabel

7 6 1

Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force -AllowClobber

Import-Module Az

Install-Module -Name Az.Migrate -Scope CurrentUser -Repository PSGallery -Force -AllowClobber

Import-Module Az.Migrate

Connect-AzAccount `

-Tenant "<tenant-id>" `

-Subscription "<sub-id>" `

-UseDeviceAuthentication

Set-ExecutionPolicy Unrestricted -Scope CurrentUser

PS C:\tmp\AZM_tests\working> $ResourceGroupName = "rg-azm-test"
PS C:\tmp\AZM_tests\working> $Location          = "canadacentral"
PS C:\tmp\AZM_tests\working> $ProjectName       = "Prj-AZM-test"
PS C:\tmp\AZM_tests\working> $SubscriptionId    = "<sub-id>"
PS C:\tmp\AZM_tests\working> $MigrateProject = New-AzMigrateProject `
>>      -Name $ProjectName `
>>      -ResourceGroupName $ResourceGroupName `
>>      -Location $Location -Debug -SubscriptionId  "<sub-id>"
DEBUG: 8:21:38 AM - [ConfigManager] Got nothing from [DisplaySecretsWarning], Module = [], Cmdlet = []. Returning default value [True].
DEBUG: 8:21:38 AM - [ConfigManager] Got nothing from [DisableInstanceDiscovery], Module = [], Cmdlet = []. Returning default value [False].
DEBUG: 8:21:38 AM - [ConfigManager] Got [False] from [EnableLoginByWam], Module = [], Cmdlet = [].
Set-AzMigrateProject_PutExpanded: C:\Users\Mro\Documents\PowerShell\Modules\Az.Migrate\3.0.0\Migrate.Autorest\custom\New-AzMigrateProject.ps1:78:16
Line |
  78 |  …      return Set-AzMigrateProject -Name $Name -ResourceGroupName $Reso …
     |                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     | Encountered internal server error. Please try again.
DEBUG: AzureQoSEvent:  Module: Az.Migrate:3.0.0; CommandName: New-AzMigrateProject; PSVersion: 7.6.1; IsSuccess: False; Duration: 00:00:02.8711822; SanitizeDuration: 00:00:00; Exception: InternalException;
PS C:\tmp\AZM_tests\working> $errorRecord = Resolve-AzError -Last
PS C:\tmp\AZM_tests\working> $errorRecord.Exception
StatusCode      : InternalServerError
Code            : InternalServerError
RequestMessage  : Method: PUT, RequestUri: 'https://management.azure.com/subscriptions/<sub-id>/resourceGroups/rg-azm-test/providers/Microsoft.Migrate/migrateProjects/Prj-AZM-test?api-ver
                  sion=2018-09-01-preview', Version: 1.1, Content: <null>, Headers:
                  {
                    Authorization: Bearer <auth-bearer>
                  }
ResponseHeaders : {[Cache-Control, System.String[]], [Pragma, System.String[]], [Strict-Transport-Security, System.String[]], [x-ms-request-id, System.String[]]…}
ResponseBody    : {"error":{"code":"InternalServerError","message":"Encountered internal server error. Please try again."}}
ClientRequestId : 
RequestId       : 40ac14e1-7e34-4431-ade0-3985fd99725d
Message         : Encountered internal server error. Please try again.
Action          : 
TargetSite      : Void MoveNext()
Data            : {}
InnerException  : 
HelpLink        : 
Source          : Az.Migrate.private
HResult         : -2146233088
StackTrace      :    at Microsoft.Azure.PowerShell.Cmdlets.Migrate.Migrate.MigrateProjectsPutMigrateProject_Call(HttpRequestMessage request, Func`3 onOk, Func`3 onCreated, IEventListener eventListener, ISendAsyncsender)
                     at Microsoft.Azure.PowerShell.Cmdlets.Migrate.Migrate.MigrateProjectsPutMigrateProject_Call(HttpRequestMessage request, Func`3 onOk, Func`3 onCreated, IEventListener eventListener, ISendAsyncsender)
                     at Microsoft.Azure.PowerShell.Cmdlets.Migrate.Migrate.MigrateProjectsPutMigrateProject(String subscriptionId, String resourceGroupName, String migrateProjectName, String acceptLanguage,
                  IMigrateProject body, Func`3 onOk, Func`3 onCreated, IEventListener eventListener, ISendAsync sender, SerializationMode serializationMode)
                     at Microsoft.Azure.PowerShell.Cmdlets.Migrate.Cmdlets.SetAzMigrateProject_PutExpanded.ProcessRecordAsync()
PS C:\tmp\AZM_tests\working>

VEMULA SRISAI 13,875 Reputation points Microsoft External Staff Moderator

2026-07-18T17:45:08.02+00:00
Hello Marian Romascanu,

Thanks for the detailed -Debug and Resolve-AzError output — it makes the diagnosis much easier. The trace shows New-AzMigrateProject internally calling Set-AzMigrateProject, which issues:

PUT /subscriptions/…/providers/Microsoft.Migrate/migrateProjects/Prj-AZM-test?api-version=2018-09-01-preview

The InternalServerError is returned by the Azure Migrate resource provider, not by the PowerShell module. The client-side UndeclaredResponseException simply reflects that the SDK received a 500 it couldn't map. This means the fix lies in isolating the service call, which we can do quickly.

Please run the following, in order:

1) Retry with a documented project location. Azure Migrate projects are created into a limited set of storage geographies. The official documentation and the cmdlet's own example both use centralus. It's likely that canadacentral isn't an accepted location for this resource type/API version, and the provider returns a generic 500 rather than a validation error. Please test:

New-AzMigrateProject -SubscriptionId $SubscriptionId -ResourceGroupName $ResourceGroupName -Name $ProjectName -Location "centralus"

If this succeeds, the location was the cause.

2) Verify resource-provider registration (independent of your admin role):

Get-AzResourceProvider -ProviderNamespace Microsoft.Migrate | Select-Object ProviderNamespace, RegistrationState Register-AzResourceProvider -ProviderNamespace Microsoft.Migrate Register-AzResourceProvider -ProviderNamespace Microsoft.OffAzure

3) If it still fails, submit the request directly via REST with a current API version to obtain a clearer error payload:

az rest --method put ` --url "https://management.azure.com/subscriptions/$SubscriptionId/resourceGroups/$ResourceGroupName/providers/Microsoft.Migrate/migrateProjects/$ProjectName?api-version=2023-01-01" ` --body '{ "location": "centralus", "properties": {} }'

4) Capture correlation details and check Service Health. You already have RequestId 40ac14e1-7e34-4431-ade0-3985fd99725d; please also capture the x-ms-correlation-request-id response header and the UTC timestamp. If the REST PUT to a documented location on 2023-01-01 still returns 500, this indicates a service-side fault; we will use those IDs to trace it with the Azure Migrate product team, and I'd recommend reviewing Azure Service Health for canadacentral in parallel.

Based on the evidence, the most probable cause is the project location (step 1). Please share the result of the centralus attempt and, if it still fails, the output of the REST call in step 3 — that will tell us definitively whether we're looking at a configuration issue or a service-side defect.

References:

Create and manage Azure Migrate projects (specific region): https://learn.microsoft.com/azure/migrate/create-manage-projects#create-a-project-in-a-specific-region

migrateProjects resource / supported API versions: https://learn.microsoft.com/azure/templates/microsoft.migrate/migrateprojects

4 answers

Your answer

Answer 1

Definitely there seem to be "garbage" left in the backend after a project is deleted and recreated with same name.

Apparently same goes for "sites" e.g.

===================

Failed to update fabric site. Status Code: BadRequest, Error: {'error':{'code':'ConflictingSpnDetails','message':

'The given spn details do not match the details already present for this site.'}},

Endpoint: https://management.azure.com/subscriptions/<sub-id>/resourceGroups/rg-bp1-cacen1/providers/Microsoft.OffAzure/vmwareSites/azmapl1tst8842site?api-version=2024-07-01-preview.

Then I changed the appliance name from azmapl1tst to azmapl2tst, generate a new key in the project, rerun check-prerequisites with new key on the appliance and this error was gone but now there are other errors

mysql_postgres_storage_err

Recommendation for all 3

Recommendation

Ensure that the currently logged in Azure user account has Contributor role assigned at the subscription level. 2. Ensure that the appliance has connectivity to Azure by rerunning the prerequisites. 3. You can try again after some time

What errors mean => clicking on error details

Service ammysqlsvc was not found on computer '.'.

Service ampgsqlsvc was not found on computer '.'.

Service amstoragesvc was not found on computer '.'.

But services are installed and permissions on subscription are "Owner"

Any advice / suggestion appreciated

azure_installed

roles

And the RP are registered as well on the subscription

RP_registered

And on top of this instability this whole automation attempt which started with New-AzMigrateProject is probably a moot point considering that the (only) Powershell code I found, supposed to enable the Azure Migrate automation, is between 3 and 6 y old and would start doing something useful only after doing the discovery, assessment and migration waves manually.

Answer 2

Starting with good news - the cmdlet works in another subscription. However old and new subscription had the RP prividers enabled (Microsoft.Migrate, Microsoft.OffAzure and Microsoft.*Discovery)

$ResourceGroupName = "rg-azm-test2"
$Location          = "canadacentral"
$ProjectName       = "PrjAZMtest"
$ApplianceName     = "azmapl1tst"
$SubscriptionId    = "...<sub-id>..."

PS C:\tmp\AZM_tests\working> $MigrateProject = New-AzMigrateProject `

-Name $ProjectName `

-ResourceGroupName $ResourceGroupName `

-Location $Location `

-SubscriptionId  $SubscriptionId `

-Etag $ApplianceName `

-Debug

DEBUG: AzureQoSEvent: Module: Az.Migrate:3.0.0; CommandName: New-AzMigrateProject; PSVersion: 7.6.1; IsSuccess: True; Duration: 00:00:01.0795517; SanitizeDuration: 00:00:00.0000294

PS C:\tmp\AZM_tests\working>

PS C:\tmp\AZM_tests\working> $MigrateProject

ETag :

Id : /subscriptions/<sub-id>/resourceGroups/rg-bp1-cacen1/providers/Microsoft.Migrate/migrateProjects/PrjAZMtest

Location : canadacentral

Name : PrjAZMtest

Property : {

                      "registeredTools": [ ],

                      "summary": {

                        "servers": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z",

                          "extendedSummary": {

                            "microsoftDiscoveredCount": "0",

                            "microsoftMachinesCount": "0"

                          },

                          "discoveredCount": 0,

                          "assessedCount": 0,

                          "replicatingCount": 0,

                          "testMigratedCount": 0,

                          "migratedCount": 0

                        },

                        "databases": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z"

                        },

                        "webApplications": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:23.3551438Z"

                        },

                        "desktopVirtualization": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z"

                        }

                      },

                      "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z",

                      "refreshSummaryState": "Completed",

                      "provisioningState": "Succeeded"

                    }
```ResourceGroupName     : rg-bp1-cacen1

TagAdditionalProperty : 

Type                  : Microsoft.Migrate/migrateProjects

And now there is a problem with generating the key for the appliance - "appliance name not found" 

There is apparently no way to programmatically generate the key according to Microsoft documentation - once the project is created by the PWSH command one must go in the portal and select the type of migration, initialize appliance and generate key to register it then do the discovery, all manual.

Why ![appl_name_not_found](/api/attachments/7c4d79bd-4182-4514-bc6c-dae179eaf2df?platform=QnA)

Answer 3

Starting with good news - the cmdlet works in another subscription. However old and new subscription had the RP prividers enabled (Microsoft.Migrate, Microsoft.OffAzure and Microsoft.*Discovery)

$ResourceGroupName = "rg-azm-test2"
$Location          = "canadacentral"
$ProjectName       = "PrjAZMtest"
$ApplianceName     = "azmapl1tst"
$SubscriptionId    = "...<sub-id>..."

PS C:\tmp\AZM_tests\working> $MigrateProject = New-AzMigrateProject `

-Name $ProjectName `

-ResourceGroupName $ResourceGroupName `

-Location $Location `

-SubscriptionId  $SubscriptionId `

-Etag $ApplianceName `

-Debug

DEBUG: AzureQoSEvent: Module: Az.Migrate:3.0.0; CommandName: New-AzMigrateProject; PSVersion: 7.6.1; IsSuccess: True; Duration: 00:00:01.0795517; SanitizeDuration: 00:00:00.0000294

PS C:\tmp\AZM_tests\working>

PS C:\tmp\AZM_tests\working> $MigrateProject

ETag :

Id : /subscriptions/<sub-id>/resourceGroups/rg-bp1-cacen1/providers/Microsoft.Migrate/migrateProjects/PrjAZMtest

Location : canadacentral

Name : PrjAZMtest

Property : {

                      "registeredTools": [ ],

                      "summary": {

                        "servers": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z",

                          "extendedSummary": {

                            "microsoftDiscoveredCount": "0",

                            "microsoftMachinesCount": "0"

                          },

                          "discoveredCount": 0,

                          "assessedCount": 0,

                          "replicatingCount": 0,

                          "testMigratedCount": 0,

                          "migratedCount": 0

                        },

                        "databases": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z"

                        },

                        "webApplications": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:23.3551438Z"

                        },

                        "desktopVirtualization": {

                          "refreshSummaryState": "Completed",

                          "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z"

                        }

                      },

                      "lastSummaryRefreshedTime": "2026-07-22T00:55:16.8107981Z",

                      "refreshSummaryState": "Completed",

                      "provisioningState": "Succeeded"

                    }
```ResourceGroupName     : rg-bp1-cacen1

TagAdditionalProperty : 

Type                  : Microsoft.Migrate/migrateProjects

And now there is a problem with generating the key for the appliance - "appliance name not found" 

There is apparently no way to programmatically generate the key according to Microsoft documentation - once the project is created by the PWSH command one must go in the portal and select the type of migration, initialize appliance and generate key to register it then do the discovery, all manual.

![appl_name_not_found](/api/attachments/7c4d79bd-4182-4514-bc6c-dae179eaf2df?platform=QnA)

Why "appliance name not found"? Same project created in the portal with same parameters allows generating the key

![appl_name_found_ok](/api/attachments/77dacb15-9034-4254-be6c-39c63a7adb92?platform=QnA)

Answer 4

The command and location are valid: Canada Central is a supported Azure Migrate metadata location. Your trace shows the request reached Microsoft.Migrate and the resource provider returned HTTP 500, so this is not a normal PowerShell parameter-validation error.

First, verify the signed-in principal has Azure Migrate Owner or a higher role. Since November 2025, that role is required to create projects. Also confirm Microsoft.Migrate is registered for the subscription and check whether a partially created migrateProjects resource already exists.

Next, try creating a project with a new name through the Azure portal. If that succeeds, restart PowerShell and test with the latest Az and Az.Migrate modules to eliminate a module-specific issue. If the portal also returns an error, open an Azure support case and include the UTC failure time, subscription, region, x-ms-request-id, client request ID, and the failed PUT operation. Those identifiers let the service team trace the backend failure.