Short answer: the migration tool will fail fast and refuse to continue — and that’s a feature, not a bug.
All serious migration tools do checksum validation.
After a migration is applied
The tool stores metadata in a DB table:
- Flyway →
flyway_schema_history - Liquibase →
DATABASECHANGELOG
That row includes:
- migration identifier (version / changeset id)
- checksum (hash of the file contents)
- execution timestamp
- success flag
When you modify the file later
Example:
-- originally applied
V3__add_email.sql
ALTER TABLE users ADD COLUMN email TEXT;
Later someone edits it:
ALTER TABLE users ADD COLUMN email VARCHAR(255);
On next startup / deploy
- Tool recalculates checksum from the file
- Compares it with the checksum stored in DB
- Mismatch detected
- 🚨 Migration fails immediately
Typical errors:
Flyway:
Validate failed: Migration checksum mismatch for version 3
Liquibase:
Validation Failed: changeset checksum changed
Why tools are so strict (this is the key insight)
Migrations are not scripts — they are historical facts.
Once applied:
- they must be immutable
- changing them means:
- prod ≠ staging ≠ local
- history is rewritten
- state is no longer reproducible
If tools allowed this silently, you’d get schema drift and non-deterministic environments.
What you should do instead (correct practice)
✅ Fix forward
If migration V3 was wrong:
V4__fix_email_column.sql
ALTER TABLE users ALTER COLUMN email TYPE VARCHAR(255);
History stays intact, state is correct.
“But Liquibase allows clearing checksums…”
Yes — and this is where interviewers watch your reaction.
Liquibase escape hatch
liquibase clearCheckSums
This:
- recomputes checksums
- updates
DATABASECHANGELOG
Why this is dangerous
- hides history corruption
- makes environments diverge
- should never be used casually in prod
✅ Acceptable only when:
- change is metadata-only (comments, formatting)
- change was never deployed to prod
- under strict review
Common interview traps ❌
“You can just edit the migration and re-run it.”
🚨 Red flag. That breaks determinism.
“Delete the history table and start fresh.”
🚨🚨 Massive red flag.
Interview-perfect answer (2–3 sentences)
Migration tools store a checksum of each applied migration in a schema history table.
If the migration file is modified later, the checksum no longer matches and the tool fails validation to prevent history corruption.
The correct fix is to add a new migration, not to edit an applied one.
Senior rule to remember
A bad migration is fixed with a new migration, never by rewriting history.