What is usually done with Django migrations if the database schema is wider and shared by other applications?

Question

Django

Better on an example:
There is a project consisting of two parts:
1 - Application on dzhanga.
2 - An application (not necessarily in python) that constantly monitors external resources and fills the database.
Those. Both applications work with one DB. Moreover, the second one has tables in the schema exclusively for its own purposes, which Dzhang does not need to know about.
Because of this, it is somehow strange to define the entire database schema using Django ORM, and the structure of the entire project seems to me something like this:
|
`- django_proj (here is a jang application)
`- monitoring_app (here is an application that constantly fills the database. written in Java, Go or python)
`- db (and here the database schema and migration files of both structure and data are actually defined)
Thus, I keep the database schema in one place, which is rightly not included in any of the applications, as it applies to both. But what about junga models? Of course, I will make them all managed=False, but there will still be models from django.contrib.* applications (admin, auth, ..) that will require django migrations. And as a result, I will get two migration systems, which may also have to be synchronized somehow.
How do you deal with such situations? How is it usually done?

Answer 1

Djanga knows about everything
The application is written in python and works through the orm djanga and django commands
Reduces the number of problems by a couple of orders of magnitude
Even if you have to rewrite that application from another PL