简短的答案是， 不要这样做！！
但是，这种答案在现实生活中的项目和生产数据库的现实世界中很少起作用。因此，我创建了一个示例GitHub存储库来演示这个相当复杂的过程。
我正在使用MysqL。 （不，这些不是我的真实凭证）。
我使用的示例是带有 应用程序的工厂项目，该应用程序最初具有Car模型和Tires模型。
factory
|_ cars
|_ Car
|_ Tires
该Car模型具有与的ForeignKey关系Tires。（同样，您可以通过汽车模型指定轮胎）。
但是，我们很快意识到这Tires将是一个具有自己的视图等的大型模型，因此我们希望在其自己的应用程序中使用它。因此，所需的结构为：
factory
|_ cars
|_ Car
|_ tires
|_ Tires
而且我们需要保持Car和之间的ForeignKey关系，Tires因为太多依赖于保留数据。
设置具有不良设计的初始应用程序。
创建一个管理界面，并添加一堆包含ForeignKey关系的数据。
查看步骤2。
决定将Tires模型移至其自己的应用程序。认真地将代码粘贴到新的轮胎应用中。确保更新Car模型以指向新tires.Tires模型。
然后运行./manage.py makemigrations数据库并将其备份到某个地方（以防万一这失败了）。
最后，运行./manage.py migrate并查看Doom的错误消息，
棘手的部分。自动生成的迁移无法看到您只是将模型复制到其他应用程序。因此，我们必须做一些事情来纠正这一问题。
您可以按照步骤4的说明进行操作，并查看最终的迁移。我确实对此进行了测试以验证其是否有效。
首先，我们将继续工作cars。您必须进行新的空迁移。实际上，此迁移需要在最近创建的迁移（执行失败的迁移）之前运行。因此，我对创建的迁移进行了重新编号，并更改了相关性，以首先运行该自定义迁移，然后运行该cars应用程序的最后一个自动生成的迁移。
./manage.py makemigrations --empty cars
进行自定义 old_app 迁移。
在第一个自定义迁移中，我将仅执行“ database_operations”迁移。Django为您提供了拆分“状态”和“数据库”操作的选项。您可以通过在此处查看代码来了解如何完成此操作。
我第一步的目标是将数据库表从重命名oldapp_model为newapp_model而不弄乱Django的状态。您必须确定Django将根据应用程序名称和模型名称为数据库表命名的方式。
现在，您可以修改初始tires迁移了。
修改 new_app 初始迁移
操作很好，但是我们只想修改“状态”，而不是数据库。为什么？因为我们要保留cars应用程序中的数据库表。另外，您需要确保先前进行的自定义迁移是该迁移的依赖项。请参阅轮胎迁移文件。
因此，现在我们已在数据库中重命名cars.Tires为tires.Tires，并更改了Django状态以识别该tires.Tires表。
去 背 到汽车，我们需要修改最后自动生成的迁移。它应该需要我们的第一个定制汽车迁移和最初的轮胎迁移（我们刚刚修改）。
这里我们应该离开AlterField操作，因为Car模型 指向 的是另一个模型（即使它具有相同的数据）。但是，DeleteModel由于cars.Tires模型已不存在，因此我们需要删除与之相关的迁移线。已完全转换为tires.Tires。查看此迁移。
清理 old_app中的 陈旧模型。
最后但并非最不重要的一点是，您需要在cars应用中进行最终的自定义迁移。在这里，我们将执行“状态”操作，仅删除cars.Tires模型。它是仅状态的，因为的数据库表cars.Tires已被重命名。这最后的迁移清理剩余的Django的状态。
602392714
清零编程群