Přesun Azure subscription do jiného tenantu: deep research pro partner benefit subscription

[!IMPORTANT] Původní zadání uživatele: „Udělej mi deep research na téma přesun azure subscription do jiného tenantu. Jedná se o subscription z partner benefit. Potřebuji znát všechny dopady na výpadek služeb. Jsou tam webapp, azure sql, storage accounts, appinsights, keyvaults.“

Datum publikace: 2026-07-02
Viditelnost: veřejná Hermes WWW

1. Executive summary

Nejdůležitější závěr je tento:

1. Pokud je ten „partner benefit“ subscription ve skutečnosti CSP subscription, změna Entra directory / tenantu není podle Microsoftu podporovaná. Microsoft to v hlavním článku k tenant transferu uvádí explicitně.
2. Pokud to CSP není, samotný tenant transfer je možný jen po velmi pečlivé přípravě a u části služeb buď způsobí výpadek, nebo je bez předchozí změny konfigurace vůbec neproveditelný.
3. Největší technické riziko není „přesun resourceů jako takových“, ale rozbití identity vrstvy: Azure RBAC, managed identities, Key Vault access policies / RBAC, Entra-auth vazby do SQL, ACLs ve Storage.
4. Pro App Service / Web App Microsoft negarantuje „bezvýpadkovost“. Pokud app používá managed identity, Key Vault references nebo Entra auth downstream služeb, je realistické čekat aplikační výpadek po přepnutí, dokud se identity a access policy znovu nenapojí.
5. Azure SQL je kritická stopka: pokud databáze používá Microsoft Entra authentication, Microsoft říká, že ji do jiného directory nelze převést v tomto stavu.

Prakticky:

• Nejdřív ověř exact offer type subscriptionu.
• Pokud CSP -> no-go tímto postupem.
• Pokud non-CSP -> dělat jako plánovaný maintenance cutover, ne jako „jen administrativní změnu“.

2. Co je potřeba rozhodnout jako úplně první

Termín „partner benefit subscription“ není dostatečně přesný pro rozhodnutí, jestli je tenant transfer supportovaný.

Microsoft dokumentuje, že partner programy poskytují různé Azure benefity / Azure credits. Z veřejných Learn stránek ale neplyne univerzální pravidlo „každý partner benefit subscription lze / nelze přepnout do jiného tenantu“. Rozhodující je skutečný offer / billing model konkrétní subscription.

Rozhodovací brána

• Je to CSP subscription?
• Pokud ano: tenant change není supportovaný.
• Je to jiný offer (např. sponsorship / credit-based / jiný non-CSP model)?
• Pak je potřeba ověřit, že Azure Portal vůbec nabízí Change directory, a zároveň projít dopady níže.

Jak to ověřit před jakýmkoli plánováním výpadku

V praxi si ověř:

• typ subscription / offer v Azure Portal,
• billing ownership model,
• jestli je v UI dostupné Change directory,
• jestli tam není vazba na partnera / CSP / delegated admin model.

Bez této validace nemá smysl dělat detailní migrační plán.

3. Oficiální Microsoft hard-stopy a obecné dopady

3.1 CSP stopka

Microsoft v článku Transfer an Azure subscription to a different Microsoft Entra directory uvádí:

• „For Azure Cloud Solution Providers (CSP) subscriptions, changing the Microsoft Entra directory for the subscription isn't supported.“

To je nejtvrdší rozhodovací bod v celé analýze.

3.2 Obecný dopad tenant transferu

Microsoft současně uvádí:

• při transferu do jiného directory jsou některé resources / security vazby nepřenositelné,
• všechny Azure RBAC role assignments a custom roles jsou ze source directory permanentně smazané a nepřenášejí se,
• v některých scénářích může být pro dokončení transferu potřeba downtime,
• článek není kompletní seznam všech služeb závislých na security principals.

To znamená:

• i když konkrétní služba není v tabulce Microsoftu explicitně vyjmenovaná,
• pořád může být rozbitá přes identitu, RBAC, managed identity, access policy nebo tenant-bound auth dependency.

4. Dopad na výpadek služeb podle typu služby

4.1 Web App / App Service

Co Microsoft říká přímo

Microsoft u App Service managed identities uvádí:

