Is this a Flyway use case

Flyway allows you to change your database by running a set of scripts in a defined order. These scripts are called 'migrations' as they allow you to 'migrate' your database from one version to another.

The idea is you can start with an an empty database and each migration script will successively bring that database up from empty up to the current version. However, it's also possible to start with an existing database by creating a 'baseline' migration.

As SudhirR said, Flyway's primary use case is to define schema changes. However, it's perfectly possible to change data also. Since Flyway is just running plain SQL, in principle almost anything you can do in a SQL script you can also do in a Flyway migration.

In the case you described it should be possible to use Flyway to migrate the customer database. The steps you could take are:

• 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 the reference data present in the database.
• Save this script in your Flyway project as something like 'V1__base_version.sql'
• Run the flyway baseline command against your production database
  • This will set up your production database for use with Flyway
• Add a new migration script to migrate your customer's data to the new version
  • e.g. create new table, copy data from old table to new table, delete old table
• Run flyway migrate to upgrade production

These steps are adapted from the Flyway documentation page here.

Of course you should read the Flyway docs and manually test on a throwaway DB before you run anything against production. However I think in principle Flyway could be a good fit for your use case.

Flyway should be used for schema migrations and any reference data (basic data that is required by the system/application in order to function properly).

Putting client specific data migrations would not be a use case. However, if you can represent the data migration "generically" by not using IDs and instead use names or types than it could be a candidate. Meaning if you could write a migration in a way that could be applied to all clients, then that would be the use case to put it in as a flyway migration.

Otherwise data migrations would be applied in some other way outside of the process like requesting special access to the database or having some team that manages the database to apply the scripts.

If you are doing custom data modifications quite often then I'd say something is wrong in some other area of the SDLC and you may need to increase testing so that bugs don't mess up the data in the first place.