Fixed #22032 -- added documentation for settings.MIGRATION_MODULES

2 files changed, 22 insertions, 0 deletions

diff --git a/docs/ref/settings.txt b/docs/ref/settings.txt
index 4e3e033b68..1b70c4db8a 100644
--- a/docs/ref/settings.txt
+++ b/docs/ref/settings.txt
@@ -1539,6 +1539,24 @@ Default::
 
 A tuple of middleware classes to use. See :doc:`/topics/http/middleware`.
 
+.. setting:: MIGRATION_MODULES
+
+MIGRATION_MODULES
+-----------------
+
+Default::
+
+    {} # empty dictionary
+
+A dictionary specifying the package where migration modules can be found on a per-app basis. The default value
+of this setting is an empty dictionary, but the default package name for migration modules is ``migrations``.
+
+Example::
+
+    {'blog': 'blog.db_migrations'}
+
+In this case, migrations pertaining to the ``blog`` app will be contained in the ``blog.db_migrations`` package.
+
 .. setting:: MONTH_DAY_FORMAT
 
 MONTH_DAY_FORMAT
diff --git a/docs/topics/migrations.txt b/docs/topics/migrations.txt
index 45fdc0bef0..7ab0135259 100644
--- a/docs/topics/migrations.txt
+++ b/docs/topics/migrations.txt
@@ -51,6 +51,10 @@ of, its codebase. You should be making them once on your development machine
 and then running the same migrations on your colleagues' machines, your
 staging machines, and eventually your production machines.
 
+.. note::
+    It is possible to override the name of the package which contains the
+    migrations on a per-app basis by modifying the :setting:`MIGRATION_MODULES` setting.
+
 Migrations will run the same way every time and produce consistent results,
 meaning that what you see in development and staging is exactly what will
 happen in production - no unexpected surprises.