Once the 3scale operator of any older version is installed on a cluster with 2.12 installed all the APIManager objects are changed to a prior version. This causes all configurations related to the external databases to be completely lost.
The impact of this situation can be then divided into two scenarios:

2.12 with external MYSQL:

In this case the operator treats the APIManager as one configured with internal databases and hence deploys them. The deployment of 3scale is not connected to those newly created databases since all the configuration secrets still point to the original external database. In this case, it seems that reconciliation is working as well to some degree.

2.12 with other external DB (Postgres, Oracle):

As in the situation above, the operator tries to treat the APIManager object as default deployment with an internal Mysql database, but since the configuration points to a different kind of DB (e.g. Postgres or oracle), the operator gets to an error loop and all of the reconciliation is broken.

This issue can be manifested by simple installation from the UI - it is not necessary to perform a complete installation of 3scale, it is enough to install an operator with namespace availability. In this situation, users are not even notified that they might be doing anything dangerous or unsupported.