Availability: Migrate isn't offered for purchase or activation at launch. It's coming later. This page explains how Migrate works so you can plan client moves ahead of time. There's no Migrate pricing yet. To hear when it's available, submit a request.
Migrate cannot automatically reverse a completed or partially completed migration job. There is no working rollback: the console's Rollback control is present but disabled, and the API refuses a rollback request outright. If you need to undo a migration, the reversal is a manual process at the destination. This article states what Migrate does and does not do, and which recovery paths actually exist.
Rollback Is Not Implemented
POST /jobs/:id/commands with {command: 'rollback_job'} returns 501 with code: 'not_implemented':
Rollback is not implemented for Migrate jobs. No migrated data can be automatically reversed today — use a manual process if you need to undo this migration.
The console's Rollback button is disabled and carries the same explanation in its tooltip. Nothing is queued for the agent, so there is no command to pick up, no rollback progress to watch, and no 24-hour expiry to beat.
How to Undo a Migration Today
- Identify what the run wrote at the destination. The job's Progress view lists what was transferred, and the destination platform's own inventory is the authoritative record.
- Remove it at the destination, using that platform's own tooling (OneDrive, SharePoint, Exchange Online, SMB share, and so on). Migrate does not perform this step for you.
- If the job did not finish and you want to complete it rather than undo it, use Re-run. A Re-run resumes from the job's saved checkpoint: items already transferred are skipped and items that failed are retried.
What a Manual Reversal Cannot Recover
These limits apply to any reversal, manual or otherwise:
Deleted source data. If delete_after_upload was enabled and source files were deleted after transfer, they cannot be restored. The source data is gone.
Overwritten destination files. If files at the destination existed before the migration and were overwritten, removing the migrated copy does not bring the previous version back. The original content is lost.
Expired staging data. R2 staging is cleaned up 7 days after a job reaches a terminal state (completed, failed, or cancelled). After cleanup, there is no staging copy to reference.
Mailbox migrations with destructive actions. If mail was deleted from the source during a mailbox migration, those messages cannot be recovered through Migrate.
Before You Run a Migration
Because Migrate cannot undo a run for you, plan the recovery before you start:
- Leave
delete_after_uploadoff unless you are certain the migration was successful. - Keep a record of the destination state before migration (for example, a backup or snapshot at the destination platform level).
- There is no scan to preview the move (see the correction note at the top of this page), so scope the job with its source filter and test a small set instead.
- Check destination status before kicking off a destructive run.
Staging Cleanup and the 7-Day Window
After a job reaches a terminal state, a cleanup timestamp is set 7 days in the future. The daily cleanup cron (running at 03:00 UTC) purges R2 staging prefixes once that window expires. Anything that is still only in staging is deleted then — if you need to inspect it or keep a copy, do so within that 7-day window.
You can check staging contents via Staging > Stats and trigger early cleanup manually via Staging > Cleanup if needed.
FAQ
Is rollback automatic if a job fails? No — and there is no manual rollback either. A failed job stops; it does not reverse what it transferred. Use Re-run to continue it from the job's saved checkpoint.
Can I roll back a sync job?
No. No job type can be rolled back automatically. A sync job is a single enumerate-and-transfer run — the same as migrate_files, with no scheduled second pass — so what it transferred is what a manual reversal has to remove.
Does pausing a job give me a way to undo it?
No. Pause stops the transfer and leaves the job Partial, and there is no Resume control — the API refuses resume with 501 not_implemented as well. Re-run is the recovery path: it continues from the persisted checkpoint. See Running a Migration.