Move from Flyway
Your applied history moves across intact. import-flyway reads Flyway's own history table and writes those records into DBLift's, so every version keeps its identity instead of collapsing into a single baseline row.
Import the history
The default Flyway source table is flyway_schema_history on every database, so most projects need no flags at all.
dblift import-flyway
If your Flyway installation uses a different source table:
dblift import-flyway --flyway-table custom_flyway_history
Use --table only to choose the target DBLift history table:
dblift import-flyway --flyway-table custom_flyway_history --table dblift_schema_history
| Flag | Points at |
|---|---|
--flyway-table | The source — Flyway's table. Default flyway_schema_history. |
--table | The target — DBLift's table. Default dblift_schema_history. |
Verify before you migrate
Check that the imported history matches what you expect, then that your files agree with it.
dblift infodblift validate
Checksums carry over
DBLift computes Flyway-compatible CRC32 checksums, so imported rows keep matching your unchanged files. The import also translates Flyway's type vocabulary to DBLift's and reconciles signed against unsigned CRC values. If validate does report drift, treat it as a real difference and investigate the file — not as an import artifact to paper over.
Your migration files stay where they are
DBLift reads the same V{version}__{description}.sql convention Flyway uses, so the SQL you already have keeps working. What changes is that undo files are yours to write — see the Undo model.
Read next
- Flyway for a Python shop: the full move, with the Java-migration rows and the Django setup, from a real run.
- Undo model: what an undo file is, since Flyway's Teams-only undo is yours to write here.
- Migrations and versioning: out-of-order versions,
--strict, and whatvalidatechecks.