A database migration is a versioned transformation that moves a database schema or its stored data from one known state to another.

Ordered history

Instead of editing a deployed schema manually, a project records changes in order:

001 create users
002 add user email
003 create orders

Each environment can then determine which migrations have already been applied and execute the remaining ones consistently.

Schema and data changes

A migration may create or alter tables, keys, constraints and indexes. It may also transform existing rows when a new representation requires old data to be converted.

A migration should represent one coherent transition and make its assumptions explicit.

Forward and reverse transitions

Some migration systems define both an upgrade and a downgrade. A reverse migration is only valid when the previous state can actually be reconstructed; destructive transformations may require accepting that some data cannot be recovered automatically.

Applied migrations are history

Once a migration has been used by shared or production databases, changing its contents can make environments disagree about what the same migration identifier means. New corrections should normally be expressed as later migrations.

Verification

Migrations should be exercised against the real database engine when correctness depends on its SQL semantics. Useful checks include applying migrations from a clean database, upgrading existing states and, when reversibility is promised, testing rollback and reapplication.

Migrations turn schema evolution into reproducible application history rather than a sequence of manual database edits.