diff --git a/content/en/docs/20.0/concepts/move-tables.md b/content/en/docs/20.0/concepts/move-tables.md
index ced9abf99..cf72e817d 100644
--- a/content/en/docs/20.0/concepts/move-tables.md
+++ b/content/en/docs/20.0/concepts/move-tables.md
@@ -2,7 +2,7 @@
 title: MoveTables
 ---
 
-MoveTables is a new workflow based on VReplication. It enables you to relocate tables between keyspaces, and therefore physical MySQL instances, without downtime.
+MoveTables is a workflow based on VReplication. It enables you to relocate tables between keyspaces, and therefore physical MySQL instances, without downtime.
 
 ## Identifying Candidate Tables
 
diff --git a/content/en/docs/20.0/reference/features/vtgate-buffering.md b/content/en/docs/20.0/reference/features/vtgate-buffering.md
index 6e831a2e8..aad5a228e 100644
--- a/content/en/docs/20.0/reference/features/vtgate-buffering.md
+++ b/content/en/docs/20.0/reference/features/vtgate-buffering.md
@@ -22,6 +22,13 @@ with the simplest case: that of buffering during a PRS (PlannedReparentShard)
 operation. Examples of various edge cases can be found in
 [Buffering Scenarios](../../../user-guides/configuration-advanced/buffering-scenarios/).
 
+{{< warning >}}
+The buffering feature is not guaranteed to eliminate errors sent to the application, but
+rather reduce them or make them less frequent. The application should still endeavor to
+handle errors appropriately if/when they occur (e.g. unplanned outages, planned failovers,
+VReplication migrations, etc.)
+{{< /warning >}}
+
 ## VTGate flags to enable buffering
 
 First, let us cover the flags that need to be set in VTGate to enable
@@ -75,13 +82,13 @@ Fundamentally Vitess will:
  * Drain the buffered queries to the new `PRIMARY` tablet.
  * Begin the countdown timer for `buffer_max_failover_duration`.
 
- {{< warning >}}
-This process is not guaranteed to eliminate errors to the application, but
-rather reduce them or make them less frequent. The application should still
-endeavor to handle errors appropriately if/when they occur (e.g. unplanned
-outages/fail overs, etc.)
-{{< /warning >}}
+## What happens during a MoveTables or Reshard SwitchTraffic or ReverseTraffic with Buffering
+
+Fundamentally Vitess will:
 
+ * Hold up and buffer any queries sent to the tables (MoveTables) or shards (Reshard) for which traffic is being switched.
+ * Perform the traffic switching work so that application traffic against the tables (MoveTables) or shards (Reshard) are transparently switched to the new keyspace (MoveTables) or shards (Reshard).
+ * Drain the buffered queries to the new keyspace or shards — or if the switch failed then back to the original keyspace or shards.
 
 ## How does it work?
 
diff --git a/content/en/docs/20.0/reference/vreplication/movetables.md b/content/en/docs/20.0/reference/vreplication/movetables.md
index 10939712f..0ca61cb88 100644
--- a/content/en/docs/20.0/reference/vreplication/movetables.md
+++ b/content/en/docs/20.0/reference/vreplication/movetables.md
@@ -80,6 +80,10 @@ It is too expensive to get real-time row counts of tables, using _count(*)_, say
 
 [`switchtraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_switchtraffic/) switches traffic forward for the `tablet-types` specified. You can switch all traffic with just one command, and this is the default behavior. Note that you can now switch replica, rdonly, and primary traffic in any order.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when switching traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### ReverseTraffic
@@ -87,6 +91,10 @@ It is too expensive to get real-time row counts of tables, using _count(*)_, say
 
 [`reversetraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_reversetraffic/) switches traffic in the reverse direction for the `tablet-types` specified. The traffic should have been previously switched forward using `SwitchTraffic` for the `cells` and `tablet-types` specified.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when reversing traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### Cancel
diff --git a/content/en/docs/20.0/reference/vreplication/reshard.md b/content/en/docs/20.0/reference/vreplication/reshard.md
index aa6b011d2..1bf3a55d8 100644
--- a/content/en/docs/20.0/reference/vreplication/reshard.md
+++ b/content/en/docs/20.0/reference/vreplication/reshard.md
@@ -64,6 +64,10 @@ It is too expensive to get real-time row counts of tables, using _count(*)_, say
 
 [`SwitchTraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_switchtraffic) switches traffic forward for the `tablet-types` specified. This replaces the previous `SwitchReads` and `SwitchWrites` commands with a single one. It is now possible to switch all traffic with just one command, and this is the default behavior. Also, you can now switch replica, rdonly and primary traffic in any order: earlier you needed to first `SwitchReads` (for replicas and rdonly tablets) first before `SwitchWrites`.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when switching traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### ReverseTraffic
@@ -71,6 +75,10 @@ It is too expensive to get real-time row counts of tables, using _count(*)_, say
 
 [`ReverseTraffic`](../../programs/vtctldclient/vtctldclient_movetables/vtctldclient_movetables_reversetraffic/) switches traffic in the reverse direction for the `tablet-types` specified. The traffic should have been previously switched forward using `SwitchTraffic` for the `cells` and `tablet_types` specified.
 
+{{< info >}}
+Note that VTGate can [buffer queries](../../features/vtgate-buffering/) when reversing traffic which can virtually eliminate any visible impact on application users.
+{{</ info >}}
+
 </div>
 
 #### Cancel