[3.0.x] Removed obsolete references to South database migrations.

Backport of 291539a85c8461456ab728fe6820a86de54294b6 from master

2 files changed, 1 insertions, 10 deletions

diff --git a/docs/ref/migration-operations.txt b/docs/ref/migration-operations.txt
index 27ffc43c52..412d5196a6 100644
--- a/docs/ref/migration-operations.txt
+++ b/docs/ref/migration-operations.txt
@@ -368,15 +368,6 @@ This is generally the operation you would use to create
 custom data updates and alterations, and anything else you need access to an
 ORM and/or Python code for.
 
-If you're upgrading from South, this is basically the South pattern as an
-operation - one or two methods for forwards and backwards, with an ORM and
-schema operations available. Most of the time, you should be able to translate
-the ``orm.Model`` or ``orm["appname", "Model"]`` references from South directly
-into ``apps.get_model("appname", "Model")`` references here and leave most of
-the rest of the code unchanged for data migrations. However, ``apps`` will only
-have references to models in the current app unless migrations in other apps
-are added to the migration's dependencies.
-
 Much like :class:`RunSQL`, ensure that if you change schema inside here you're
 either doing it outside the scope of the Django model system (e.g. triggers)
 or that you use :class:`SeparateDatabaseAndState` to add in operations that will
diff --git a/docs/ref/schema-editor.txt b/docs/ref/schema-editor.txt
index a80d45c573..8374fdc26e 100644
--- a/docs/ref/schema-editor.txt
+++ b/docs/ref/schema-editor.txt
@@ -180,7 +180,7 @@ without losing data, and so it will refuse to do it. Instead,
 If the database has the ``supports_combined_alters``, Django will try and
 do as many of these in a single database call as possible; otherwise, it will
 issue a separate ALTER statement for each change, but will not issue ALTERs
-where no change is required (as South often did).
+where no change is required.
 
 Attributes
 ==========