Migration

Last published : Aug 25, 2026
You can initiate migration on a primary cluster when peer clusters are connected, configured for Disaster Recovery (DR), and application stack is online. Migration must be initiated from the primary cluster only - this is the source cluster. You can run the command kubectl or oc edit/patch <Name of DR plan> and update Spec:PrimaryClusterto change current primary cluster details. A differentSpec:PrimaryCluster in specifications and status indicates that migration is ongoing.
Figure: Migration initiated. Namespace resides on Cluster 1.
Migration initiated. Namespace resides on Cluster 1.
Following entities are updated during migration:
  1. Application metadata - When migration is initiated from source cluster, latest snapshot of managed application's metadata is taken and tagged for restoration. This latest snapshot is replicated across peer clusters (target cluster) for restoring. Thereafter, application goes offline on the source cluster. On the target cluster, this latest snapshot is used for restoring application stack.
  2. Application data - For stateful applications, you must have configured Data Replication CR and updated DisasterRecoveryPlan:Spec:DataReplicationPointer accordingly. Data Replication CR manages replication of application data from primary cluster to peer clusters (source to target). Currently, Arctera Volume Replicator(VVR) is used for application data replication. When migration is initiated from the source cluster, the cluster roles are swapped. The proposed primary cluster assumes 'Primary' role whereas current primary cluster assumes 'Secondary' role.
  3. DNS endpoints - The DNS custom resource updates and monitors the mapping for:
    • The host name to IP address (A, AAAA, or PTR record)
    • Alias to hostname or canonical name (CNAME)
When migration is initiated, the DNS resource records are updated appropriately.
Figure: Migration complete. Namespace resides on Cluster 2.
Migration complete. Namespace resides on Cluster 2.
You can check intermediate transient states like BackupStatus, ScheduleStatus, RestoreStatus, and DataReplicationStatus attributes of Disaster Recovery Plan during migration. To check logs if migration is stuck, run kubectl/oc logs -f --tail=100 deployments.apps/infoscale-dr-manager -n infoscale-vtas. After migration is complete, these transient states are cleaned and Status:PrimaryCluster in Disaster Recovery Plan is updated to the new primary.
Related information