Kizaki
Concepts

Migration Lifecycle

Schema changes should move through a repeatable path from local edit to committed migration to deployed environment.

The recommended lifecycle is:

  1. edit Inspire
  2. generate a migration
  3. review the plan
  4. apply locally
  5. deploy

Why This Lifecycle Exists

Schema changes are one of the few places where product speed and operational risk collide directly. A team wants to move quickly, but production data needs a reviewable history.

Kizaki handles that tension by separating:

  • the schema you want
  • the migration plan that gets you there
  • the environments that need to apply that plan

This is why Kizaki treats migration files as part of your app source rather than hidden state.

What A Healthy Workflow Looks Like

In practice, healthy schema work means:

  • schema edits happen in Inspire
  • migrations are generated soon after the schema change
  • plan.inspire is reviewed before deploy
  • local and hosted environments converge through the same history

That discipline is what lets Kizaki promise a faster workflow without making schema evolution casual or opaque.

On this page