diff --git a/docs/architecture/concepts/volume-migration.md b/docs/architecture/concepts/volume-migration.md
index 78bceaee..0b680346 100644
--- a/docs/architecture/concepts/volume-migration.md
+++ b/docs/architecture/concepts/volume-migration.md
@@ -9,7 +9,7 @@ to volumes remotely via NVMe-oF (TCP, RoCEv2), and the back storage, which serve
 The front storage accesses back storage both locally and remotely. Remote access itself uses NVMe-oF.
 
 Volume migration in simplyblock enables the online relocation of logical volumes (front storage or "docking points") 
-between storage nodes without service interruption and almost instantly. This is possible, because front storage has
+between storage nodes without service interruption and almost instantly. This is possible because front storage has
 remote access to all devices in the cluster and thus exists essentially "in memory" only. 
 
 Volume migrations are performed automatically based on operator decisions to either pre-serve data locality of workloads or 
@@ -17,13 +17,13 @@ to to balance I/O performance across cluster nodes. This is required since the f
 and runs all the data services. Additionally, volume migration is is used to drain nodes in case they need to be removed from the cluster
 (hardware replacement, infrastructure modernization).
 
-While most of the volume migrations happen "under the hood", users can also explicitely initiate migrations (e.g., to 
+While most of the volume migrations happen "under the hood", users can also explicitly initiate migrations (e.g., to 
 move particular, I/O-heavy volumes to particular nodes).
 
 ## How Volume Migration Works
 
-When a volume migration is initiated, simplyblock transfers the volume's complete data lineage -- including its entire
-snapshot chain and the active volume data -- from the source node to a target node. The migration runs in the background
+When a volume migration is initiated, simplyblock transfers the volume's complete data lineage (including its entire
+snapshot chain and the active volume data) from the source node to a target node. The migration runs in the background
 while the volume continues to serve I/O through its existing NVMe-oF paths.
 
 The migration process follows these phases:
@@ -64,7 +64,7 @@ If migration fails at any point, the target-side artifacts are cleaned up and th
 - **One migration per source node:** Only one volume migration can run on a given source node at a time. This is
   required to maintain snapshot consistency during the transfer.
 - **Protection guards:** Volumes undergoing migration are protected from deletion, resizing, and snapshot deletion
-  until the migration completes or is cancelled.
+  until the migration completes or is canceled.
 - **Automatic retry:** Transient failures during migration (such as temporary network issues) are automatically retried.
   The migration resumes from the last successful checkpoint.
 
diff --git a/docs/kubernetes/operations/volume-migration.md b/docs/kubernetes/operations/volume-migration.md
index fa5ddb14..26b5bd8b 100644
--- a/docs/kubernetes/operations/volume-migration.md
+++ b/docs/kubernetes/operations/volume-migration.md
@@ -10,6 +10,11 @@ does not move the storage node itself. This is different from
 [Migrating a Storage Node](../../non-kubernetes/operations/migrating-storage-node.md), which relocates an entire storage node identity to a
 new host.
 
+A volume migration moves only the logical volume itself, not the actual data. Since data remains distributed in the back
+storage, volume migrations is an online live migration and nearly instant. If node affinity is turned on for a cluster,
+back storage data realignment happens via rebalancing as an asynchronous task after one or more the volume migration(s)
+finished. 
+
 Volume migration is used in three ways:
 
 - **Manual migration:** requests a specific volume to move to a specific target node.