diff --git a/docs/migrations.md b/docs/migrations.md
index b0924ace..949e4209 100644
--- a/docs/migrations.md
+++ b/docs/migrations.md
@@ -11,6 +11,31 @@ This guide outlines the configuration changes required when upgrading between ma
 
 ---
 
+## Upgrading from 3.x to 4.x
+
+RQueue 4.x switched from Jackson 2.x (`com.fasterxml.jackson`) to Jackson 3.x
+(`tools.jackson`). Jackson 3.x defaults to **alphabetical** JSON property ordering,
+while Jackson 2.x used **declaration order**. Messages enqueued by 3.x and messages
+enqueued by 4.x therefore have different byte representations in Redis.
+
+The processing queue uses byte-exact lookups (ZSCORE/ZREM) to move or acknowledge
+messages. If stored bytes do not match the re-serialised bytes, the lookup silently
+fails and the message is repeatedly re-delivered via the visibility-timeout rescue path.
+
+**If you are upgrading with messages still present in Redis**, set the following
+property to keep using declaration order (matching what 3.x stored):
+
+```properties
+rqueue.serialization.property.order=DECLARATION
+```
+
+{: .warning}
+After upgrading, changing `rqueue.serialization.property.order` away from
+its current value while messages are present in the processing queue will cause those
+messages to be unexpectedly retried. Drain the processing queue before switching values.
+
+---
+
 ## Upgrading from 2.9.0 to 2.10+
 
 Starting with version **2.10**, several configuration keys were renamed for consistency with the
@@ -73,28 +98,3 @@ ZCARD rqueue-processing::<queueName>
 
 If all commands return **0**, your queues are empty and you can proceed with the 
 migration without additional configuration.
-
----
-
-## Upgrading from 3.x to 4.x
-
-RQueue 4.x switched from Jackson 2.x (`com.fasterxml.jackson`) to Jackson 3.x
-(`tools.jackson`). Jackson 3.x defaults to **alphabetical** JSON property ordering,
-while Jackson 2.x used **declaration order**. Messages enqueued by 3.x and messages
-enqueued by 4.x therefore have different byte representations in Redis.
-
-The processing queue uses byte-exact lookups (ZSCORE/ZREM) to move or acknowledge
-messages. If stored bytes do not match the re-serialised bytes, the lookup silently
-fails and the message is repeatedly re-delivered via the visibility-timeout rescue path.
-
-**If you are upgrading with messages still present in Redis**, set the following
-property to keep using declaration order (matching what 3.x stored):
-
-```properties
-rqueue.serialization.property.order=DECLARATION
-```
-
-{: .warning}
-Changing `rqueue.serialization.property.order` while messages are present in the
-processing queue will cause those messages to be unexpectedly retried. Drain the processing
-queue before switching values.