diff --git a/content/posts/vault-migration/index.md b/content/posts/vault-migration/index.md
index 9d77489..12d369b 100644
--- a/content/posts/vault-migration/index.md
+++ b/content/posts/vault-migration/index.md
@@ -1,7 +1,7 @@
 ---
 title: "Migrating HashiCorp Vault Between AKS Clusters"
-date: 2025-03-18
-author: "Max Leske (Xovis) and Mathis Kretz (bespinian)"
+date: 2026-01-01
+author: "Max Leske (Xovis, @theseion) and Mathis Kretz (bespinian)"
 tags: ["Kubernetes", "Vault", "Azure", "Cloud Engineering"]
 categories: ["Engineering", "Cloud Native"]
 ---
@@ -11,11 +11,11 @@ categories: ["Engineering", "Cloud Native"]
 ## Introduction
 
 At [Xovis](https://xovis.com) and bespinian, we recently faced the challenge of
-migrating a Kubernetes-based HashiCorp Vault instance from one Azure Kubernetes
+migrating HashiCorp Vault cluster from one Azure Kubernetes
 Service (AKS) cluster to another. The goal was to consolidate infrastructure and
 reduce the number of AKS clusters that required maintenance. The outcome of a
 somewhat arduous journey is a Bash script that has enabled us to test the
-migration repeatedly and then perform the migration with a outage of less than 2
+migration repeatedly and then perform the migration with an outage of less than 2
 minutes.
 
 This blog post walks through our approach and presents the migration steps in 14
@@ -38,152 +38,173 @@ we needed to manage. Our primary goals were:
 
 ## Migration Strategy
 
-Our Vault instances are running in a high-availability configuration using the
-integrated Raft storage backend and auto-unseal with Azure Key Vault. This setup
-is needed in order to ensure resilience and security across client environments.
-To migrate Vault between AKS clusters, we implemented the process with a Bash
-script that automated all steps including snapshot creation, data restoration,
-and unseal key migration.
+We implemented the entire process of migrating the original Vault instance to the
+new AKS cluster with a Bash script that automated all steps including snapshot
+creation, auto-unseal key migration, and data restoration to the new Vault instance.\
+We wrote an additional Bash script to handle restoration of the original Vault
+instance, in case of unexpected issues.
+
+Before starting the actual migration, we tested the migration several times between
+two non-production clusters.
 
 ### Pre-Migration Setup
 
-Before initiating the migration:
+Before the migration script can be used, the target cluster must be prepared with
+an empty Vault instance with the same configuration as the original Vault instance.
+Setting up this empty Vault instance isn't covered in this post, however, as part
+of this work we also automated setting up new Vault instances, so that we could
+iterate on testing as fast as possible, with minimal manual intervention. In general,
+before the start of a migration run, the following work needs to be completed:
 
 1. **Provision the new Vault cluster**: Set up a fresh Vault instance on the
    target AKS cluster with the same configuration as the existing one.
 2. **Configure networking and authentication**: Ensure that the new instance has
    the necessary access permissions and that external clients will be able to
    connect post-migration.
-3. **Test the migration in a staging environment**: Migrate a test Vault
-   instance within between two non-production clusters to verify the process.
 
 ## Migration Process
 
-The migration script consists of the steps outlined below.
+In the following sections, we describe each individual step in the script.
+
+Uppercase variables like `OLD_K8S_NAME` refer to data that was configured
+as part of the script invocation, e.g., with `--old-k8s-name`, or data that
+was created in one step and needs to be available in another step. Lowercase
+variables like `required_tools` are local variables and are only read in the
+current step.
+
+The script snippets use some functions that are not explained further. Refer
+to the actual script to see what they do exactly.
+
+Note that the script snippets shown have been adapted to fit the blog post
+and can differ slightly from the actual script.
 
 ### 1. Prepare the Migration
 
-Before performing the actual migration, it's crucial to validate your
+Before performing the actual migration, it's crucial to validate the
 environment and ensure all prerequisites are met. This step includes setting up
 local backups, verifying Kubernetes contexts, ensuring proper access
 permissions, and preparing the user for the maintenance window.
 
-- Create a local backup directory:
+1. Create a local backup directory:
 
-  ```bash
-  mkdir -p vault-backups
-  ```
+    ```bash
+    mkdir -p vault-backups
+    ```
 
-- Check that the required tools are available and that `kubectl wait` is
-  supported
+2. Check that the required tools are available and that `kubectl wait` is
+   supported:
 
-  ```bash
-  REQUIRED_TOOLS=(az kubectl jq ed dig)
-
-  for tool in "${REQUIRED_TOOLS[@]}"; do
-    if ! command -v "$tool" >/dev/null 2>&1; then
-      print_message "Required tool '$tool' is not installed or not in PATH."
-      MISSING=1
-    fi
-  done
-
-  if ! kubectl wait --help | grep -q 'Wait for a specific condition'; then
-    print_message "'kubectl wait' is not supported."
-    MISSING=1
-  fi
+    ```bash
+    required_tools=(az kubectl jq ed dig)
 
-  if [ -n "$MISSING" ]; then
-    print_message "Please install the missing tools."
-    exit 1
-  fi
-  ```
+    for tool in "${required_tools[@]}"; do
+        if ! command -v "${tool}" >/dev/null 2>&1; then
+        print_message "Required tool '${tool}' is not installed or not on PATH."
+        missing=1
+        fi
+    done
 
-- Check that the `kubectl` contexts for both clusters are available
+    if ! kubectl wait --help | grep -q 'Wait for a specific condition'; then
+        print_message "'kubectl wait' is not supported."
+        missing=1
+    fi
 
-  ```bash
-  if ! (kubectl config get-contexts "${OLD_K8S_NAME}" > /dev/null 2>&1 && \
-      kubectl config get-contexts "${NEW_K8S_NAME}" > /dev/null 2>&1); then
-    print_message "No contexts for ${OLD_K8S_NAME} and ${NEW_K8S_NAME}."
-    print_message "Make sure you have credentials for both clusters"
-    exit 1
-  fi
-  ```
+    if [ -n "${missing}" ]; then
+        print_message "Please install the missing tools."
+        exit 1
+    fi
+    ```
 
-- Check that both `kubectl` contexts are accessible
+3. Check that the `kubectl` contexts for both clusters are available. You may have
+   to run `az aks get-credentials` to set up the required contexts for `kubectl`.
 
-  ```bash
-  switch_context "${OLD_K8S_NAME}" "${OLD_VAULT_NAME}"
-  if ! kubectl get cm > /dev/null 2>&1; then
-    print_message "Can't access resources on ${OLD_K8S_NAME}. Aborting"
-    exit 1
-  fi
+    ```bash
+    if ! (kubectl config get-contexts "${OLD_K8S_NAME}" > /dev/null 2>&1 && \
+        kubectl config get-contexts "${NEW_K8S_NAME}" > /dev/null 2>&1); then
+        print_message "No contexts for ${OLD_K8S_NAME} and ${NEW_K8S_NAME}."
+        print_message "Make sure you have credentials for both clusters"
+        exit 1
+    fi
+    ```
 
-  switch_context "${NEW_K8S_NAME}" "${NEW_VAULT_NAME}"
-  if ! kubectl get cm > /dev/null 2>&1; then
-    print_message "Can't access resources on ${NEW_K8S_NAME}. Aborting"
-    exit 1
-  fi
-  ```
+4. Check that both `kubectl` contexts are accessible:
 
-- Check that the new Vault cluster has three replicas
+    ```bash
+    switch_context "${OLD_K8S_NAME}" "${OLD_VAULT_NAME}"
+    if ! kubectl get cm > /dev/null 2>&1; then
+        print_message "Can't access resources on ${OLD_K8S_NAME}. Aborting"
+        exit 1
+    fi
 
-  ```bash
-  availableReplicas=$(kubectl get statefulsets.apps "${NEW_VAULT_NAME}" \
-    -o template --template="{{.status.availableReplicas}}")
-  if [ "${availableReplicas}" -ge 3 ]; then
-    print_message "Expected number of replicas found on ${NEW_K8S_NAME}"
-  else
-    print_message "Unexpected replica count on ${NEW_K8S_NAME}. Exiting."
-    exit 1
-  fi
-  ```
-
-- Our auto-unseal setup using Azure Key Vault is based on the AKS cluster's
-  Managed Service Identity. We thus need to check that the Managed Service
-  Identity of the new Vault cluster has access to the unseal keys of both Vault
-  instances, since both sets of keys will be rquired during the migration.
-
-  ```bash
-  az account set -s "${NEW_VAULT_SUBSCRIPTION_NAME}"
-
-  msi_principal_id=$(az identity list \
-    -g "${NEW_VAULT_RESOURCE_GROUP}" \
-    --query "[?clientId == '${NEW_VAULT_MSI_CLIENT_ID}'].principalId" \
-    | jq -r '.[]')
-
-  key_vault_id=$(az keyvault show --name "${NEW_KEY_VAULT_NAME}" \
-    --query "id" | jq -r '.')
-  if
-      ! az role assignment list \
-      --scope "${key_vault_id}" \
-      --role "Key Vault Crypto Service Encryption User" \
-      --query "[?principalId == '${msi_principal_id}']" > /dev/null 2>&1; then
-    print_message "Role assigment missing for new vault MSI"
-    print_message "Assign role 'Key Vault Crypto Service Encryption User'"
-    exit 1
-  fi
+    switch_context "${NEW_K8S_NAME}" "${NEW_VAULT_NAME}"
+    if ! kubectl get cm > /dev/null 2>&1; then
+        print_message "Can't access resources on ${NEW_K8S_NAME}. Aborting"
+        exit 1
+    fi
+    ```
+
+5. Check that the new Vault cluster has the number of desired replicas,
+   as specified when the script was called:
+
+    ```bash
+    availableReplicas=$(kubectl get statefulsets.apps "${NEW_VAULT_NAME}" \
+        -o template \
+        --template="{{.status.availableReplicas}}")
+    if [ "${availableReplicas}" -ge "${EXPECTED_REPLICAS} ]; then
+        print_message "Expected number of replicas found on ${NEW_K8S_NAME}"
+    else
+        print_message "Unexpected replica count on ${NEW_K8S_NAME}: ${availableReplicas}, expected ${EXPECTED_REPLICAS}. Exiting."
+        exit 1
+    fi
+    ```
+
+6. Our auto-unseal setup using Azure Key Vault is based on the AKS cluster's
+   Managed Service Identity. We thus need to check that the Managed Service
+   Identity of the new Vault cluster has access to the recovery keys of both Vault
+   instances, since both sets of keys will be rquired during the migration.
+
+    ```bash
+    az account set -s "${NEW_VAULT_SUBSCRIPTION_NAME}"
+
+    msi_principal_id=$(az identity list \
+        -g "${NEW_VAULT_RESOURCE_GROUP}" \
+        --query "[?clientId == '${NEW_VAULT_MSI_CLIENT_ID}'].principalId" \
+        | jq -r '.[]')
+
+    key_vault_id=$(az keyvault show \
+        --name "${NEW_KEY_VAULT_NAME}" \
+        --query "id" | jq -r '.')
+    if
+        ! az role assignment list \
+        --scope "${key_vault_id}" \
+        --role "Key Vault Crypto Service Encryption User" \
+        --query "[?principalId == '${msi_principal_id}']" > /dev/null 2>&1; then
+        print_message "Role assigment missing for new vault MSI"
+        print_message "Assign role 'Key Vault Crypto Service Encryption User'"
+        exit 1
+    fi
 
-  az account set -s "${OLD_VAULT_SUBSCRIPTION_NAME}"
-
-  key_vault_id=$(az keyvault show --name "${OLD_KEY_VAULT_NAME}" \
-    --query "id" | jq -r '.')
-  if
-      ! az role assignment list \
-      --scope "${key_vault_id}" \
-      --role "Key Vault Crypto Service Encryption User" \
-      --query "[?principalId == '${msi_principal_id}']" > /dev/null 2>&1; then
-    print_message "Role assigment missing for new vault MSI"
-    print_message "Assign role 'Key Vault Crypto Service Encryption User'"
-    exit 1
-  fi
-  ```
+    az account set -s "${OLD_VAULT_SUBSCRIPTION_NAME}"
+
+    key_vault_id=$(az keyvault show --name "${OLD_KEY_VAULT_NAME}" \
+        --query "id" | jq -r '.')
+    if
+        ! az role assignment list \
+        --scope "${key_vault_id}" \
+        --role "Key Vault Crypto Service Encryption User" \
+        --query "[?principalId == '${msi_principal_id}']" > /dev/null 2>&1; then
+        print_message "Role assigment missing for new vault MSI"
+        print_message "Assign role 'Key Vault Crypto Service Encryption User'"
+        exit 1
+    fi
+    ```
 
-- Remind the user to now announce the start of the maintenance window
+7. Remind the user to now announce the start of the maintenance window:
 
-  ```bash
-  print_message "Please announce the start of the maintenance window."
-  wait_for_any_key
-  ```
+    ```bash
+    print_message "Please announce the start of the maintenance window."
+    wait_for_any_key
+    ```
 
 ### 2. Create temporary migration tokens
 
@@ -192,241 +213,247 @@ Vault tokens with limited permissions. These tokens allow access to specific
 endpoints like snapshot creation, restoration, sealing, and leadership
 operations, which aren't granted to the existing policies.
 
-- Write policies for authorizing the migration operations
-
-  ```hcl
-  # Policy allowing to step down Vault leader
-  path "sys/step-down" {
-   capabilities = ["update", "sudo"]
-  }
-  # Policy allowing to save snapshots
-  path "sys/storage/raft/snapshot" {
-   capabilities = [ "create", "read", "update", "list" ]
-  }
-  # Policy allowing to restore vault's snapshots
-  path "sys/storage/raft/snapshot-force" {
-   capabilities = [ "create", "read", "update", "list" ]
-  }
-  ```
+1. The following policies are required by the migration tokens and are stored in
+   a dedicated file:
 
-- Detect the index of the leader pod in each Vault instance
-
-  ```bash
-  kubectl get pod -l "vault-active=true" -o jsonpath \
-    --template "{.items[0].metadata.labels.apps\.kubernetes\.io/pod-index}"
-  ```
-
-- Create tokens for each vault instances
-
-  ```bash
-  switch_context "${cluster_name}" "${vault_name}" > /dev/null
-  leader_index="$(detect_vault_leader_index)" > /dev/null
-
-  kubectl cp migration-policy.hcl "${vault_name}-${leader_index}":/tmp > /dev/null
-
-  kubectl exec -it "${vault_name}-${leader_index}" -- \
-    vault login "${admin_token}" > /dev/null
-
-  kubectl exec -it "${vault_name}-${leader_index}" -- \
-    sh -c "cat /tmp/migration-policy.hcl | vault policy write migration -" \
-    > /dev/null
+    ```hcl
+    # Policy allowing to step down Vault leader
+    path "sys/step-down" {
+    capabilities = ["update", "sudo"]
+    }
+    # Policy allowing to save snapshots
+    path "sys/storage/raft/snapshot" {
+    capabilities = [ "create", "read", "update", "list" ]
+    }
+    # Policy allowing to restore vault's snapshots
+    path "sys/storage/raft/snapshot-force" {
+    capabilities = [ "create", "read", "update", "list" ]
+    }
+    ```
 
-  kubectl exec -it "${vault_name}-${leader_index}" -- \
-    vault token create -policy=migration -period=30m -format json \
-    | jq -r '.auth.client_token'
+2. Create tokens for each vault instance, using the policies shown above:
 
-  kubectl exec -it "${vault_name}-${leader_index}" -- \
-    rm /tmp/migration-policy.hcl > /dev/null
-  ```
+    ```bash
+    NEW_VAULT_MIGRATION_TOKEN="$(create_migration_token "${NEW_K8S_NAME}" "${NEW_VAULT_NAME}" "${NEW_VAULT_ADMIN_TOKEN}")"
+    OLD_VAULT_MIGRATION_TOKEN="$(create_migration_token "${OLD_K8S_NAME}" "${OLD_VAULT_NAME}" "${OLD_VAULT_ADMIN_TOKEN}")"
+    ```
 
 ### 3. Block access to the old Vault instance
 
-Before creating the snapshot, it’s important to prevent any writes to the old
-Vault instance. This step ensures no data is changed after the snapshot and
-avoids issues with lease revocation.
-
-- Backup and delete the ingress for the old Vault instance
+We are now ready to actually perform the migration. Before creating the snapshot
+of the data in the old Vault instance, it’s important to prevent any further
+writes to the old Vault instance. This step ensures no data is changed after the
+snapshot has been created.
 
-  ```bash
-  kubectl get ing vault -o yaml > "${BACKUPS_DIR}/${OLD_VAULT_INGRESS_FILENAME}"
+Backup and delete the ingress resource for the old Vault instance:
 
-  kubectl delete ing vault --wait=true
-  ```
+```bash
+kubectl delete ing vault --wait=true
+```
 
 ### 4. Create snapshot of the old Vault instance
 
 We now take a snapshot of the Vault data using the Raft backend's built-in
 snapshot mechanism. After the snapshot is saved and downloaded, we immediately
-disable the old Vault to avoid unintended behavior.
-
-- Log in with the migration token
-
-  ```bash
-  kubectl exec -it "${OLD_VAULT_NAME}-${leader_index}" -- \
-    vault login "${OLD_VAULT_ADMIN_TOKEN}"
-  ```
-
-- Create the snapshot in the leader pod
-
-  ```bash
-  kubectl exec -it "${OLD_VAULT_NAME}-${leader_index}" -- \
-    vault operator raft snapshot save "${snapshot_filepath}"
-  ```
-
-- Dowload the snapshot
-
-  ```bash
-  kubectl cp "${OLD_VAULT_NAME}-${leader_index}":"${snapshot_filepath}" \
-    "${BACKUPS_DIR}/${OLD_VAULT_SNAPSHOT_FILENAME}"
-
-  kubectl exec -it "${OLD_VAULT_NAME}-${leader_index}" -- \
-    rm "${snapshot_temp_filepath}"
-  ```
-
-- Disable the old Vault instance by changing the command of the Vault
-  StatefulSet to `sleep`
-
-  ```bash
-  kubectl get statefulset vault -o yaml > \
-  "${BACKUPS_DIR}/${OLD_VAULT_STATEFULSET_FILENAME}"
-  cp "${BACKUPS_DIR}/${OLD_VAULT_STATEFULSET_FILENAME}" .
-
-  ed "${OLD_VAULT_STATEFULSET_FILENAME}" <<EOF
-  /args:/
-  +1,/-config=/c
-          - sleep infinity
-  .
-  w
-  q
-  EOF
-
-  kubectl apply -f "${OLD_VAULT_STATEFULSET_FILENAME}"
-  ```
-
-- Restart all pods to pick up the patched configuration
-  ```bash
-  kubectl delete pod --selector=app.kubernetes.io/name=vault
-  ```
+disable the old Vault to avoid unintended behavior. We do this to prevent issues
+with lease revocation, which would continue to run in the old Vault instance and
+lead to a difference in state to the snapshot.
+
+1. Log in to the leader pod with the migration token:
+
+    ```bash
+    kubectl exec -it "${OLD_VAULT_NAME}-${leader_index}" -- \
+        vault login "${OLD_VAULT_ADMIN_TOKEN}"
+    ```
+
+2. Create the snapshot in the leader pod:
+
+    ```bash
+    kubectl exec -it "${OLD_VAULT_NAME}-${leader_index}" -- \
+        vault operator raft snapshot save "${snapshot_filepath}"
+    ```
+
+3. Download the snapshot:
+
+    ```bash
+    kubectl cp "${OLD_VAULT_NAME}-${leader_index}":"${snapshot_filepath}" \
+        "${BACKUPS_DIR}/${OLD_VAULT_SNAPSHOT_FILENAME}"
+    ```
+
+
+4. Disable the old Vault instance by changing the command of the Vault StatefulSet to
+   `sleep infinity`. This will ensure that they reach a "ready" state without actually
+   running Vault.
+
+    ```bash
+    kubectl get statefulset vault -o yaml > \
+    "${BACKUPS_DIR}/${OLD_VAULT_STATEFULSET_FILENAME}"
+    cp "${BACKUPS_DIR}/${OLD_VAULT_STATEFULSET_FILENAME}" .
+
+    ed "${OLD_VAULT_STATEFULSET_FILENAME}" <<EOF
+    /args:/
+    +1,/-config=/c
+            - sleep infinity
+    .
+    w
+    q
+    EOF
+
+    kubectl apply -f "${OLD_VAULT_STATEFULSET_FILENAME}"
+    ```
+
+    The `args` field of the container in the StatefulSet resource will be changed from:
+
+    ```yaml
+    - args:
+        - "cp /vault/config/extraconfig-from-values.hcl /tmp/storageconfig.hcl;\n[
+            -n \"${HOST_IP}\" ] && sed -Ei \"s|HOST_IP|${HOST_IP?}|g\" /tmp/storageconfig.hcl;\n[
+            -n \"${POD_IP}\" ] && sed -Ei \"s|POD_IP|${POD_IP?}|g\" /tmp/storageconfig.hcl;\n[
+            -n \"${HOSTNAME}\" ] && sed -Ei \"s|HOSTNAME|${HOSTNAME?}|g\" /tmp/storageconfig.hcl;\n[
+            -n \"${API_ADDR}\" ] && sed -Ei \"s|API_ADDR|${API_ADDR?}|g\" /tmp/storageconfig.hcl;\n[
+            -n \"${TRANSIT_ADDR}\" ] && sed -Ei \"s|TRANSIT_ADDR|${TRANSIT_ADDR?}|g\"
+            /tmp/storageconfig.hcl;\n[ -n \"${RAFT_ADDR}\" ] && sed -Ei \"s|RAFT_ADDR|${RAFT_ADDR?}|g\"
+            /tmp/storageconfig.hcl;\n/usr/local/bin/docker-entrypoint.sh vault server
+            -config=/tmp/storageconfig.hcl \n"
+    ```
+    to:
+
+    ```yaml
+    - args:
+        - sleep infinity
+    ```
+
+
+    - Restart all pods to pick up the patched configuration (the pod disruption budget 
+    prevents the StatefulSet from redeploying the pods automatically):
+    ```bash
+    kubectl delete pod --selector=app.kubernetes.io/name=vault
+    ```
 
 ### 5. Restore the snapshot in the new Vault instance
 
 With the snapshot from the old instance in hand, we restore it to the new Vault
-instance. This effectively brings the new Vault cluster to the same data state
-as the old one.
+instance. Once the snapshot has been restored, both Vault instances will have the
+identical state.
 
-- Upload the snapshot the to leader pod
+1. Upload the snapshot the to leader pod:
 
-  ```bash
-  kubectl cp "${BACKUPS_DIR}/${OLD_VAULT_SNAPSHOT_FILENAME}" \
-    "vault-${leader_index}":"${snapshot_tmp}"
-  ```
+    ```bash
+    kubectl cp "${BACKUPS_DIR}/${OLD_VAULT_SNAPSHOT_FILENAME}" \
+        "vault-${leader_index}":"${snapshot_tmp}"
+    ```
 
-- Log in with the migration token
+2. Log in with the migration token:
 
-  ```bash
-  kubectl exec -it "vault-${leader_index}" -- \
-    vault login "${NEW_VAULT_MIGRATION_TOKEN}"
-  ```
+    ```bash
+    kubectl exec -it "vault-${leader_index}" -- \
+        vault login "${NEW_VAULT_MIGRATION_TOKEN}"
+    ```
 
-- Run the restore command
-  ```bash
-  kubectl exec -it "vault-${leader_index}" -- \
-    sh -c "vault operator raft snapshot restore -force \"${snapshot_tmp}\""
-  ```
+3. Run the restore command in the leader pod.
 
-### 6. Configure the new Vault cluster to use the old unseal key
+    ```bash
+    kubectl exec -it "vault-${leader_index}" -- \
+        sh -c "vault operator raft snapshot restore -force \"${snapshot_tmp}\""
+    ```
 
-The restored state must be unsealed with the unseal key stored in the KeyVault
+### 6. Configure the new Vault cluster to use the old auto-unseal key
+
+The restored state must be unsealed with the auto-unseal key stored in the KeyVault
 associated with the _old_ Vault instance. We now need to unseal the state but
-store a new unseal key in the KeyVault associated with the _new_ Vault instance.
+store a new auto-unseal key in the KeyVault associated with the _new_ Vault instance.
 This step modifies the config map by replacing the coordinates to the _new_
-instance unseal key with those of the _old_ instance unseal key and restarts the
-pods to apply the change. After the restart, the pods should unseal the state
-automatically since they have access to the original unseal key.
-
-- Patch the configuration of the new Vault cluster with the credentials of the
-  old Azure Key Vault
-
-  ```bash
-  kubectl get cm vault-config -o yaml > "${vault_config_filename}"
-
-  ed '+/seal "/' "${vault_config_filename}" <<EOF
-  .,/}/d
-  -
-  a
-      seal "azurekeyvault" {
-        tenant_id      = "${TENANT_ID}"
-        client_id      = "${NEW_VAULT_MSI_CLIENT_ID}"
-        vault_name     = "${OLD_KEY_VAULT_NAME}"
-        key_name       = "${OLD_VAULT_UNSEAL_KEY_SECRET_NAME}"
-      }
-  .
-  w
-  q
-  EOF
-
-  kubectl apply -f "${vault_config_filename}"
-  ```
-
-  This will apply the following config map to the new Vault cluster
-
-  ```yaml
-  apiVersion: v1
-  data:
-    extraconfig-from-values.hcl: |2-
-
-      disable_mlock = true
-      plugin_directory = "/vault/data/plugins"
-      ui = false
-      listener "tcp" {
-        tls_disable = 1
-        address = "[::]:8200"
-        cluster_address = "[::]:8201"
-      }
-      storage "raft" {
-        path = "/vault/data"
-      }
-      seal "azurekeyvault" {
-        tenant_id      = "$TENANT_ID"
-        client_id      = "$NEW_VAULT_MSI_CLIENT_ID"
-        vault_name     = "$OLD_KEY_VAULT_NAME"
-        key_name       = "$OLD_VAULT_UNSEAL_KEY_SECRET_NAME"
-      }
-      service_registration "kubernetes" {}
-  kind: ConfigMap
-  metadata:
-    name: new-vault-config
-    namespace: new-vault-destination
-  ```
-
-- Restart all pods to pick up the patched configuration
-  ```bash
-  kubectl delete pod --selector=app.kubernetes.io/name=vault
-  ```
-
-### 7. Prepare the unseal key migration on the new Vault instance
-
-To enable unseal key migration, the new Vault cluster needs to know about both
-unseal key coordinates when the configuration is loaded the next time (after
-unsealing the state) — keeping the old seal block active but disabled, and
+instance auto-unseal key with those of the _old_ instance auto-unseal key and restarts the
+pods to apply the change. After the restart, the pods will unseal the state
+automatically since they have access to the old auto-unseal key.
+
+1. Patch the configuration of the new Vault cluster with the credentials of the
+   old Azure Key Vault:
+
+    ```bash
+    kubectl get cm vault-config -o yaml > "${vault_config_filename}"
+
+    ed '+/seal "/' "${vault_config_filename}" <<EOF
+    .,/}/d
+    -
+    a
+        seal "azurekeyvault" {
+            tenant_id      = "${TENANT_ID}"
+            client_id      = "${NEW_VAULT_MSI_CLIENT_ID}"
+            vault_name     = "${OLD_KEY_VAULT_NAME}"
+            key_name       = "${OLD_VAULT_UNSEAL_KEY_SECRET_NAME}"
+        }
+    .
+    w
+    q
+    EOF
+
+    kubectl apply -f "${vault_config_filename}"
+    ```
+
+    This will apply the following ConfigMap to the new Vault cluster:
+
+    ```yaml
+    apiVersion: v1
+    kind: ConfigMap
+    metadata:
+        name: new-vault-config
+        namespace: new-vault-destination
+    data:
+        extraconfig-from-values.hcl: |-
+        disable_mlock = true
+        plugin_directory = "/vault/data/plugins"
+        ui = false
+        listener "tcp" {
+            tls_disable = 1
+            address = "[::]:8200"
+            cluster_address = "[::]:8201"
+        }
+        storage "raft" {
+            path = "/vault/data"
+        }
+        seal "azurekeyvault" {
+            tenant_id      = "$TENANT_ID"
+            client_id      = "$NEW_VAULT_MSI_CLIENT_ID"
+            vault_name     = "$OLD_KEY_VAULT_NAME"
+            key_name       = "$OLD_VAULT_UNSEAL_KEY_SECRET_NAME"
+        }
+        service_registration "kubernetes" {}
+    ```
+
+2. Restart all pods to pick up the patched configuration:
+
+    ```bash
+    kubectl delete pod --selector=app.kubernetes.io/name=vault
+    ```
+
+### 7. Prepare the auto-unseal key migration on the new Vault instance
+
+The new Vault instance has now been unsealed. We now need to migrate the auto-unseal
+configuration, so that the new Vault will read the auto-unseal key from the new
+KeyVault and no longer the old KeyVault.
+
+To enable auto-unseal key migration, the new Vault cluster needs to know about both
+auto-unseal key configurations when the configuration is loaded the next time (after
+unsealing the state) — keeping the old seal block active but _disabled_, and
 adding a new one that points to the new Azure Key Vault.
 
-- Update the Vault configuration:
+Update the Vault configuration:
 
 ```bash
 kubectl get cm vault-config -o yaml > vault-config.yaml
 
 ed '+/seal "/' vault-config.yaml <<EOF
 a
-      disabled       = true
+    disabled       = true
 .
 /}/
 a
     seal "azurekeyvault" {
-      tenant_id      = "${TENANT_ID}"
-      client_id      = "${NEW_VAULT_MSI_CLIENT_ID}"
-      vault_name     = "${NEW_KEY_VAULT_NAME}"
-      key_name       = "${NEW_VAULT_UNSEAL_KEY_SECRET_NAME}"
+    tenant_id      = "${TENANT_ID}"
+    client_id      = "${NEW_VAULT_MSI_CLIENT_ID}"
+    vault_name     = "${NEW_KEY_VAULT_NAME}"
+    key_name       = "${NEW_VAULT_UNSEAL_KEY_SECRET_NAME}"
     }
 .
 w
@@ -440,123 +467,114 @@ This will apply the following config map to the new Vault cluster
 
 ```yaml
 apiVersion: v1
+kind: ConfigMap
+metadata:
+name: new-vault-config
+namespace: new-vault-destination
 data:
-  extraconfig-from-values.hcl: |2-
-
-      disable_mlock = true
-      plugin_directory = "/vault/data/plugins"
-      ui = false
-      listener "tcp" {
+extraconfig-from-values.hcl: |2-
+    disable_mlock = true
+    plugin_directory = "/vault/data/plugins"
+    ui = false
+    listener "tcp" {
         tls_disable = 1
         address = "[::]:8200"
         cluster_address = "[::]:8201"
-      }
-      storage "raft" {
+    }
+    storage "raft" {
         path = "/vault/data"
-      }
-      seal "azurekeyvault" {
+    }
+    seal "azurekeyvault" {
         # the old seal config
         disabled       = true
         tenant_id      = "$TENANT_ID"
         client_id      = "$NEW_VAULT_MSI_CLIENT_ID"
         vault_name     = "$OLD_KEY_VAULT_NAME"
         key_name       = "$OLD_VAULT_UNSEAL_KEY_SECRET_NAME"
-      }
-      seal "azurekeyvault" {
+    }
+    seal "azurekeyvault" {
         # the new seal config
         tenant_id      = "$TENANT_ID"
         client_id      = "$NEW_VAULT_MSI_CLIENT_ID"
         vault_name     = "$NEW_KEY_VAULT_NAME"
         key_name       = "$NEW_VAULT_UNSEAL_KEY_SECRET_NAME"
-      }
-      service_registration "kubernetes" {}
-kind: ConfigMap
-metadata:
-  name: new-vault-config
-  namespace: new-vault-destination
+    }
+    service_registration "kubernetes" {}
 ```
 
-### 8. Perform the unseal key migration on the follower pods
+### 8. Perform the auto-unseal key migration on the follower pods
 
-Vault only allows unseal key migration on follower nodes, so we restart each
+Vault only allows auto-unseal key migration on follower nodes, so we restart each
 follower pod and run the migration steps.
 
-- Iterate through each follower pod and migrate it using the required number of
-  unseal keys (in this case, 3, based on the configured unseal threshold). Note:
-  This refers to unseal keys generated during the initial Vault initialization
-  process (using Shamir’s Secret Sharing), not recovery keys which are used in
-  auto-unseal or disaster recovery modes.
+Iterate through each follower pod and migrate it using the recovery keys provided
+during script invocation:
 
-  ```bash
-  for i in {0..2}; do
-    if [ "${i}" -eq "${leader_index}" ]; then
-      continue
-    fi
-
-    print_message "Restarting pod vault-${i} to start unseal key migration"
-    kubectl delete pod "vault-${i}"
-    kubectl wait \
-      --for=jsonpath='{.status.containerStatuses[0].state.running}' \
-      --selector=apps.kubernetes.io/pod-index="${i}" \
-      --timeout=90s \
-      pod
-
-    print_message "Migrating vault-${i}"
-    kubectl exec -it "vault-${i}" -- \
-      sh -c "vault operator unseal -migrate \"${OLD_VAULT_UNSEAL_KEY_1}\""
-    kubectl exec -it "vault-${i}" -- \
-      sh -c "vault operator unseal -migrate \"${OLD_VAULT_UNSEAL_KEY_2}\""
+```bash
+for i in $(get_vault_follower_indexes); do
+print_message "Restarting pod vault-${i} to start auto-unseal key migration"
+kubectl delete pod "vault-${i}"
+kubectl wait \
+    --for=jsonpath='{.status.containerStatuses[0].state.running}' \
+    --selector=apps.kubernetes.io/pod-index="${i}" \
+    --timeout=90s \
+    pod
+
+print_message "Migrating vault-${i}"
+for key in "${OLD_VAULT_RECOVERY_KEYS}"; do
     kubectl exec -it "vault-${i}" -- \
-      sh -c "vault operator unseal -migrate \"${OLD_VAULT_UNSEAL_KEY_3}\""
-  done
-  ```
+    sh -c "vault operator unseal -migrate \"${key}\""
+done
+done
+```
 
 ### 9. Step down leader pod
 
 Once all follower pods have been migrated, the leader must step down so it can
-restart and apply the new seal configuration.\
+restart and apply the new auto-unseal configuration.\
 Note that we use the migration token of the _old_ Vault instance here, since
 that is the token stored in the restored snapshot.
 
-- Step down the leader pod
+Step down the leader pod:
 
-  ```bash
-  kubectl exec -it "vault-${leader-index}" -- vault login "${OLD_VAULT_MIGRATION_TOKEN}"
-  kubectl exec -it "vault-${leader-index}" -- vault operator step-down
-  ```
+```bash
+kubectl exec -it "vault-${leader-index}" -- vault login "${OLD_VAULT_MIGRATION_TOKEN}"
+kubectl exec -it "vault-${leader-index}" -- vault operator step-down
+```
 
-### 10. Remove old seal block from the config
+### 10. Remove old seal block from the ConfigMap
 
 Now that all pods use the new seal configuration, we can safely remove the old
 seal block.
 
-- Edit the config map
+Edit the ConfigMap to remove the old seal block and apply it:
 
-  ```bash
-  kubectl get cm vault-config -o yaml > vault-config.yaml
+```bash
+kubectl get cm vault-config -o yaml > vault-config.yaml
 
-  ed '+/disabled \+= true/' vault-config.yaml <<EOF
-  -
-  .;/}/d
-  w
-  q
-  EOF
+ed '+/disabled \+= true/' vault-config.yaml <<EOF
+-
+.;/}/d
+w
+q
+EOF
 
-  kubectl apply -f vault-config.yaml
-  ```
+kubectl apply -f vault-config.yaml
+```
 
 ### 11. Restart all replicas
 
-- Restart all Vault pods to ensure they all use the final configuration.
-  ```bash
-  kubectl delete pod --selector=app.kubernetes.io/name=vault
-  ```
+Restart all Vault pods to ensure they all use the final configuration:
+
+```bash
+kubectl delete pod --selector=app.kubernetes.io/name=vault
+```
 
 ### 12. Create a proxy service from the old Vault to the new Vault
 
 To allow clients using the old Vault domain to reach the new Vault instance, we
 create a proxy Service and EndpointSlice in the old cluster that forwards
-traffic to the new Vault’s ingress. Note: We use an IP address for the
+traffic to the new Vault instance's ingress. Note: We use an IP address for the
 forwarding target instead of a DNS name because the ExternalName feature in
 ingress-nginx relies on commercial NGINX functionality and is not supported in
 the open source version.
@@ -595,40 +613,75 @@ endpoints:
 EOF
 ```
 
-### 13. Modify the ingress of the old Vault to forward connections via proxy
+### 13. Modify the ingress of the old Vault instance to forward connections via proxy
 
 With the proxy service in place, we recreate the ingress for the old Vault
-instance but configured to forward all requests to the proxy.
-
-- Edit the old ingress and update
-
-  ```bash
-  cp "${BACKUPS_DIR}/${OLD_VAULT_INGRESS_FILENAME}" "${new_ingress_filename}"
-  ed '+/annotations:/' "${new_ingress_filename}" <<EOF
-  a
-      nginx.ingress.kubernetes.io/backend-protocol: HTTPS
-      nginx.ingress.kubernetes.io/ssl-redirect: "true"
-      nginx.ingress.kubernetes.io/upstream-vhost: "${NEW_VAULT_DOMAIN}"
-  .
-  /name: vault-active/
-  s/name:.*/name: vault-migration-proxy
-  /number: 8200/
-  s/number:.*/number: 443
-  w
-  q
-  EOF
-
-  kubectl apply -f "${new_ingress_filename}"
-  ```
-
-  This allows existing clients to continue using the old Vault domain without
-  any modifications, as long as the configuration on the old cluster forwards
-  requests.
-
-### 14. Test the reachability of the old Vault domain
+instance but configure it to forward all requests to the proxy. This enables
+existing clients to continue using the old Vault domain without any modifications,
+as long as the configuration on the old cluster forwards requests.
+
+Edit the old ingress and apply it:
+
+```bash
+cp "${BACKUPS_DIR}/${OLD_VAULT_INGRESS_FILENAME}" "${new_ingress_filename}"
+ed '+/annotations:/' "${new_ingress_filename}" <<EOF
+a
+    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
+    nginx.ingress.kubernetes.io/ssl-redirect: "true"
+    nginx.ingress.kubernetes.io/upstream-vhost: "${NEW_VAULT_DOMAIN}"
+.
+/name: vault-active/
+s/name:.*/name: vault-migration-proxy
+/number: 8200/
+s/number:.*/number: 443
+w
+q
+EOF
+
+kubectl apply -f "${new_ingress_filename}"
+```
+
+The following shows the relevant fields of the Ingress resource before the
+modification:
+
+```yaml
+metadata:
+  annotations:
+spec:
+  rules:
+  - http:
+      paths:
+      - backend:
+          service:
+            name: vault-active
+            port:
+              number: 8200
+```
+
+The following shows the modified fields of the Ingress resource:
+
+  ```yaml
+metadata:
+  annotations:
+    nginx.ingress.kubernetes.io/backend-protocol: HTTPS
+    nginx.ingress.kubernetes.io/ssl-redirect: "true"
+    nginx.ingress.kubernetes.io/upstream-vhost: "<new vault domain>"
+spec:
+  rules:
+    - http:
+      paths:
+      - backend:
+          service:
+            name: vault-migration-proxy
+            port:
+              number: 443
+```
+
+### 14. Test the reachability of the old and new Vault domains
 
 Finally, we test that both the old and new Vault domains point to the same
-instance and that authentication works as expected.\
+instance (the old instance will not respond since it is not running) and that
+authentication works as expected.\
 Note again the use of the _old_ Vault token for both tests.
 
 ```bash
@@ -645,6 +698,17 @@ Note again the use of the _old_ Vault token for both tests.
   fi
 ```
 
+## Restoration in case of failure
+
+The migration script creates backups of all modified resources in the working directory.
+When something goes wrong, the restoration script can simply restore the backed up
+resources and restart the nodes of the old Vault instance.
+
+Despite careful planning and multiple test runs on non-production clusters, we did use the
+restoration script twice during migration attempts on the production clusters. In both
+instances, the reasons were related to network access, which varied slightly between
+the production and non-production clusters.
+
 ## Conclusion
 
 Migrating Vault between AKS clusters may seem daunting, especially when
@@ -658,6 +722,10 @@ Thanks to careful planning, extensive testing, and robust scripting, we were
 able to execute the migration with minimal downtime and no impact on dependent
 systems.
 
+We provide all the scripts and files described in this blog post for your use at
+<insert git repo link>. We provide no guarantees or support, use them at your own
+risk.
+
 We hope this walkthrough — and the accompanying script excerpts — can serve as a
 blueprint for others facing similar migrations. If you have questions, feedback,
-or suggestions for improvements, feel free to reach out!
+or suggestions for improvements, feel free to reach out!
\ No newline at end of file