Workstream 01
Classify the symptom and affected scope
Ask first whether data failed to copy, users cannot authenticate, new mail is routing incorrectly, or users can sign in but cannot find expected files and calendar items. Record how many people are affected, the first error time and the last known working state.
An Outlook profile issue after cutover is usually a different operational problem from an Exchange migration job that never staged. Treating both as “email migration failed” wastes diagnostic time.
| Symptom | Investigate first | Avoid |
|---|---|---|
| Batch cannot start | Permissions, licence eligibility, target object, service quota | Creating duplicate target mailboxes |
| Some files missing | Detailed item logs, unsupported files, path/size rules | Assuming task completed means all files copied |
| Mail routing loops | Current MX/connectors, coexistence rules, aliases | Repeated DNS changes without a snapshot |
| Users can't open shared files | Identity/group mapping, guest access, inheritance | Granting everyone broad access to make the test pass |
| Outlook keeps asking for credentials | Client profile, auth policy, MFA and device state | Re-running all source mail data |
Workstream 02
Preserve evidence before changing the environment
Export available batch and scan reports, capture current DNS and transport rules and record what has already changed. Where retention or regulated data is involved, involve the responsible owner before cleanup or deletion.
Use a representative failed item to reproduce the problem. If the job copied most accounts successfully, isolate the exceptional accounts instead of treating the whole migration as broken.
Workstream 03
Agree a recovery decision and an acceptance test
Some errors can be retried after correcting an account attribute; some require an alternate migration path or explicit manual work. Others, especially after certain cross-tenant moves or identity changes, cannot be reversed with one click.
A useful incident plan states who decides to continue, pause or switch method; how staff will be told; and which concrete test closes the issue. Business-critical loss of access should be handled under the customer's actual incident response arrangements.
What to capture before the decision
- Exact failed workload, batch and timestamp
- Error export and current configuration snapshot
- Affected people and business severity
- Whether a retry creates duplicates or loses state
- Named owner for remediation and user acceptance
Workstream 04
Build an incident timeline before attempting a rescue
When a migration stalls, preserve the time of the failed operation, job identifier, source/target tenant, affected batch and the exact reported error before changing anything. Check whether the symptom is copy throughput, licence eligibility, target recipient mismatch, source throttling, authentication, calendar fidelity or post-cutover routing. These diagnoses require different responses; repeating every migration batch can create confusing duplicate evidence without repairing the cause.
For a live cutover, separate business-impacting outages from background sync delay. An incomplete archive can sometimes be scheduled for remediation while a broken MX record or lost production mailbox requires immediate coordinated action. Do not delete target objects, purge mailboxes or clear identity attributes on the assumption that a retry will fix the problem.
| Observed issue | First evidence to inspect | Safer next action |
|---|---|---|
| Mail not arriving after cutover | Public MX and message trace from both systems | Check routing and authentication with authorised admin |
| Cross-tenant batch fails | Licence/hold/MailUser details and migration error | Stop and validate documented prerequisites |
| SharePoint files missing | Scanner and task exception reports | Map unsupported objects and source access |
| Teams or Outlook sign-in broken | Identity policy and client sign-in events | Coordinate identity owner and user communications |
Workstream 05
Recovery acceptance is different from declaring the job restarted
Agree the service restoration target that actually matters: business mail delivery, user authentication, file access or acceptable legacy coexistence. Record the owner of each recovery decision and capture before-and-after proof. A technical job may return to running status while staff remain unable to use essential applications.
After service stabilises, produce a short root-cause and residual-risk log. Identify which data still needs reconciliation, what is deliberately preserved for compliance, which privileged actions were taken and how users will be informed about follow-up. Recovery promises should distinguish feasible restoration from irreversible native migration steps.
What to capture before the decision
- Preserve job logs, timestamps, recipient and DNS evidence
- Avoid destructive retries until root cause is understood
- Define go/no-go authority and communications
- Verify external mail, representative identities and critical files
- Document residual data issues and the accepted follow-up owner
A recovery review should produce one accurate diagnosis and a safe next action—not merely another migration attempt.
Source documents and limitations
These references establish current vendor behaviour; they do not verify an individual customer's configuration or imply Microsoft affiliation. Technical claims should be rechecked before execution.