diff --git a/supporting-docs/howtos/client-server-migrating-from-v1.rst b/supporting-docs/howtos/client-server-migrating-from-v1.rst
index d96daa1d..5633d387 100644
--- a/supporting-docs/howtos/client-server-migrating-from-v1.rst
+++ b/supporting-docs/howtos/client-server-migrating-from-v1.rst
@@ -45,10 +45,6 @@ following summary may be useful to compare with ``v1``:
    for clients to represent state changes that occur within the region of
    returned timeline.
 
- * Additionally, the ``state`` contained in the ``/sync`` response by default
-   only contains keys that have changed since the basis given in the ``since``
-   parameter, rather than containing a full set values.
-
  * In ``/events`` if more events occurred since the ``since`` token than the
    ``limit`` parameter allowed, then events from the start of this range were
    returned and the client had to perform another fetch to incrementally obtain
@@ -57,6 +53,11 @@ following summary may be useful to compare with ``v1``:
    requested limit. If this occurs then the client can use the ``prev_batch``
    token as a reference to obtaining more.
 
+ * Additionally, the ``state`` contained in the ``/sync`` response that has a
+   ``since`` parameter will contains only keys that have changed since the
+   basis given in the ``since`` parameter, rather than containing a full set
+   values.
+
 There is no direct replacement for the per-room ``/rooms/:roomId/initialSync``
 endpoint, but the behaviour can be recreated by applying an ad-hoc filter using
 the ``filter`` parameter to ``/sync`` that selects only the required room ID::