CUBA is most effective when developing an application from scratch: from model to database schema and UI. We have faced the problem of replacing legacy systems many times, and we always created new applications and custom migration procedures.
A one-time custom migrator can be created as a JMX bean with a single method. This method may work as follows:
- Open a connection to the legacy database
- Create new CUBA entity instances in the order of dependencies, which can be hard coded.
- Read old tables and fill entities with data from the old database.
- Save new entities via EntityManager.
If the database is large enough, all reading and writing should be divided into batches.
Theoretically, it should be possible to run a new CUBA application on the old database without migration, if you make the new model very close to the existing database. It will require adding some service fields (like CREATE_TS, UUID, etc.) to the tables and pre-populating them with default values. But anyway, there will be some restrictions, for example, composite keys are not supported.
We are considering adding the feature of generating “reconciliation” scripts between the data model and the legacy database to CUBA Studio. But at the moment I cannot say when it will be available.
As for using CUBA UI without middleware and database, I would not recommend it, because too much plumbing will be required.