Recovering a failed Google Workspace migration

The instinct on discovering a broken migration is to restart it. Resist it. Most migration tools keep state, and a restart without knowing whether that state survived is how a mailbox ends up with two copies of four years of mail, which is a far more expensive problem than an incomplete copy.

Stopping costs nothing that cannot be resumed. Staff are already affected, and one further hour of a known-bad position is cheaper than an unknown one.

Recovery is an accounting exercise before it is a technical one. Both estates are counted: mailboxes and message counts per mailbox, files and folders per drive, ownership and sharing state, group membership, calendar resources, and where mail is currently being delivered.

That count produces the only document that matters, which is a per-object statement of complete, partial, or not started. Everything after this is a decision rather than a guess, and it is the document we hand over whether or not the recovery work continues with us.

Mail migration is a mature, well-understood copy. Permission migration is not, because permissions are a graph rather than a list: a file shared with a group whose membership was migrated separately, inside a folder whose owner left, referenced by a link somebody saved in a document.

This is why a migration can report success while staff report that nothing works. The messages arrived; the access model did not. Rebuilding it is methodical work driven by the inventory, and the sequence is ownership first, then group membership, then direct shares, then link-based access.

Finishing forward is usually right where mail has already been cut over and most content has landed: complete the remaining copy, repair permissions, reconcile, then close. Rolling back is right where the cutover has not happened, or where the target was built on a structure that will cause the same failure again.

Either way the decision is written down with its reasons before work resumes, because the failure being recovered from was frequently a decision nobody had recorded. We would rather hand you an argued recommendation you can reject than resume work you did not choose.

Record running job IDs, logs, source access, routing and known destination writes before changing anything. A restart may be safe with a supported resumable job, while a fresh job may duplicate items. Pause harmful writes where justified; do not blindly stop a job that is sustaining service or discard its state.

Recovery acceptance should account for complete, partial and missing objects, not only totals. Compare message IDs or tool identifiers where available, test repaired access, and identify destination-only mail or file edits before considering rollback. Data that survives neither estate nor a retained copy cannot be promised recoverable.

Availability, access and investigation scope determine triage timing. Request a paid assessment with deliverables and decision gates; a universal 48-hour recovery commitment is not established by this page.