skipping a migration is sometimes needed (bad script, applied out-of-band, or not relevant in test). How you do it depends on your tool:
🔹 Flyway
Flyway tracks migrations in a table called flyway_schema_history.
Options:
- Mark it as applied (skip execution)
flyway migrate -target=V5
Runs migrations up to V5. If your next file is V6__bad.sql, it won’t run.
Later, when you add V7__new.sql, Flyway will skip V6 because it sees V7 is next.
2. Baseline or repair trick
- If the migration was already applied outside Flyway, mark it with:
flyway baseline -baselineVersion=6
→ Flyway pretends everything up to version 6 is applied.
3. Mark individual migration as applied
- Insert a row manually into
flyway_schema_historywith the right version, description, checksum =null, and success =1. - Dangerous if done wrong, but effective.
🔹 Liquibase
Liquibase uses a DATABASECHANGELOG table.
Options:
- ChangeSet with
runAlways: false+runOnChange: false- By default, Liquibase already skips a changeset once it’s logged as applied.
- Mark as executed without running
liquibase changelogSync
→ Marks all pending changes as executed (skips them).
Or, more selectively:
liquibase changelogSyncSQL→ Generates SQL to insert rows into DATABASECHANGELOG for specific changesets.
Comment it out in changelog (not ideal — keeps history inconsistent if already deployed).
🔹 General Best Practices
- Don’t delete a migration file — it breaks history for anyone who hasn’t applied it yet.
- Mark it as skipped/applied so the migration tool’s history table stays consistent.
- Document why it was skipped — future teammates (or future you) will thank you.
- If it’s a bad migration, safer pattern is:
- Create a new “fix” migration instead of removing the old one.
- Only use skip tricks in dev/test, not prod.