Azure Static Web Apps: cross-subscription move fails with ResourceMoveFailed, app now appears in both subscriptions

Question

Azure Static Web Apps: cross-subscription move fails with ResourceMoveFailed, app now appears in both subscriptions

Martina Vila 0

Two Static Web Apps failed a cross-subscription move (same tenant) with ResourceMoveFailed, while two other SWAs in the same migration moved fine:

Failed SWA #1: 2026-07-13 11:33 UTC, correlation 202ec912-95af-4347-8db1-a9bef57e3155
Failed SWA #2: 2026-07-14 08:35 UTC, correlation 08c53545-828d-4306-ab8d-30771c607be6

After each failure the target showed "already exists at destination" while a direct GET returned ResourceNotFound; within hours both apps became fully-resolving ARM records in both subscriptions (same defaultHostname per pair). Sites still serve, but we can't safely manage or delete either record.

Pattern: both failed apps are Azure-DevOps-connected (provider=DevOps); the two that moved have no repo connection (provider=SwaCli). validateMoveResources passed beforehand.

Can the duplicate/phantom registrations be cleaned up and the moves completed backend-side?

Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-07-14T11:26:32.28+00:00
Hi @Martina Vila

Thank you for reaching us regarding the issue.

The resource type Microsoft.Web/staticSites (Azure Static Web Apps) supports moves across subscriptions (and resource groups) within the same tenant. Region relocation is not supported.

Guidance from App Service Move Limitations

Static Web Apps are part of the Microsoft.Web provider family.

Subscription moves are primarily metadata changes and should not affect the running application (sites continue to serve content).

The destination subscription/resource group must not contain conflicting resources.

Dependent or linked configurations may require additional handling after the move.

Use the validateMoveResources API/operation prior to the move

Addressing Partial Move Failures and Duplicates

It indicates that move operations must be atomic. Partial failures can result in inconsistent ARM state across subscriptions. In such scenarios:

You may see temporary conflicts (e.g., "already exists" messages) followed by replication issues creating multiple records with the same identifiers (such as defaultHostname).

Self-service deletion or management of such phantom/duplicated registrations is often restricted through standard ARM/portal/CLI operations to prevent further inconsistency.

Recommended resolution per documentation and support processes:

Collect diagnostic details including correlation IDs from the failed move operations, full resource IDs in both subscriptions, and properties like the provider linkage (e.g., DevOps).

https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/move-support-resources
https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/move-limitations/app-service-move-limitations

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.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-07-15T14:33:48.5866667+00:00

Hi @Martina Vila

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Martina Vila 0 Reputation points

2026-07-17T13:27:03.5033333+00:00
Hi @Golla Venkata Pavani and @Christos Panagiotidis
Thanks, we had done the checks before:

az resource show on both resource IDs returns identical JSON except the subscription in the id field

activity logs (both subscriptions, both correlation IDs) show the failure mechanism: target-side staticSites/write Succeeded at 08:32:58Z, the move failed at 08:35:51Z (source side), and then another target-side staticSites/write Succeeded at 08:43:04Z, 8 minutes after the move had already failed. Same pattern on the second app.

State did not converge till now

We have not deleted or retried anything. This needs the "failed move transactions to be reconciled backend-side": correlation IDs 202ec912-95af-4347-8db1-a9bef57e3155 and 08c53545-828d-4306-ab8d-30771c607be6.
Full JSON evidence and subscription IDs available through a private channel.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-08-02T17:05:46.9433333+00:00

Hi @Martina Vila

Thank you for the detailed diagnostics. The activity log sequence you described (target-side staticSites/write Succeeded > move failure on the source side > later additional target-side staticSites/write Succeeded) is consistent with a partial resource move involving the two-phase process defined by Azure Resource Manager.

A move request has two phases:

Resources are moved.

Resource providers that depend on the moved resources are notified.

Resource Manager allows up to four hours for the full operation (including recovery from transient issues). Source and destination resource groups are locked during this time.

If a resource provider fails either phase, Resource Manager unlocks the groups after the time limit. Resources that move successfully appear in the destination; resources that fail to move remain in the source.

When the notification phase does not complete cleanly, resources can end up in an inconsistent ARM state across subscriptions.

