Batch»
Step 6 of the migration walkthrough: choose which units migrate in this batch. Migrations are iterative — you don't move the whole estate at once, you stage a batch, migrate it, then come back for the next.
liftoff batch list — see what's there»
1 | |
Lists every migratable unit — spaces, stacks, modules, contexts — with its current staging status.
Variables and mounted files aren't listed: they're far too many, and they ride along with their owner automatically.
Filter with --status unstaged|staged|migrated and --kind space|stack|module|context.
1 2 3 4 5 6 7 8 9 10 11 12 | |
Everything lands unstaged after discover — "not yet triaged."
You stage the units you want in this batch, and re-run list (or list --status staged) to see the batch take shape.
liftoff batch stage — pick the batch»
1 | |
Selectors are <kind>:<id> (the Kind and Id columns from list); pass as many as you like, or --all for a full lift-and-shift.
Staging cascades: a staged stack pulls in the spaces it sits under and the contexts attached to it, so the batch always renders without dangling.
The result shows what changed and why each dependency came along:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
Via reads requested for a unit you named, and <kind> <id> for one pulled in by the cascade — here staging the stack brought its project space, that space's parent, and its attached context.
Staging only ever pulls upward. It stages what a unit needs, never what a unit contains. Spaces are where that catches people out, because staging one does not stage the stacks inside it:
1 2 3 4 | |
Two spaces changed, the requested one and its parent, and no stacks.
The stacks in that space are still unstaged, and liftoff batch list will show them that way.
To migrate them, name them.
Note that unstage is not the mirror image of this: it cascades downward, so unstaging a space does take the stacks in it (below).
Re-staging a migrated unit needs a person's explicit agreement.
Staging normally moves an unstaged unit into the batch and is ungated.
But if the cascade would pull back a unit you've already migrated, staging drops it out of migrated — and the next generate then rewrites its file, losing any hand-edits you made to it.
So that case refuses first, and the refusal names every migrated unit the cascade touches (not just the one you typed) with why it came along, so what you agree to is the real blast radius.
A person agrees by re-running with --restage-migrated; an agent cannot use the flag, and instead asks the user to run liftoff approve stage:migrated in a terminal of their own.
Staging fresh units is unaffected.
liftoff batch unstage — change your mind»
1 | |
Reverses a staging choice. It cascades down (unstaging a space takes the stacks in it) and is refcount-aware: a shared parent space stays staged as long as any staged child still needs it, and is released only when nothing does.
There's no skip command — to leave something out of the batch, just don't stage it (or unstage it if you had).
Once the batch looks right, move on to audit.