Our company is moving its Azure and Microsoft 365 resources into a third-party-managed subscription so everything can be handled under one billing arrangement. The Microsoft 365 migration is relatively straightforward, but we operate a SaaS across several Azure Container App environments and Azure SQL databases in multiple regions. Services authenticate with managed identities, and deployments run through GitHub CI/CD. User authentication currently uses an Azure AD B2C tenant, which may remain where it is for now. Because an automatic subscription transfer does not appear to support everything we use, we may need to recreate resources, permissions, networking, and service relationships manually. Has anyone completed a migration like this? Is it practical, and what should we watch for to avoid identity problems, broken dependencies, or extended downtime?
3 Answers
The safest approach is usually a parallel rebuild rather than trying to move the existing environment in place. Create new Container Apps, SQL databases, managed identities, networking, and supporting resources in the target subscription, preferably from Bicep or Terraform. Deploy the application through the existing CI/CD process, copy or replicate the SQL data, and test the entire target environment while the original remains untouched.
For cutover, stop writes to the old application, perform a final database backup or synchronization, start the new environment, and run your validation checks. If everything passes, switch DNS to the new endpoints. If not, the rollback is simple: bring the original environment back online because it was never modified. A traffic-management or proxy layer can make the DNS switch easier.
The biggest risks are the hidden dependencies around identity and networking, not the container images themselves. Before cutover, document every managed identity and its access to SQL, Key Vault, Storage, ACR, App Configuration, monitoring, and other services. Recreate RBAC at the correct scope instead of assuming assignments will follow.
Also verify private endpoints, VNet integration, private DNS zones, firewall rules, outbound IP allowlists, Cloudflare origin restrictions, Key Vault secrets and certificates, and all GitHub environment secrets or federated credentials. Check SQL connection strings, failover groups, geo-replication, backup and restore procedures, and the exact process for preventing writes during the final sync.
Test B2C early from the new environment. Cross-subscription access should work, but redirect URIs, app registrations, certificates, secrets, and CORS settings are easy to overlook. Lower DNS TTL before the change, keep the old environment available for rollback, and define a clear go/no-go checklist. Since your deployment tooling already produces Bicep, use the migration to make the target configuration reproducible rather than manually rebuilding it.
That checklist is exactly what I needed. We use Aspire and azd in GitHub workflows, with Bicep generated as part of provisioning, so recreating the target environment should be reasonably repeatable after the parameters are supplied.
I would avoid relying on the subscription move process for this. There are unsupported resources and plenty of cases where something appears to transfer but later fails because managed identities, RBAC assignments, or resource IDs did not come across correctly. Rebuilding also gives you a chance to design the platform so it is not tightly coupled to one subscription. Management groups, policies, and other governance controls can span multiple subscriptions, so a subscription does not need to be the main architectural boundary.
We’re going with a new deployment and a controlled data migration rather than an in-place move. This may also be a good opportunity to clean up our subscription layout, which has grown somewhat ad hoc.
That sounds much more manageable. I’m leaning toward leaving the B2C tenant where it is since it is free and not part of the billing concern; we’ll test the authentication flow from the new subscription. Our public applications are already behind Cloudflare, so changing the destination should be fairly straightforward.