• managed identities nepodporují cross-directory scénáře, a
• pokud je app přesouvána mezi subscriptions nebo tenants, managed identities se nebudou chovat očekávaně a je nutné je znovu vytvořit,
• downstream resources pak musejí dostat nové access policies / permissions.

Microsoft u Key Vault references pro App Service zároveň uvádí, že:

• Key Vault references typicky používají system-assigned managed identity appky,
• případně lze použít user-assigned identity,
• app musí mít práva ke čtení secrets z Key Vaultu přes tuto identitu.

Reálný dopad na výpadek

Samotný App Service resource nemusí nutně „spadnout“ jako compute platforma. Ale velmi často přestane fungovat aplikace jako celek, pokud používá některý z těchto patternů:

• system-assigned managed identity,
• user-assigned managed identity,
• Key Vault references v app settings / connection strings,
• přístup do Storage / SQL / jiných služeb přes Entra identity,
• access do downstream resource přes RBAC navázané na starý tenant.

Praktická klasifikace rizika

• Nízké riziko výpadku: jednoduchý web bez managed identity a bez tenant-bound závislostí.
• Vysoké riziko výpadku: web používá Key Vault references, managed identity, RBAC přístup ke Storage, SQL, Service Bus apod.
• Velmi vysoké riziko výpadku: web závisí na user-assigned identity nebo na více downstream resources s Entra auth.

Co typicky po transferu přestane fungovat

• načtení secretů z Key Vaultu,
• přístup do Storage přes MI/RBAC,
• přístup do SQL přes Entra auth / token flow,
• jakákoli jiná vazba na starý service principal / object ID.

Závěr pro outage

U Web App neplánuj „zero downtime“ jako default. Pokud app používá MI nebo Key Vault references, plánuj to jako maintenance window s následnou repair fází.

4.2 Azure SQL

Co Microsoft říká přímo

V tenant transfer článku Microsoft uvádí:

• Azure SQL databases with Microsoft Entra authentication integration enabled — impacted: yes, recoverable: no
• „You cannot transfer an Azure SQL database with Microsoft Entra authentication enabled to a different directory.“

To je zásadní.

Reálný dopad

Pokud dnes aplikace používá:

• Azure SQL přes Microsoft Entra authentication,
• Entra admin / contained users / token-based auth,

pak je to před transferem blocker.

Co to znamená pro výpadek

• Pokud Entra auth zůstane zapnuté, tenant transfer tímto způsobem není validní postup.
• Pokud se před transferem přejde na jiný auth model a po transferu se Entra auth znovu nastaví, vzniká plánovaný aplikační zásah a prakticky jistě maintenance window.

Praktický závěr

• Azure SQL s Entra auth je no-go bez předchozí změny konfigurace.
• Pokud web na tuto DB sahá přes Entra identitu, outage se přenese i do webu.

4.3 Storage Accounts

Co Microsoft říká přímo

Microsoft uvádí:

• Azure Storage and Azure Data Lake Storage Gen2 — impacted: yes, recoverable: yes
• je nutné znovu vytvořit ACLs

U Azure Files Microsoft doplňuje:

• ACLs je nutné znovu vytvořit,
• pro storage accounts s Microsoft Entra Kerberos authentication je nutné auth po transferu vypnout a znovu zapnout,
• v některých scénářích to není podporované.

Reálný dopad

Dopad závisí hlavně na tom, jak je storage používán:

• pokud aplikace používá pouze account key / connection string / SAS, riziko je nižší,
• pokud se používají ACLs, Entra-based access, RBAC, ADLS Gen2 POSIX ACLs nebo Azure Files s Entra/Kerberos vazbou, je riziko významné.

Co může způsobit výpadek

• app po transferu ztratí přístup do blob/file storage přes identitu,
• rozpadnou se ACL-based přístupy,
• dávky / joby / funkce / weby přestanou číst nebo zapisovat,
• Azure Files auth může vyžadovat re-enable a následné testy klientů.

Závěr pro outage

• Storage account jako resource nemusí být nedostupný plošně, ale identity-based přístupy a ACL scénáře jsou vysoce rizikové.
• Pokud web nebo joby jedou přes MI/RBAC, počítej s výpadkem do doby oprav.

4.4 Key Vault

