Refs #27236 -- Added generic mechanism to handle the deprecation of migration operations.

docs/topics/checks.txt

@@ -128,18 +128,18 @@ The code below is equivalent to the code above::
 
 .. _field-checking:
 
-Field, model, manager, and database checks
-------------------------------------------
+Field, model, manager, migration, and database checks
+-----------------------------------------------------
 
 In some cases, you won't need to register your check function -- you can
 piggyback on an existing registration.
 
-Fields, models, model managers, and database backends all implement a
-``check()`` method that is already registered with the check framework. If you
-want to add extra checks, you can extend the implementation on the base class,
-perform any extra checks you need, and append any messages to those generated
-by the base class. It's recommended that you delegate each check to separate
-methods.
+Fields, models, model managers, migrations, and database backends all implement
+a ``check()`` method that is already registered with the check framework. If
+you want to add extra checks, you can extend the implementation on the base
+class, perform any extra checks you need, and append any messages to those
+generated by the base class. It's recommended that you delegate each check to
+separate methods.
 
 Consider an example where you are implementing a custom field named
 ``RangedIntegerField``. This field adds ``min`` and ``max`` arguments to the
@@ -194,6 +194,10 @@ the only difference is that the check is a classmethod, not an instance method::
             # ... your own checks ...
             return errors
 
+.. versionchanged:: 4.2
+
+    Migration checks were added.
+
 Writing tests
 -------------