Skip to content
eSHARS Operations

Key Vault: Move Between Resource Groups

Overview

Moving an Azure Key Vault to a different resource group does not break web app access. The vault’s DNS URI (https://{vault-name}.vault.azure.net/) does not change, and all access policies and RBAC role assignments travel with the vault.

Use this runbook when reorganising resource groups or consolidating eSHARS infrastructure layout.

What Moves With the Vault

  • All secrets, keys, and certificates
  • Managed identity access policies
  • RBAC role assignments scoped to the vault
  • Soft-delete and purge protection settings
  • Diagnostic settings do not move — see post-move steps

What Web Apps Are Affected By

Web apps connect via Key Vault references in App Settings:

@Microsoft.KeyVault(SecretUri=https://{vault-name}.vault.azure.net/secrets/{secret-name}/)

The vault name is the only identifier used. Moving between RGs does not change the vault name, so app settings require no changes.

Prerequisites

  • Azure CLI authenticated to the HISD tenant
  • Contributor role on both the source and destination resource groups
  • If the vault has private endpoints: review the private endpoints runbook before proceeding

Before Moving

1. Check for private endpoints

Terminal window
az keyvault show \
  --name {vault-name} \
  --query "properties.privateEndpointConnections" \
  -o table

If any private endpoints exist, they must be deleted before the move and recreated afterward.

2. Check Terraform state

Terminal window
cd {path-to-eshars-ops}/infrastructure
tofu state list | grep keyvault

Note the state address for reference. After the Azure move, update the Key Vault resource_group_name in OpenTofu/Terraform and run tofu plan / tofu apply.

You only need to run tofu state mv if the OpenTofu/Terraform resource address changes (for example, during a module refactor or resource rename), not just because the vault moved to a different resource group.

3. Note existing diagnostic settings

Terminal window
az monitor diagnostic-settings list \
  --resource $(az keyvault show --name {vault-name} --query id -o tsv) \
  -o table

Save the output — diagnostic settings must be reapplied after the move.

Performing the Move

The vault is locked for approximately 10 seconds during the move. No secrets or keys are affected.

Terminal window
# Get the vault resource ID
VAULT_ID=$(az keyvault show --name {vault-name} --query id -o tsv)


# Move to the destination resource group
az resource move \
  --destination-group {destination-rg} \
  --ids $VAULT_ID

Verify:

Terminal window
az keyvault show --name {vault-name} --query resourceGroup -o tsv

After Moving

1. Update Terraform state

Moving a Key Vault between resource groups does not change its Terraform resource address — tofu state mv is not needed. Simply update the resource_group_name argument in the relevant .tf file:

resource "azurerm_key_vault" "main" {
  name                = "kv-eshars-prod"
  resource_group_name = "rg-eshars-core-prod"  # ← update to new RG
  ...
}

Then run tofu plan to confirm Terraform sees no unintended changes (it should show zero diff beyond the RG name).

2. Reapply diagnostic settings

Recreate diagnostic settings using the saved output from the pre-move step, or via Terraform if managed there.

3. Update Azure Monitor alert rules

Alert rules scoped to the old resource ID stop working after a move. Check for KV-specific alerts:

Terminal window
az monitor alert list --resource-group {old-rg} -o table

Update or recreate any that reference the vault.

4. Verify web app access

Check that app services can still resolve secrets:

  1. Open the App Service in the portal
  2. Go to Configuration → verify KV references show a green tick (resolved)
  3. If not resolved within a few minutes, restart the app service

Rollback

The move cannot be automatically undone, but you can move the vault back to the original RG using the same az resource move command with the original RG as --destination-group.