Migration, step by step
A migration is a sequence of reversible steps with a check after each one. When a check cannot reach a verdict, the run says so instead of calling it a success.
The steps
- Restore point— taken on the destination before anything is written.
- Extensions— installed first, because the schema depends on them.
- Schema— every project schema, with the search path of the source carried along so custom types resolve.
- Authentication— users and identities. Password hashes are carried when their format is portable; when it is not, that is recorded as a limitation rather than worked around.
- Data— table contents, with row counts and content compared afterwards.
- Storage— buckets and objects, with path, type, size, owner and access policies checked, and bytes compared.
When something fails
The step is retried where retrying is safe. If it still fails, completed steps are undone in reverse order and the destination returns to the restore point. The run is recorded as compensated — not as a success with a footnote.
When you cancel
The step in progress finishes, then the run stops and the destination returns to the restore point. Interrupting a copy halfway would leave a state nobody has described, so the engine does not offer that.
Honest limits
What has been measured
- Verified against a real hosted project in the laboratory: schema, extensions, authentication users, table data and file storage, with 11 checks passed.
- A process stopped mid-run resumed from its journal and finished without redoing completed work.
What has not
- Active sessions. They do not transfer — the tokens belong to the old platform.
- Platforms other than the one measured. Each source is its own connector, and each connector is its own measurement.
- Migrations that depend on data present only in the source database may need adaptation before they can run; the plan reports them.
Try it on a disposable destination first
A pilot starts with a rehearsal against a throwaway destination, never against the system you depend on.