Migrations
One-way doors that deserve a plan you can read first.
Migrations are the work where the plan matters more than the code. They are usually performed once, often under time pressure, frequently by whoever is available, and they are the changes that are hardest to reverse. The failure mode is not a bug; it is a Tuesday spent restoring from backup.
The same loop, applied to this problem.
A plan you can read before anything moves
Fidelio produces a versioned plan from your intent. For a migration this is the deliverable that matters most — it is reviewable, arguable and revisable while the change is still hypothetical.
Independent review of the steps
The reviewer grades the built migration against the intent, including the parts that are easy to omit under pressure: ordering, reversibility, and what happens to rows that do not fit the new shape.
An explicit gate on a one-way door
Nothing executes because a run completed. A person approves, which is the appropriate amount of ceremony for a change that is difficult to undo.
Things teams actually ask for.
Written the way a request arrives, not the way a feature list describes it.
- A column split with a documented backfill and rollback path
- A move between providers with a verified restore step, not an assumed one
- A tenancy change that proves isolation holds before and after
- A dependency upgrade with the breaking changes enumerated in the plan
Common questions.
- Will Fidelio run a migration automatically?
- No. Execution is behind a human deploy gate. For irreversible work that gate is the entire point.
- Can I get just the plan without the build?
- The versioned plan is produced before the build step and is a reviewable artifact in its own right, so you can read and revise it before deciding to proceed.
Put an intent in and see what comes back.
Every run produces a plan, a build, an independent review, and a gate you control.