diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx
index 2c43cda3ee18f..1ffa04e3399a6 100644
--- a/develop-docs/backend/application-domains/database-migrations/index.mdx
+++ b/develop-docs/backend/application-domains/database-migrations/index.mdx
@@ -134,9 +134,9 @@ This is complicated due to our deploy process. When we deploy, we run migrations
 
 To avoid this, follow these steps:
 
-- Make a PR to remove all uses of the column in the codebase in a separate PR. This mostly helps with code cleanliness. This should be merged ahead of the migration prs, but we don't need to worry about whether it is deployed first.
+- First, if the column is either not nullable, or doesn't have a `db_default` set, then make a PR to make it nullable via `null=True`.
+- Then, remove all uses of the column in the codebase in a separate PR; this mostly helps with code cleanliness. This should be merged ahead of the next migration PRs, but we don't need to worry about whether it is deployed first.
 - Make another PR that:
-    - Checks if the column is either not nullable, or doesn't have a `db_default` set. If either of these is true, then make it nullable via `null=True`.
     - If the column is a foreign key, remove the database level foreign key constraint it by setting `db_constraint=False`.
     - Remove the column and in the generated migration use `SafeRemoveField(..., deletion_action=DeletionAction.MOVE_TO_PENDING)` to replace `RemoveField(...)`. This only marks the state for the column as removed.
     - Combine these migrations together to save making multiple deploys