Update key vault's assiciated Azure AD tenant after subscriptin move without having to do a synchronized deployment of all dependent apps

Question

I am moving subscriptions from one tenant of Azure AD to another. I have reviewed and followed the process outlined in this doc. Everything is fine. The next step is about changing the key vault tenant ID for the moved subscription as per this doc. This is where I can't figure out a way to do it in such a way that doesn't involve changing and deploying several application dependent on the Key Vault together with the move. Ideally I would like to associate second tenant (the new one) with the key vault, register the apps in the new tenant and let those application update the configs as per their own release cycle and once all of the applications have updated to use new ClientID/Secret generated in the new Azure AD tenant, I would remove the old tenant association. However a key vault can only be associated with one tenant at any given time. What strategy can be used to allow this transition in smooth fashion without forcing a synchronized deployment of all of the dependent application in one go? It seems the only solution is to create a new key vault associated with the new AD tenant, register apps and issue new ClientID/Secret and let those go live as per their own deployment schedule. Eventually old key vault can be deleted. This seems to be a rather cumbersome approach. Is there any other way?

To make matter even more complicated, storage accounts keys are configured to be managed by key vault and all of the applications use key vault to get access to storage rather than directly using storage account keys. Here also the storage account can only be linked and managed by a single key vault.

Only a single Key Vault object should manage storage account keys.
Don't allow key management from multiple objects.

This would mean even the approach of creating new key vaults and migrating all apps to use these won't work unless the update to the storage-key vault link is synchronized with and deployment of all of the applications that use such storage. Some of these apps are managed by different teams in different timezones so a synchronized deployment is rather difficult plus if any of the app deployment were to rollback, it would either lose access to storage accounts or all of the apps have to rollback.

While this may not be a frequent situation where the subscriptions are moved to a different Azure AD tenant, I am sure it has been done and that is why I would like to get some guidance to how to do this without having to do a synchronized deployments of all of the key vault dependent apps.

Answer 1

As you pointed out, a key vault can only be associated with one tenant at any given time. So I do not believe that there is another way or workaround.

The best thing to do would be to make a feature request in User Voice.

Answer 2

we found this out the hard way, we migrated the subscription from an old tenant to a new one.
fortunately, we did NOT follow the doc above, as $vault.Properties.AccessPolicies = @() just wipes out the original access policies
of course, all the access policies are tied to azure active directory users, groups, and service principals, which work in the old tenant's azure active directory, but not in the new tenant with a whole different set of guid's.
Nor can you just add access policies as the tenant id of the keyvault and each access policy still has the old tenantid.
So, I fixed this in part manually.
I copied all the access policies with the old guids to a text file, so I knew the permissions on keys, secrets, and certs for each old guid
launched one browser, set to old tenant's AAD, and in overview, searched for each guid, noting the names (could be groups, users, enterprise apps, app registrations).
now my text file has a list of the old guids, permissions, and the old names (some of which are still unknown, they weren't in the old AAD. guessing either removed users/groups or deleted/recreated resources like data factory objectid's that were never cleaned up.
Then ran those commands to convert the keyvault to the new tenant (and wipe out the access policies).

Then manually re-added the users/groups/service principals by adding new access policies and match their permissions.
I suppose I could automate it, but I didn't.

Then tested things out and manually fixed things that didn't work (like data factories), managed id's in app services, etc. Still working on some data factories (as they too still have the old tenantid's (look in properties). don't yet have an answer for that (short of destroying/re-creating them, which I know works, but in my mind, a last resort)