diff --git a/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx b/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx
index c25e0d447..29584742a 100644
--- a/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx
+++ b/src/frontend/src/content/docs/integrations/cloud/azure/azure-front-door.mdx
@@ -156,6 +156,10 @@ When you publish your app, Aspire generates Bicep alongside the manifest. A Fron
   **Upgrading from Aspire 13.3.0-preview:** The resource names generated for Front Door profiles, endpoints, origin groups, origins, and routes changed in Aspire 13.4. This can result in duplicate Azure resources (profiles, endpoints, origin groups, routes, and origins) during an upgrade. To avoid duplicates, either remove the existing Azure resources before redeploying, or set resource names explicitly using `ConfigureInfrastructure`.
 </Aside>
 
+<Aside type="caution">
+  **Upgrading from Aspire 13.5 or earlier:** Origin names changed in Aspire 13.6 to include the origin's backend hostname in addition to the resource group ID, so switching an origin's backend produces a new origin name instead of reusing the previous origin's identity. This changes the generated origin name even when the backend hostname hasn't changed, and can result in old and new origins coexisting in the same origin group after an upgrade (incremental ARM deployments don't remove resources omitted from the new template). The recommended approach is to adopt the new naming policy and manually delete the old origins after deploying and confirming that the new origins are healthy and serve the intended backends. If this isn't feasible, preserve the previous default origin names with `ConfigureInfrastructure` before the first deployment after upgrading. For more information, see [Breaking changes in Aspire 13.6](/whats-new/aspire-13-6/#front-door-origin-names-now-include-the-backend-hostname).
+</Aside>
+
 ```bicep title="Generated Bicep — frontdoor.bicep"
 @description('The location for the resource(s) to be deployed.')
 param location string = resourceGroup().location
@@ -196,7 +200,7 @@ resource my_apiOriginGroup 'Microsoft.Cdn/profiles/originGroups@2025-06-01' = {
 }
 
 resource my_apiOrigin 'Microsoft.Cdn/profiles/originGroups/origins@2025-06-01' = {
-  name: take('myapiOrigin-${uniqueString(resourceGroup().id)}', 90)
+  name: take('myapiOrigin-${uniqueString(resourceGroup().id, my_api_host)}', 90)
   properties: {
     hostName: my_api_host
     originHostHeader: my_api_host
diff --git a/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx b/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx
index 716d4292e..212ad6629 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-13-6.mdx
@@ -34,7 +34,7 @@ This release introduces:
 - **Integration improvements** — debug Blazor WebAssembly apps, discover Dev Tunnel URLs, customize Radius recipes, and protect destructive Azure location changes.
 - **Updated emulator images** — move Azure App Configuration to `1.2.0` and make the Linux-based vNext Cosmos DB emulator the default.
 - **Community contributions** — 13 pull requests from eight contributors span major features, integration improvements, reliability fixes, and project tooling.
-- **One breaking change** — `RunAsEmulator` now selects the Linux-based vNext Cosmos DB emulator.
+- **Two breaking changes** — `RunAsEmulator` now selects the Linux-based vNext Cosmos DB emulator, and Azure Front Door origin names now include the backend hostname.
 - …and much more.
 
 ## 🆙 Upgrade to Aspire 13.6
@@ -298,6 +298,7 @@ Existing integrations add new workflows and safer defaults:
 - **Azure identity reliability.** Role-assignment Bicep detects service principal and federated workload identity credentials more accurately, and the experimental Sandboxes integration now binds its deployment principal to the scoped data-owner role correctly.
 - **Cosmos DB client health.** `AddAzureCosmosClient` and `AddKeyedAzureCosmosClient` register default-on health checks that probe account reachability. Set `DisableHealthChecks` to opt out.
 - **Foundry model refreshes.** Generated Foundry model constants were refreshed throughout the release cycle without changing the hosting API shape.
+- **Front Door origin identity.** Generated origin names now include the origin's backend hostname, so switching backends creates a distinct origin instead of reusing the previous origin's Azure identity. Review the [breaking-change guidance](#breaking-changes) before upgrading.
 
 <Aside type="note">
   Radius recipe APIs, the Dotnet project Blazor gateway, and Azure Container
@@ -387,3 +388,45 @@ If you adopt the new default:
   Linux emulator
   documentation](https://learn.microsoft.com/azure/cosmos-db/emulator-linux).
 </LearnMore>
+
+### Front Door origin names now include the backend hostname
+
+Azure Front Door origin names generated by the Aspire hosting integration now combine the resource group ID with the origin's backend hostname, instead of hashing the resource group ID alone. This is a breaking deployment change: upgrading to Aspire 13.6 changes the generated origin resource names, even when the backend hostname hasn't changed. Endpoint, origin-group, and route names are unchanged.
+
+[Incremental ARM deployments](https://learn.microsoft.com/azure/azure-resource-manager/templates/deployment-modes#incremental-mode) don't remove resources omitted from the new template, so existing origins can remain alongside the newly named origins in the same origin group.
+
+**Recommended approach:** Adopt the new naming policy, which gives an origin a new identity when its backend hostname changes:
+
+1. Deploy your app with Aspire 13.6 using the new default origin names.
+2. Confirm that the newly named origins are healthy and serve the intended backends.
+3. Manually delete the old origins from each affected origin group.
+
+**Fallback:** If the recommended deployment and cleanup approach isn't feasible, preserve the previous default origin names by overriding them with `ConfigureInfrastructure` before the first deployment after upgrading:
+
+```csharp title="AppHost.cs"
+using Azure.Provisioning;
+using Azure.Provisioning.Cdn;
+using Azure.Provisioning.Expressions;
+
+builder.AddAzureFrontDoor("frontdoor")
+    .WithOrigin(api)
+    .ConfigureInfrastructure(infrastructure =>
+    {
+        foreach (var origin in infrastructure.GetProvisionableResources()
+            .OfType<FrontDoorOrigin>())
+        {
+            // Match the previous default: remove underscores and hash only the resource-group ID.
+            origin.Name = BicepFunction.Take(
+                BicepFunction.Interpolate($"{origin.BicepIdentifier.Replace("_", "")}-{BicepFunction.GetUniqueString(BicepFunction.GetResourceGroup().Id)}"),
+                origin.GetResourceNameRequirements().MaxLength);
+        }
+    });
+```
+
+The callback runs after the integration's defaults and applies to every configured origin. This override opts out of hostname-based origin identity, so switching backends no longer creates a new origin; if the new naming scheme has already been deployed, applying the override doesn't delete the newly created origins, so disable or remove unwanted origins separately after confirming which origins should serve traffic.
+
+<LearnMore>
+  Review the [Front Door origin naming
+  change](https://github.com/microsoft/aspire/pull/20035) and the [Azure Front
+  Door integration](/integrations/cloud/azure/azure-front-door/) documentation.
+</LearnMore>