Rollback preview · seven-day reversible window
Every completed migration keeps a rollback journal for seven days. Before you revert, a preview shows exactly what will be undone — file counts, permission removals, folder deletions — so you never guess what undo actually does.
How the rollback journal works
During every migration run, MigrationFox writes a journal entry for each destination-side mutation:
- Files created — destination path, source hash, size, timestamp.
- Folders auto-provisioned — destination path (so we know to delete only the ones we created, not pre-existing).
- Permissions granted — principal, role, scope. Revocable per-entry.
- Metadata overwritten — previous value (if any), new value.
The journal is bounded to seven days. After day seven the journal entries are purged and the run becomes non-revertible. The window is long enough to catch a landing problem after stakeholders have had a chance to look, and short enough to keep journal storage bounded.
Reverting a run
- Open the project in MigrationFox.
- Navigate to History · Runs. Reversible runs show a
ROLLBACK AVAILABLEbadge with the remaining time window. - Click Preview rollback. The preview loads in seconds (it reads the journal, does not touch the destination).
- Review the counts and the per-action summary. Check that what will be removed is what you expect.
- Click Revert run. The rollback job queues. A progress view shows real-time undo progress.
- When the rollback completes, the run is marked
REVERTED. The journal is retained for audit but cannot be re-applied.
Partial rollback
You can also roll back a subset of a run. From the preview, click Narrow scope and pick:
- A specific library or folder (e.g., undo the
/vendor-contractspath only). - Specific permission grants (e.g., remove the external share grants, keep the internal ones).
- A specific principal (e.g., revoke every permission granted to
ex-employee@).
Partial rollbacks write their own journal entries and can themselves be rolled back within the remaining seven-day window.
MOVE MIGRATIONS
If the run was a MOVE (source files deleted after copy), a rollback puts files back in the destination but cannot restore the source — the source was deleted by the tenant’s own deletion. In this case rollback shows a prominent warning and you choose whether to proceed with the partial-restore. For fully-reversible rollbacks, use COPY migrations until the rollback window closes.
What rollback does NOT do
- Restore destination content that existed before the migration. If a migration over-wrote a pre-existing file, the pre-existing content is not in the journal. Enable Conflict resolution: version-keep at migration time if you need the original preserved.
- Undo user edits on the destination after the migration. If a user opened and saved a migrated file, the rollback removes the file including the user’s edit.
- Remove items outside the migration scope. Only mutations recorded in the journal are reverted. Items created by users on the destination after the migration are untouched.
Audit log
Every rollback operation (preview viewed, revert initiated, revert completed, revert failed) is written to the project audit log with timestamp and actor. Audit entries are CSV-exportable and retained for the life of the project.
Revert via API
POST /api/runs/run_4e7a/rollback
Authorization: Bearer <personal-access-token>
{
"confirm": true,
"scope": "full" // or "narrow" with an additional selector
}Related
- Migration Rehearsal dry-run — prevent most issues before the real run
- Rehearsal verdict reference — the 10 categories of cutover issue
- Client Live View — branded share page for stakeholders