By default it is expected that you will deploy the same versioned and repeatable migrations against all environments in your deployment pipeline in the same order.

Within a single migration run, all pending versioned migrations are applied in order first followed by any repeatable migrations that have changed.

There are however some scenarios where it may be necessary to deploy different migrations against different environments or to deliberately run migrations out of order, and Flyway provides a number of features to help with this.

Grouping migrations into multiple locations and specifying different locations per environment

One powerful approach is to group migrations into multiple locations and specify different locations per environment.

This is done using the locations setting. The default can be set under the Flyway namespace in your TOML configuration file. It is also possible to configure this per environment in the TOML configuration file and to override it on the command line.

One common scenario where this is a convenient approach is SQL unit testing. You may want to deploy your test objects to development and testing environments so that the tests can run, but you may not want to deploy these to your production database. If you add your tests to a separate location from your other objects, you can specify this location only for the environments where it is desirable.

Cherry picking migrations

Flyway allows you to fully customize what migrations will be run and in what order using the cherry pick setting.

This is good for one off instances where you need to run a sub-set of the normal migrations, or need to work around deployment order.

It is also possible to save the cherry pick selection to your configuration file, maintaining a persisted fully customized deployment order, although this fully negates Flyway's default behavior and can become unwieldy.

Adding conditions to individual migrations

The shouldExecute option in Script Configuration gives you control over whether a specific migration is executed when Flyway Migrate runs.

The power of this configuration comes from the integration with placeholders that allow you to set the condition for a specific script and control that condition globally.