By Dan Stark
Before you approve Microsoft 365 migration services, ask three questions: what will move, what needs separate work, and what employees must be able to do afterward. A mailbox transfer report can’t answer all three.
CTMS supports scoped Microsoft 365 migrations involving on-premises Exchange, Google Workspace, moves between Microsoft 365 tenants, legacy file servers, and SharePoint or OneDrive data. Planning may include dependency review, permissions mapping, testing, cutover coordination, and validation. The source environment and agreed scope determine the work and its impact on users.
Use this Microsoft 365 migration checklist to separate three decisions:
- Approve the work: Agree on what’s included, who performs it, and how completion will be judged.
- Authorize cutover: Confirm readiness before employees start using the destination for the affected work.
- Accept the result: Review the evidence, record unresolved issues, and assign ongoing ownership.
These are planning recommendations, not a single technical sequence for every migration.
Match the plan to the migration path
Start with the source, destination, and selected method for each workload, such as email or shared files. A Microsoft 365 tenant to tenant migration (a move between separate Microsoft 365 environments) has different requirements from a move out of Google Workspace.
| Migration path | Question the scope must answer |
|---|---|
| On-premises Exchange to Microsoft 365 | Which mailboxes, archives, delegated access, and mail-dependent applications are included? |
| Google Workspace to Microsoft 365 | Does the project cover email only, or also Drive content, shared calendars, and connected applications? |
| Microsoft 365 tenant to tenant | What moves, what must be recreated, and what stays in the source environment? |
| File servers, SharePoint, or OneDrive | Where will the content live, who should have access, and which file-dependent processes need attention? |
The method changes the answer. Microsoft’s email migration guidance separates methods that copy contacts, calendar items, and tasks along with mail from IMAP migration, which copies email only. With IMAP, those other items need separate treatment.
Microsoft’s documented Google Workspace migration method covers mail, rules, calendars, and contacts. It doesn’t migrate shared calendars, room bookings, or automatic reply settings. Migrated rules arrive turned off, and Microsoft advises reviewing them before enabling them.
Ask the provider to explain the selected method’s limits in terms of the work your employees do.
Define your Microsoft 365 migration services scope
For each item, record its intended treatment: move, recreate or reconfigure, retain, retire with authorization, or exclude. A list marked “included” leaves too much unresolved.
Cover user and shared mailboxes, archives, files, permissions, identities, groups, sharing arrangements, and connected applications as applicable. Microsoft’s native cross-tenant SharePoint guidance, for example, ties continued access to identity mapping and identifies separate work to recreate, republish, modify, or reconnect apps and workflows. Scope that work separately from moving site content.
Use a Migration Scope and Cutover Record
Copy this record for each workload or group that shares the same method, dependencies, timing, and acceptance conditions. Keep connected users and systems together where the technical method requires it.
| Field | What to record |
|---|---|
| Source, destination, and method | Platforms, environments, selected migration method, and responsible technical lead. |
| Included work | Users, mailboxes, files, access, applications, and locations covered, with the treatment of each item. |
| Exclusions and retained records | What stays, what’s excluded, how required records remain accessible, and who can authorize retirement. |
| Dependencies | Required accounts, permissions, domains, DNS access, licenses, vendors, and connected systems, with an owner for each unresolved item. |
| Assigned authority | Who approves business impact, performs technical work, coordinates the project, and accepts the result. One person may hold several roles. |
| Readiness evidence | Required pilot results, configuration checks, access tests, and workflow checks, with results, dates, and where the evidence is kept. |
| Cutover conditions | Approved window, affected users, permitted interruption, user instructions, support coverage, and conditions that must hold before proceeding. |
| Contingency | Who can stop or postpone, the latest safe decision point, and the verified options after changes begin. Identify unverified recovery assumptions. |
| Acceptance and exceptions | Accepted scope, each outstanding issue, its business effect, any restriction on use, decision owner, corrective action, and deadline. |
| Operating handoff | Support contact, owners of unresolved work, administration, documentation, temporary-access cleanup, and ongoing security and recovery responsibilities. |
This record is a planning aid, not a Microsoft requirement or an automatic CTMS deliverable. The engagement defines the work and service commitments.
Resolve dependencies before committing to cutover
Have the technical lead confirm the prerequisites for the chosen method. Microsoft’s native cross-tenant mailbox migration, for example, requires destination identities prepared with specific attributes and a migration license for each user. An account that appears in the destination doesn’t establish readiness.
Make the remaining assignments explicit:
- Domains and DNS: Who controls the domain, can authorize its release or configuration, and will make and verify the DNS changes?
- Accounts and access: Who prepares identities, verifies sign-in, and authorizes access in each environment?
- Licensing and applications: Who confirms the required entitlements and handles applications that depend on the old environment?
- Records: Who approves how required records are retained and accessed? The native cross-tenant mailbox method blocks mailboxes on hold. Resolve the approved treatment of held and retained records before scheduling that work.
Consider two businesses consolidating their environments. In this hypothetical project, mailbox preparation is progressing, but the source administrator hasn’t confirmed the domain-release work. The coordinator must obtain that commitment or bring a revised plan to the authorized decision-maker. A target date alone doesn’t resolve the dependency.
Coordination doesn’t grant business approval or technical access, and an internal approval can’t change another provider’s contract or commitment.
Authorize or postpone the cutover
Cutover is the point or window when the affected work changes production use. Before proceeding, review the agreed readiness evidence, outstanding issues, user instructions, and support availability. Confirm any day-one sign-in or Outlook changes employees will need, and plan the support and network capacity those steps require.
Use representative accounts and workflows in the pilot. If a shared mailbox, branch office, or critical application sat outside that test, keep it visible as untested. A successful pilot supports the tested conditions, not every part of the environment.
Name who can authorize proceeding, postponing, or accepting a defined exception. Record the latest safe decision point and who communicates a change to employees and providers. Changes to scope or timing may also require revised provider agreements.
Postponing is different from moving back
Don’t accept “we can roll back” without a method-specific explanation. Because the native cross-tenant mailbox move deletes the source mailbox, returning a mailbox means another prepared move in the opposite direction, not reopening the old one.
Ask the technical lead: When can we still stop? What options remain after changes begin? How will data created or changed after cutover be handled? What access, licensing, time, and approvals would the response require? Record any unverified assumptions before authorizing cutover.
Accept the work using more than transfer status
Agree on the evidence before execution so completion doesn’t become an argument afterward. Review four things:
- Transfer results: Included content, errors, skipped items, exclusions, and their disposition.
- Technical checks: The agreed routing, configuration, and connectivity tests.
- Access checks: Required actions for the tested users and agreed restrictions on access.
- Business workflows: A designated employee completes the agreed task using the relevant account, application, and data.
Example: email works, but the finance task doesn’t
In a hypothetical native cross-tenant migration, the finance team’s personal and shared mailboxes have moved. Personal email sends and receives, but an employee can’t send on behalf of the shared mailbox.
Microsoft documents that Send on Behalf permissions don’t move with the mailbox in this method and must be set again on the target side. Treat the failed action as its own issue: assign the fix, retest it, and record the result before accepting that workflow as complete.
If the business authorizes a temporary workaround, record its limits, owner, and deadline. Conditional acceptance should name the unfinished work. It shouldn’t erase it or imply that untested users and applications have passed.
Assign ownership after the migration
Name the post-cutover support contact and confirm whether Microsoft 365 user support is included, for which hours, and for how long. Give each remaining issue an owner and an agreed path to resolution.
Assign ongoing Microsoft 365 security management, administration, and documentation. If the project affects backup and recovery, confirm coverage, recovery responsibilities, and required restore tests separately. A completed migration doesn’t include those services by default.
Review temporary migration access and remove it when its authorized purpose ends. Retire source systems or subscriptions only after their remaining dependencies and records requirements are resolved and the responsible person authorizes it.
Discuss Microsoft 365 migration services with CTMS
CTMS supports organizations nationwide through remote Microsoft 365 work. The engagement determines which migration activities CTMS performs and what stays with internal IT or other providers. Confirm any on-site needs by location and scope.
Discuss your Microsoft 365 migration with CTMS. Share your source platform, intended destination, approximate user count, target timing, and main concern. A brief overview is enough to start. Leave credentials and sensitive records out of the public form.
