# Force Migrations on new MySQL Database **URL:** \ **Category:** Using the ORM\ **Created:** [June 9, 2025, 3:38pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368 "2025-06-09T15:38:38Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![PyPHAnetwork](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/pyphanetwork/32/28160_2.png) [@PyPHAnetwork](https://forum.djangoproject.com/u/PyPHAnetwork)\ **Post date:** [June 9, 2025, 3:38pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/1 "2025-06-09T15:38:39Z")
I have a newly created Django project/app and I created the initial migrations in SQLLite just to make sure I could run the app and also login to the Admin dashboard. All that is fine. I then created a new MySQL database and I replaced the SQLLite connection with the MySQL connection. I can run the app wthout issues, and it properly connects to the MySQL db. Now, I want to run all the migrations on the new DB to create all of the authorization tables, and then CreateSuperuser to create the admin user in this new MySQL database. Are there some guidelines on how to do this? I have read where I need to delete all files in the **Migrations** folders under .venv\Lib\site-packages\django\contrib folder such as admin, auth, etc. I just want to make sure I am not deleting anything that shouldn’t be removed. I tried this previously and must have deleted a file that should not have been deleted, because the app stopped working. I just deleted the whole project and started over at that point, since I hadn’t gotten too far into it. If there is any guidance on this, I would appreciate it. Thanks! ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [June 9, 2025, 3:56pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/2 "2025-06-09T15:56:16Z")
You shouldn’t need to do anything special. Once you’ve changed the DATABASES setting to point to your new database, then just run `migrate`. Do **not** delete any of your migrations - it’s not necessary. (In the general case, you should **never** delete any migration files - _especially_ after they’ve been applied.) ---
**Author:** ![PyPHAnetwork](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/pyphanetwork/32/28160_2.png) [@PyPHAnetwork](https://forum.djangoproject.com/u/PyPHAnetwork)\ **Post date:** [June 9, 2025, 6:02pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/4 "2025-06-09T18:02:18Z")
I tried that and it showed that no migrations were needed. But then I realized I hadn’t switched the data source back to the MySQL database, so I did that and tried to migrate again and got this error. MySQLdb.OperationalError: (1050, “Table ‘auth\_permission’ already exists”) However, I can confirm that the database in question has no tables, so I’m not sure where it is looking to determine which tables already exist. There are two other Django apps on the local MySQL server, so I’m wondering if it is somehow getting confused with one of those?? ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [June 9, 2025, 6:05pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/5 "2025-06-09T18:05:20Z")
> [@PyPHAnetwork](#): > > However, I can confirm that the database in question has no tables, so I’m not sure where it is looking to determine which tables already exist. It is looking at the database identified in the DATABASES setting. I would suspect that the database you are looking at is _not_ the database configured for your project. > [@PyPHAnetwork](#): > > There are two other Django apps on the local MySQL server, so I’m wondering if it is somehow getting confused with one of those?? As long as those other two projects are using a different database than the one you’re trying to use, there is no conflict. ---
**Author:** ![PyPHAnetwork](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/pyphanetwork/32/28160_2.png) [@PyPHAnetwork](https://forum.djangoproject.com/u/PyPHAnetwork)\ **Post date:** [June 9, 2025, 6:28pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/6 "2025-06-09T18:28:23Z")
Okay, all set. I wasn’t seeing the tables created in the database through JetBrains DataGrip, and I had done, what I thought was unsuccessful migrations before this. I didn’t realize that I had to do refresh in DataGrip to see the updates, but now I am seeing them. Thanks for you help! ---
**Author:** ![PyPHAnetwork](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/pyphanetwork/32/28160_2.png) [@PyPHAnetwork](https://forum.djangoproject.com/u/PyPHAnetwork)\ **Post date:** [June 11, 2025, 3:29pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/7 "2025-06-11T15:29:27Z")
Okay, I have a follow-up to this. Apparently, there are still some migration issues. I created a new model but the migrate command failed with the following error. django.db.utils.OperationalError: (1050, “Table ‘django\_admin\_log’ already exists”) I can see that the django\_admin\_log table is in fact created in the database. The problem is that when I get this error, the migration stops and it doesn’t create the table for the new model that I created. Is there any way to clear the status of the previous migrations so that I can create the new model? I tried **python manage.py migrate --fake auth** in order to clear the status of all authorization tables and that helped a bit as the initial error concerned the **auth\_user** table and I no longer see that error message. Is there another fake command that works with the **django\_admin** tables? Thanks! ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [June 11, 2025, 3:52pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/8 "2025-06-11T15:52:56Z")
> [@PyPHAnetwork](#): > > Is there another fake command that works with the **django\_admin** tables? There’s only one “fake” parameter, and what follows it in the command line is the name of the app to which it is applied. So yes, you can use that with `admin` as the parameter instead of `auth`. But I’d be _more_ concerned about getting these errors at all. Are you making any manual changes to your migration files? Did you manually create or alter _any_ tables within your database? Delete contents of any system-related tables? If any of these is true, then this is another case where I’d suggest deleting the database and recreating it. Then run migrate to ensure _everything_ is created as it’s supposed to be. (Running with `fake` is a work-around, and can create other issues on its own. It’s not a “guarantee fix” for anything.) The key lesson to learn here is to **not** second-guess what migrate is doing. If you’re going to use migrations to manage the database, then let it do so. You’re best served by not interfering with its normal operations. If you’re going to manually manage your database, that’s ok too - there are cases where it may be appropriate to do so. But when you do run into a situation like that, then do not try to add `migrate` into the mix. ---
**Author:** ![PyPHAnetwork](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/pyphanetwork/32/28160_2.png) [@PyPHAnetwork](https://forum.djangoproject.com/u/PyPHAnetwork)\ **Post date:** [June 11, 2025, 5:12pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/9 "2025-06-11T17:12:54Z")
Okay, thanks Ken, and I agree that I should let the migration process take its course. That has always worked for me with other projects, but for some reason, this project got a bit messed up, I think when I switched the DB to MySQL. I have basically two options at this point. I can trash the whole project and start over. I’m only about 4 hours into it, so not the worse thing in the world. That might be the way to go to make sure I have a clean start. The other option as you said, is that I can delete and recreate the database. At this point, it only has the _initial_ Django admin tables, so not a big deal. My question about this though, is how will the **migrate** process know to create all of the tables? Does it actually check the schema of the database, or does it just view the log files within Django to determine if the migrations were done? I’d hate to delete and recreate the database, only to continue to have problems with the migration process. Your thoughts on this? ---
**Author:** ![KenWhitesell](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.djangoproject.com/kenwhitesell/32/280_2.png) [@KenWhitesell](https://forum.djangoproject.com/u/KenWhitesell)\ **Post date:** [June 11, 2025, 5:51pm UTC](https://forum.djangoproject.com/t/force-migrations-on-new-mysql-database/41368/10 "2025-06-11T17:51:29Z")
> [@PyPHAnetwork](#): > > My question about this though, is how will the **migrate** process know to create all of the tables? The migrate process maintains a migrations table in the database. That’s what it uses to determine which migrations have been applied. See the docs at [Migrations | Django documentation | Django](https://docs.djangoproject.com/en/5.2/topics/migrations/#module-django.db.migrations) for more details. The `makemigrations` command will create migration files, and you can create migration files manually. The `migrate` command will only read them - it doesn’t make any changes to your system. The only changes that `migrate` will make will be to the database. > [@PyPHAnetwork](#): > > I think when I switched the DB to MySQL. Changing databases isn’t going to cause problems, unless you’ve done something to interfere with the processes such as deleting migrations files or any other similar mistake. Two keys to keep migrations happy: - Don’t alter (edit or delete) migration files, especially after they’ve been applied - Don’t manually alter any database table that is being managed by migrations. If you strictly follow those two rules, you’ll generally find that everything works quite smoothly.