Move the boxing database to a separate server

It seems to me that this is a bad idea, since the consequences of not working on one server can be deplorable, as well as transmission delays between servers.
You would be better off solving problems with integrations, what you describe "implementations you can synchronize with boxing for a year" is not the norm

It is not a problem for us to keep two servers connected. They are in their hermetic zone. Solving the problem will allow all billing/ERP/etc systems to connect. to one database and make actual changes online.
Worse is the one whose crutch has been built now, as it turned out, this is a more complicated undertaking, which they have been trying to solve for more than a year. Namely, to build a synchronous import/export for billing<->CRM

What is stopping you from redoing the entire exchange through the API, here you will have both speed and access?
You just understand that if you let another developer into the database, then there will start a "shit" that you need to follow (log), and this is another "brute" for the project's PM

The lack of an API for the services with which a bundle is being built. One system without an API, the second works according to the API but only for import into the system, and any improvements are made only by their system developers (there is a dependence on the speed of implementing tasks). And Boxing with its API.
Its infrastructure is faster to implement. + for logging we will connect to graylog.

It's clear that you have a lot of variables in your task :)
Well, let's wait for the answer of Ustimenko or Miroshnichenko, it seems to me that they will not take on such a task, since there are a lot of pitfalls, including those responsible for product support, all this needs to be registered somewhere

The real pain of working in CRM is only increasing now, just imagine the whole way of registering a client in CRM now.
From telephony, a contact was made to the box, a card was created for him with full name and phone numbers, etc. Further, in order to provide the client with a service (TV / Internet, etc.), it must be transferred to billing (billing monitors payments and allows the Radius server to authorize the client)
Since there is no two-way import / export in box billing, you have to create an account separately in billing.
But import into boxing from billing works. Now Boxing is creating a duplicate of the application and it turns out that there is a duplication of clients in the box. (customers added in box and clients imported from billing)
It is undesirable to stop the import box, since it uses business processes and calculates the manager's RFP based on them)
And export from boxing does not yet fully work in billing in order to create an account in one system.
And there is also a third ERP system with which they planned to build integration, but now I’m wondering how much more time it takes :)
I hope I explained all the variables clearly.
I spoke with Miroshnichenko about this. Let's wait for his return, I understand that he is not available yet, let him get better.

Writing something directly to the OneBox database is not worth it (even "not allowed").
OneBox is not software that is written "from the database". Not so simple.
The OneBox database itself is not normalized according to all the canons of ANSI SQL. It's the price of performance for OneBox to be able to digest tens of millions of contacts and tens of millions of orders.
In simple words (for those who are not in the subject of SQL'a) - the same data can be duplicated in different cells of different tables. For sample performance.
The OneBox database is controlled by the so-called ORM SQLObject. This is an important story:
when OneBox is updated, SQLObject looks at which columns to add, which to remove, for which to change the data type. If you add a column to the database, it's okay, SQLObject won't touch it. But, if you manually change the column, SQLObject will return the data type in place in 1 minute according to the ORM configuration.
No one should be tied to OneBox'a database - because we are changing it.
We can easily rename the table, create a new table structure and convert data between them even within the same version, and the client will not even notice it.
---
Knowing how the billing systems of providers are usually arranged, I can say that the database there changes incredibly rarely. And it is much more correct and reliable to use such options:
Option 1 is the correct one
OneBox knocks on the billing API and changes what is needed there.
If there is no API, you can make quite specific php/perl/python/cgi scripts that will accept GET/POST parameters and run the required SQL.
Option 2
There is a certain script on the billing side (or close to it), which knocks on the OneBox API, receives the data, then changes the SQL in the billing.
Option 3
Transfer billing to OneBox'a side.
I understand that you will not agree to this now, but in fact even the first version of OneBox'a https://crm-onebox.com/en/version/ started with billing for the Internet provider and OneBox directly conducted billing and controlled raduis servers . Ah, those were good times :)
---
The coolest option 1 - make on your side a mega-simple API, without authorization (well, or IP restricted authorization), which will only do the necessary addition of a user update.
I understand that this is not an easy task.
Give the contact of a techie who cuts billing directly - and I will solve it. Only a techie directly, if there is some kind of manager and he will coordinate something - oh, that's all :)