Know what changes.
Know how it runs.

Create a SQLite database, apply a versioned change, and write its reverse. Choose either C# style; the runner is the same.

The core library, database driver, optional DI integration and CLI each have a distinct job.

Select the connection, migration set and history scope first, then set runner options before executing.

Decisions to make before adopting the library or moving an existing migration project.

Describe a complete table: columns first, with explicit named keys and constraints.

Rename objects and evolve populated tables while preserving the schema details you still need.

Type, size, precision, nullability, defaults, identity and collation are explicit column attributes.

Insert, update and delete using explicit column/value arrays. Keep predicates separate from changed values.

Read the connected database before deciding what to change. Metadata is different from a model snapshot.

Use schema operations where they fit, and keep database-specific SQL explicit.

Use the active provider connection when a migration needs driver-level work.

An index is a separate schema object, even when it enforces uniqueness.

Declare table invariants independently of column attributes.

Define ordered child/parent columns and independent actions for update and delete.

Distinguish values from SQL expressions, and comparison intent from a provider's installed collation name.

Use the same migration assembly in a dedicated host, a DI scope or the command-line tool.

List, validate, plan, preview, apply and reverse migrations from a deployment script.

Resolve the runner and migration dependencies inside one service scope.

A version plan answers what runs. SQL preview shows the supported operation SQL.

Transaction rollback and cross-process coordination solve different problems.

Number changes, keep applied source immutable and give independent modules explicit histories.

Select a subset of versioned migrations using explicit ordinal names.

Run explicitly selected work after versioned migrations without recording a version.

Place ordered work at the runner's lifecycle stages.

Fluent operations can describe a supported reverse sequence; Classic migrations author it directly.

One authoring contract, explicit database behavior. Choose the driver and provider together.

Change existing tables from the live schema, without maintaining an ORM model.

Explicit keys, provider-specific indexes, transactional DDL and application locks.

Native intervals, schema-aware metadata, transactional DDL and advisory locks.

Related providers with explicit engine, collation and DDL transaction differences.

Preserve explicit constraints and be deliberate about identity, sequences and implicit DDL commits.

Use the live-engine matrix to qualify operations beyond the common database families.

Choose between inspecting the live schema and declaring a provider-specific operation.

Reuse schema conventions without hiding provider behavior or changing the migration contract.

Verify stored data, preserved schema and repeat execution on the actual target engine.

Update source definitions while preserving the history your databases already contain.

A practical index of the two authoring surfaces and their shared provider contracts.

Make a provider change reproducible, then verify its observable behavior.