Your observation that az resource show returns essentially identical JSON and that the state has not converged indicates a partial success during the provider write/notification steps for Microsoft.Web/staticSites. Self-service actions (delete, retry, or further management) are not recommended in this situation because they can worsen the inconsistence.

Please let us know if you are still facing an issue, please let us know. We will check with the backend team.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-08-11T13:52:10.95+00:00

Hi @Martina Vila

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Martina Vila 0 Reputation points

2026-08-14T08:49:02.0466667+00:00

Hi @Golla Venkata Pavani
Yes the issue is there, would prefer if we can get support on this to resolve on backend side. Otherwise we need to drop and create new and we're not sure what will deleting actually do.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-08-19T13:13:31.0466667+00:00

Hi @Martina Vila

Currently we are checking with the backend team. Once we got an update, will share information as soon as possible.

1 answer

Your answer

Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-07-15T14:33:48.5866667+00:00

Hi @Martina Vila

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Martina Vila 0 Reputation points

2026-07-17T13:27:03.5033333+00:00

Hi @Golla Venkata Pavani and @Christos Panagiotidis
Thanks, we had done the checks before:

az resource show on both resource IDs returns identical JSON except the subscription in the id field

activity logs (both subscriptions, both correlation IDs) show the failure mechanism: target-side staticSites/write Succeeded at 08:32:58Z, the move failed at 08:35:51Z (source side), and then another target-side staticSites/write Succeeded at 08:43:04Z, 8 minutes after the move had already failed. Same pattern on the second app.

State did not converge till now

We have not deleted or retried anything. This needs the "failed move transactions to be reconciled backend-side": correlation IDs 202ec912-95af-4347-8db1-a9bef57e3155 and 08c53545-828d-4306-ab8d-30771c607be6.
Full JSON evidence and subscription IDs available through a private channel.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-08-02T17:05:46.9433333+00:00

Hi @Martina Vila

Thank you for the detailed diagnostics. The activity log sequence you described (target-side staticSites/write Succeeded > move failure on the source side > later additional target-side staticSites/write Succeeded) is consistent with a partial resource move involving the two-phase process defined by Azure Resource Manager.

A move request has two phases:

Resources are moved.

Resource providers that depend on the moved resources are notified.

Resource Manager allows up to four hours for the full operation (including recovery from transient issues). Source and destination resource groups are locked during this time.

If a resource provider fails either phase, Resource Manager unlocks the groups after the time limit. Resources that move successfully appear in the destination; resources that fail to move remain in the source.

When the notification phase does not complete cleanly, resources can end up in an inconsistent ARM state across subscriptions.

Your observation that az resource show returns essentially identical JSON and that the state has not converged indicates a partial success during the provider write/notification steps for Microsoft.Web/staticSites. Self-service actions (delete, retry, or further management) are not recommended in this situation because they can worsen the inconsistence.

Please let us know if you are still facing an issue, please let us know. We will check with the backend team.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-08-11T13:52:10.95+00:00

Hi @Martina Vila

I'm just reaching out to see if your issue has been resolved or if you've had a chance to review my previous comment?
Martina Vila 0 Reputation points

2026-08-14T08:49:02.0466667+00:00

Hi @Golla Venkata Pavani
Yes the issue is there, would prefer if we can get support on this to resolve on backend side. Otherwise we need to drop and create new and we're not sure what will deleting actually do.
Golla Venkata Pavani 7,440 Reputation points Microsoft External Staff Moderator

2026-08-19T13:13:31.0466667+00:00

Hi @Martina Vila

Currently we are checking with the backend team. Once we got an update, will share information as soon as possible.

Answer 1

Hi, when a failed move leaves the Static Web App visible in both subscriptions, do not delete either representation until you know which resource ID owns the live site and deployment token. Compare the full resource IDs with az resource show, check the move operation and Activity Log correlation IDs in both subscriptions, and verify the custom domains and production hostname against the live resource. A resource move is a control-plane transaction; the portal can temporarily show stale or partially committed records even though the site still serves traffic. If the state does not converge, open an Azure Static Web Apps support case and ask for the failed move transaction to be reconciled. Recreating or force-deleting the ghost entry can make domain validation and deployment history harder to recover.