Co Microsoft říká přímo

Microsoft uvádí:

• Azure Key Vault — impacted: yes, recoverable: yes
• je nutné update tenant ID associated with the key vaults,
• je nutné remove and add new access policies.

K tomu je potřeba přičíst obecný dopad článku:

• role assignments se nepřenášejí,
• managed identities se musí re-create / re-enable podle typu.

Reálný dopad

Key Vault je u tenant transferu jeden z nejpravděpodobnějších zdrojů výpadku.

Pokud z něj čtou:

• Web App secrets,
• connection strings,
• certifikáty,
• klíče pro signing / encryption,
• jiné automatizace přes managed identity,

pak po transferu typicky nastane některý z těchto stavů:

• vault sice existuje, ale app už nemá oprávnění,
• reference v appce zůstanou, ale nová identity nemá access,
• RBAC / access policy ukazuje na staré object IDs,
• deployment / runtime začne vracet authorization chyby.

Závěr pro outage

• Key Vault je high-risk outage dependency.
• Pokud web nebo jiné služby používají Key Vault references, outage téměř jistě dopadne i na ně.

4.5 Application Insights / App Insights

Co Microsoft říká přímo

Application Insights není v hlavním tenant transfer článku explicitně vypsaný jako zvláštní resource type s unikátním migračním pravidlem.

Microsoft ale současně říká dvě důležité věci:

• seznam impacted služeb není kompletní,
• RBAC role assignments se při transferu nepřenášejí.

K tomu Microsoft v dokumentaci k Application Insights connection strings uvádí, že:

• connection string určuje, do kterého Application Insights resource se telemetrie posílá,
• instrumentation key je identifikátor pro ingestion service, ne security token.

Reálný dopad

Z toho plyne tento opatrný závěr:

• samotná telemetry ingestion pravděpodobně není hlavní outage vektor jen kvůli změně tenantu, pokud zůstává stejný resource a stejná connection string konfigurace,
• ale přístupová vrstva kolem resource se může rozbít:
• RBAC přístupy administrátorů,
• automatizace navázané na staré identity,
• případné vazby na jiné resources, pokud používají staré object IDs.

Závěr pro outage

• Pro samotný běh aplikace je App Insights obvykle nižší riziko než Key Vault nebo SQL.
• Pro operations/observability je to střední riziko, protože po transferu můžeš ztratit přístup k resource přes RBAC, dashboardy, alerting ownership apod.

5. Outage matice pro tvoje služby

Služba	Primární riziko	Pravděpodobnost výpadku	Poznámka
Web App / App Service	Managed identity, Key Vault references, RBAC na downstream resources	Vysoká	Platforma může běžet, ale aplikace často ne
Azure SQL	Microsoft Entra authentication	Velmi vysoká / blocker	S Entra auth enabled to Microsoft výslovně nepovoluje
Storage Accounts	ACLs, RBAC, Entra/Kerberos access	Střední až vysoká	Záleží, zda app používá keys/SAS vs. identity/ACL
Key Vault	Tenant ID, access policies, RBAC, MI object IDs	Velmi vysoká	Častý hlavní zdroj aplikačního výpadku
Application Insights	Ztráta RBAC a ops access	Nízká až střední	Nižší riziko pro runtime, vyšší pro operations

6. Co z toho plyne pro maintenance window

Pokud to není CSP a tenant transfer je vůbec supportovaný, doporučený realistický pohled je:

Varianta A — minimální riziko výpadku

Pouze pokud platí vše:

• web nepoužívá managed identity,
• web nepoužívá Key Vault references,
• SQL nepoužívá Entra auth,
• storage nepoužívá ACL / Entra-based access,
• nejsou tam jiné tenant-bound identity.

To je u reálného Azure workloadu spíš méně časté.

Varianta B — běžný reálný scénář

Typický moderní workload má alespoň část z následujícího:

• App Service managed identity,
• Key Vault references,
• SQL přes Entra nebo aspoň admin vazby,
• storage přes RBAC / ACL,
• CI/CD identity a automation.

V tom případě je správné počítat s:

• plánovaným maintenance window,
• post-transfer repair fází,
• smoke testem před otevřením provozu.

7. Doporučené pořadí rozhodnutí a kontrol

7.1 Gate 0 — supportability

