These are the steps to follow to successfully integrate Flyway into a project with existing databases.
If you are new to Flyway, read through our getting started section first.
First start by taking a snapshot of your most important database: production. This will be the starting point for migrations.
Generate a SQL script that includes the entire DDL (including indexes, triggers, procedures …) of the production database. To do this you will need to add insert statements for all of the reference data present in the database.
This script will form your baseline migration. Save it in a location specified in the locations property. Give it a relevant version number and description such as
Now comes the point where we have to make sure that the migrations meant for production will work everywhere with the clean command.
For all databases with unimportant data that you don’t mind losing, execute:
> flyway clean
by altering the url to completely remove their contents.
Now you need to check all remaining databases (e.g. test). You must make sure that their structure (DDL) and reference data matches production exactly. This step is important, as all scripts destined for production will likely be applied to these databases first. For the scripts to succeed, the objects they migrate must be identical to what is present in production.
Now comes the time to baseline the databases that contain data (including production) with a baseline version. Use the same version and description you used for the baselined migration above (
You can accomplish it like this:
> flyway -baselineVersion="1" -baselineDescription="baseline_migration" baseline
You must perform this step for each database that hasn’t been cleaned by altering the url again.
Congratulations! You are now ready.
When you execute:
> flyway migrate
against the empty databases (by altering the url), they will be migrated to the state of production and the others will be left as is.
As soon as you add a new migration, it can be applied identically to any of your databases.