Sometimes generating and using a baseline script is problematic for the following reasons.

1. It might take a long time to execute due to a large number of schema objects, or a large number of migration scripts.
2. It might be a legacy database that has invalid objects that can't be rebuilt from scratch. 
3. There may be circular dependencies across databases

In these scenarios, using a clone as the baseline is a good option. Only one person needs to configure this for your project, but all users will need the clone technology on the machine they are using Flyway Desktop.

Preparing your clone

1. Make sure you have an image that represents your baseline
   If you don't have access to Production, that's ok.  You just need a copy of what Production looks like.  This could be a recent backup, a cleansed Staging environment, or maybe even asking a Production DBA to generate this for your team.
   

   1. Keep only the database objects that you need (e.g., if this database supports 5 different applications, but you're currently only working on a single schema within it, you could limit the image to just that one schema.  You'll want to delete or clean the transactional data, especially any sensitive data. 

2. Capture the baseline in the database.
   This step can be skipped if your database has a flyway_schema_history.

   If flyway hasn't been used on this database, there will be no flyway_schema_history. This helps flyway understand that this database is already at a certain version and only versioned migration scripts with a bigger version number should be applied to this database. To create the flyway_schema_history use the flyway baseline command and specify a baselineVersion parameter to let Flyway known where to run migrations scripts from. If this is a new Flyway Project, you’re baselineVersion can be 0 since the next script we generate will be 001 by default. 
   Some teams like to match their database version scripts with a numbering system that is already in use for the corresponding application.  For example, if you're application code is at V8.4 and your database works with this, then your baselineVersion can be set to 8.4.  Just make sure to set the next versioned migration script to be 8.4.1 or higher so that the future changes will be applied. 

   1. flyway baseline -baselineVersion=<your_version_number> -url=<jdbc_connection_string> -user=<your_db_username> -password=<your_db_password>

   Learn more about flyway baseline. 
   
   

   Note: The flyway baseline command is different than the baseline (script/clone/backup). The flyway baseline command indicates that the target database is being tracked by flyway and only migrations higher than this number should be applied to it.  Running flyway baseline creates the flyway_schema_history table on your target database so that flyway knows which migrations to apply going forward.  Learn more about versioned migration scripts. 

Configure Redgate Clone as a provisioner for the shadow database (Redgate Clone only - preview)

1. Open the shadow database connection dialog and configure it to use your baseline image
   In the connection dialog, select Redgate Clone from the provisioner dropdown and fill in the required fields as detailed here.

   Verify that the connection is successful and save and close the dialog.

2. Start generating migrations without generating a baseline script
   You are now set to generate migrations as normal. You should ignore the prompt to generate a baseline migration, which will go away once you have generated a migration.

Set up your clone to be used as the baseline (when not using Redgate Clone)

1. Create the afterClean.sql callback.
   In your Flyway Project's migrations folder, create a new file called afterClean__Clone-as-Baseline.sql. (CallBack scripts are feature of Flyway which give you a lot of additional control when migrating changes. Write the code to restore your clone the following as an example.  
   
   

   # Recreate the clone
   rgclone create data-container --image=<my_baseline_image> --name=<my_project_shadow_db> --lifetime=8h
    # Update shadow proxy to new connection details# TODO:

   
   
   

2. Share the callback script with your team
   Save this file.  After testing, you'll want to commit/push this to your repository, so your team members can also use this clone as baseline feature.  

Cloning Technologies 

X-Database

Learn more about the supported databases in Redgate Clone.

SQL Server only

Use SQL Clone to spin up multiple copies of your databases quickly.  This is great for dev/test purposes. 

Oracle only

If you are using a Pluggable Databases (PDB) in Oracle, then you may be able to use the Clone PDB feature.  There's more information about this on the Oracle docs.

Get in touch with Redgate to learn more about these options.