Nejdřív potvrdit:

• exact subscription offer,
• CSP vs non-CSP,
• zda Azure Portal nabízí Change directory.

Pokud vyjde CSP, tento plán končí: tenant transfer není supportovaný.

7.2 Gate 1 — dependency inventory

Před změnou si vyexportovat minimálně:

• všechny role assignments,
• custom roles,
• system-assigned a user-assigned managed identities,
• všechny Key Vaulty a jejich access model,
• web app konfiguraci používající Key Vault references,
• SQL servery/databáze s Entra auth,
• storage účty s ACL / ADLS Gen2 / Azure Files Entra/Kerberos vazbou.

7.3 Gate 2 — blockers

Přerušit projekt, dokud nejsou vyřešené:

• Azure SQL s Entra auth,
• user-assigned identities bez plánu na re-create + rebind,
• Key Vault access bez připravených nových principals,
• storage ACL scénáře bez exportu a obnovy.

7.4 Gate 3 — cutover readiness

Před maintenance window musí být připravené:

• nové principals / identities v target tenantu,
• mapping starých a nových objektů,
• předem připravené RBAC reassign skripty,
• plán rebindu Key Vault access,
• plán re-enable / recreate managed identities,
• smoke test checklist pro web, DB, storage a observability.

8. Praktický závěr pro tvoje konkrétní portfolio

Pro stack Web App + Azure SQL + Storage + App Insights + Key Vault je nejpravděpodobnější tato realita:

• Key Vault a identity budou hlavní outage vektor.
• Web App na ně velmi pravděpodobně spadne logicky, i když resource fyzicky běží.
• Azure SQL je blocker, pokud používá Entra auth.
• Storage může být buď skoro bezbolestný, nebo kritický problém — podle ACL / Entra auth usage.
• App Insights je spíš operations problém než primární runtime blocker.

9. Doporučené rozhodnutí

Pokud chceš rychlé rozhodovací pravidlo

• Je to CSP? -> Nedělat tenant transfer tímto způsobem.
• Není to CSP, ale SQL používá Entra auth? -> Nejdřív změnit SQL auth model / připravit reconfiguration plán.
• Web používá Key Vault references nebo managed identity? -> Počítat s maintenance window a repair fází.

10. Co bych považoval za bezpečný další krok

Než se stanoví termín výpadku, udělal bych přesně tyto 3 věci:

1. Potvrdit exact offer type subscriptionu a tím vyřešit CSP vs non-CSP.
2. Udlat dependency inventory zaměřený jen na:
3. Web Apps,
4. identities,
5. Key Vault references,
6. SQL auth mode,
7. storage ACL / Entra auth.
8. Z toho odvodit outage plan, ne obráceně.

Bez těchto 3 kroků by jakýkoli odhad „výpadek bude malý“ byl nespolehlivý.

11. Zdroje

Primární Microsoft Learn zdroje

1. Transfer an Azure subscription to a different Microsoft Entra directory
   https://learn.microsoft.com/en-us/azure/role-based-access-control/transfer-subscription

2. How to change the Entra directory of your Azure subscription
   https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/subscription-change-directory

3. Use managed identities for App Service and Azure Functions
   https://learn.microsoft.com/en-us/azure/app-service/overview-managed-identity

4. Use Key Vault references as app settings in Azure App Service, Azure Functions, and Azure Logic Apps (Standard)
   https://learn.microsoft.com/en-us/azure/app-service/app-service-key-vault-references

5. Connection strings in Application Insights
   https://learn.microsoft.com/en-us/azure/azure-monitor/app/connection-strings

6. Manage Membership with Microsoft in Partner Center
   https://learn.microsoft.com/en-us/partner-center/membership/mpn-overview

7. Partner Success Core Benefits
   https://learn.microsoft.com/en-us/partner-center/membership/partner-success-core-benefits

12. Bottom line jednou větou

Nejprve ověř, zda ten partner benefit subscription není CSP; pokud ano, tenant transfer není podporovaný. Pokud CSP není, pro tvoji kombinaci Web App + SQL + Storage + Key Vault je správný předpoklad plánovaný maintenance window, protože největší riziko je rozpad identity a access vrstvy, ne samotné „přesunutí subscriptionu“.