What is Database Migration?
Definition
Database migration is used two ways in practice. Day to day, it usually refers to the ongoing process of applying incremental schema and data changes as an application evolves, the same thing a ChangeLog is built to manage. Less frequently, it refers to a larger one-time effort: moving an entire database to a new platform (from one vendor's database to another, for instance) or a major version upgrade, which typically involves translating structure, migrating data, and validating that both behave correctly afterward. The incremental kind is continuous and low-risk per change; the platform-level kind is usually a bounded project with its own testing and cutover plan, precisely because the scope and risk are so much larger.
The two meanings of database migration
Most references to database migration, particularly in a CI/CD context, mean the everyday practice of applying changes to a database over time as an application evolves, adding a column here, an index there, tracked and versioned the same way application code is. A smaller number of references mean something bigger: moving from one database platform to another, or a major version jump, which involves not just applying changes but validating that data, behavior, and performance all hold up on the new platform. Both usages appear frequently enough in practice that it's worth clarifying which one a given conversation means before assuming.
Why the distinction matters
Treating a platform migration like routine schema migration risks underestimating it: a one-time move to a new database vendor typically needs its own data validation, performance testing, and cutover plan, not just a ChangeLog of structural changes. Conversely, treating routine ongoing changes like a major migration project, with the ceremony that implies, slows down work that should be routine. Most organizations do far more of the everyday kind than the platform-level kind, which is why tooling built for continuous, incremental migration looks different from a one-time migration toolkit. Getting the scope wrong in either direction tends to be expensive: underestimating a platform migration leads to surprises late in the project, and overestimating routine work slows a team down for no real benefit.
How Liquibase helps
Liquibase is built primarily for the everyday, ongoing kind of database migration: a ChangeLog captures each incremental schema and data change, applied consistently across environments as an application evolves. Because Liquibase supports more than sixty database platforms through the same declarative change types, it can also support the platform-level kind, translating the same structural changes to a new database's syntax as part of a larger migration project, so the two kinds of migration described here aren't necessarily separate tools, just different scales of the same underlying model.
