Microsoft 365 Tenant Migrations Need an MSP Plan Beyond Email

Consider a Microsoft 365 migration where all the email arrives, but the accounting team cannot send invoices from its shared mailbox. The files are in the destination, but the office manager’s saved links do not open. Staff can sign in through a browser, while their usual desktop applications still need attention.

The migration report might look good. The client still has work it cannot do, and the MSP has a support queue that should have been part of the project plan.

In my December 2025 weekly notes, I wrote about moving an email security client from GoDaddy’s Microsoft 365 setup into a new tenant so we could manage their email security properly. That was a narrower engagement than taking over all of a company’s IT, but it is a useful example of why these projects happen outside large mergers and acquisitions. Sometimes the immediate problem is getting a client’s environment into a manageable state.

CM Alliance’s tenant-to-tenant migration guide covers the assessment, preparation, migration, and validation sequence. I want to look at that work from the provider’s side: what needs to be discovered, what belongs in the quote, and what evidence should exist before we tell a client the move is finished.

Establish why the tenant needs to change

A tenant is the organization’s Microsoft 365 environment, with its own directory, configuration, and access relationships. Moving to another one deserves a business reason. An acquisition, a company split, or a requirement to consolidate environments may provide it. A change of IT provider should first prompt an assessment of whether the existing tenant can meet the client’s needs.

I would want that decision documented before choosing a migration product. What cannot be achieved in the current environment? What will improve after the move? Which business systems depend on the identities we are replacing? A new tenant can be the right answer, but the client needs to understand the work that comes with it.

Then establish who can actually authorize and perform the changes. Confirm administrative access in both tenants, control of DNS, the licensing contacts, and cooperation from any outgoing provider. A client’s approval does not make an inaccessible registrar account usable on Friday evening.

Give the outgoing provider specific deliverables and dates: required configuration information, approved access, responsibility for domain release, and an escalation contact during cutover. Record the source and destination tenant IDs in the change record. Similar company names and several open browser sessions are poor substitutes for confirming which environment a technician is changing.

Scope the work the client will notice

Mailbox counts and storage totals help size a job. They do not describe how the business uses Microsoft 365.

Discovery should connect the inventory to the people who depend on it. Identify shared and resource mailboxes, archives, delegates, groups, aliases, forwarding, mail-flow rules, and applications that send email. For files and collaboration, identify site owners, external sharing, important links, Teams usage, and automation. Include device management and applications using Microsoft sign-in, even if their remediation becomes a separate workstream.

Here is an illustrative discovery record for a small business. These are examples of questions to resolve, not findings from a particular client:

That last column gives the project a useful acceptance test. The accounting lead should be able to send an invoice through the normal workflow, rather than merely confirm that a technician can open the mailbox.

The quote should separate data migration, configuration work, endpoint work, and user support. State exclusions in ordinary language. If historical Teams content, a particular application, or rebuilding a workflow is outside scope, the client needs to know while there is still time to change the plan.

Budget for overlapping services where needed, the migration licenses, the pilot, and support after cutover. Leaving those costs out of the proposal makes them surprises; it does not remove the work.

Select the migration method before preparing the destination

Microsoft now documents both individual workload moves and a Migration Orchestrator. The orchestrator supports Exchange mailboxes, OneDrive, Teams chats, and Teams meetings, with dependencies between workloads. It moves content; preparing the destination identities remains the customer’s responsibility. Teams and their channels, along with SharePoint sites, are outside that user-data migration scope.

That distinction belongs in the design. “We are migrating Teams” is too vague to price or validate. List the particular content and behavior the client expects, then check the selected tool against that list.

There are several native requirements worth settling early:

• Mailbox moves need the right target objects. Microsoft’s cross-tenant mailbox documentation requires a target MailUser with matching ExchangeGUID and, where applicable, ArchiveGUID values. LegacyExchangeDN and X500 addresses matter for replies to older messages. Mailboxes on hold are blocked from moving.
• License assignment has an order. For the orchestrator, Microsoft’s user-preparation instructions require identity mapping before assigning licenses that would provision target mailboxes or OneDrive sites. The cross-tenant migration add-on is an additional requirement; ordinary service licensing alone is insufficient.
• OneDrive does not follow a generic repeat-copy process. Microsoft’s native OneDrive move does not support incremental or delta passes. An existing destination OneDrive site blocks the move.
• SharePoint needs its own eligibility check. Microsoft’s native cross-tenant SharePoint feature currently limits its feature and licenses to Enterprise Agreement customers. Moving a Teams-connected site through that feature does not migrate the Teams channels and structure. It also documents work to recreate and reconnect Power Apps and Power Automate dependencies.

These requirements were checked against Microsoft’s documentation on September 28, 2026. Recheck them when designing the actual job, particularly licensing availability and workload coverage.

Target preparation depends on the tool

Do not turn “create the users and assign licenses” into a universal first step. A product that copies into existing mailboxes and Microsoft’s native mailbox move can require different destination states. Follow the selected method’s preparation sequence before allowing users into the new environment.

A third-party product may be a better fit for the client’s scope, licensing channel, or support requirements. Evaluate how it handles permissions, archives, retries, exceptions, and content it cannot transfer. Ask what administrative consent it needs, where any intermediate data is held, and what happens when a job fails partway through. A supported-feature list is useful evidence, but the pilot still has to demonstrate the client’s required workflow.

Treat the pilot as part of the migration

An empty test mailbox can prove connectivity. It tells you little about a user with an archive, delegated access, a phone, shared files, and several years of calendar entries.

Choose a small group that represents the complications found during discovery. Keep people who depend heavily on one another together where the migration method and coexistence design require it. Include the support team in the pilot so it can turn the observed experience into instructions for everyone else.

Have those users perform real tasks: reply to an older message, send from a shared mailbox, open a shared document, use the relevant Teams features, and sign into a business application. Check expected access and inappropriate access. Being able to open a file does not prove the permissions are correct if everyone else can open it too.

Use the result to revise batch sizes, staffing, and the outage estimate. Data volume is one input; service throttling, item counts, exceptions, and client reconfiguration can affect the schedule. A transfer estimate derived from the office’s internet speed alone is not enough.

For a native move, remember that completing the pilot can change where those users’ data lives. Plan their access and communication with the rest of the business afterward. Calling it a test does not make the completed move disposable.

Write the domain cutover as a sequence with stop points

Moving the client’s email domain requires coordination beyond changing an MX record. Microsoft documents that a domain is associated with only one tenant. If only some users are moving, establish how the remaining users will receive mail and which addresses they will retain before committing to the domain move.

Microsoft’s domain-removal guidance identifies references that must be cleared, including users, aliases, shared and resource mailboxes, contacts, and groups. Administrator sign-ins using that domain need attention too. Microsoft says removal can take several hours, up to a day, when many references exist. Lowering DNS TTLs cannot shorten that tenant-side operation.

The runbook should name who performs each action, what confirms success, and when the team stops to escalate. For example, the domain must be released successfully before the next person assumes it can be attached to the destination. Preserve working administrative access on an unaffected domain and test it before the change.

Include mail routing through any security gateway, destination connectors, and the applicable MX, Autodiscover, SPF, DKIM, and DMARC configuration. Confirm values against the destination and the actual sending services. Copying the old DNS records without checking their dependencies can preserve the wrong routing or authentication configuration.

Give staff instructions that match the pilot: when to stop making changes, where to sign in afterward, what authentication steps to expect, and how to reach support if email is unavailable. Use a known communication channel established before cutover. A migration is a particularly bad time to train people to trust an unexpected message asking them to enter credentials.

Before authorizing cutover

Before the agreed cutover, the technical lead and client contact should confirm:

• Both tenants and DNS are accessible, with a reachable escalation contact for each dependency.
• The identity mapping and migration reports have been reviewed; unresolved exceptions have an owner and an agreed treatment.
• Pilot users have completed the business tasks selected during discovery.
• Destination security settings, authentication, monitoring, and the intended backup coverage are ready.
• Staff instructions and an alternative support channel have been distributed.
• The team knows which step it can still pause safely and what recovery requires after that point.

If a condition fails, record the decision to delay or the specific consequence the client is accepting. Do not silently turn an unmet requirement into something to investigate on Monday.

Make recovery specific to the method

“We can switch DNS back” is not a recovery plan for data that has already moved and changed.

For Microsoft’s native mailbox migration, a successful move deletes the source mailbox. Keeping the source tenant subscribed does not preserve that mailbox as a fallback. A copy-based product may behave differently, but even then, messages and edits made in the destination need to be accounted for before directing users back.

Before cutover, document the recoverable copies available, what they contain, where they can be restored, and how long that would take. Verify a representative restore using the intended recovery process. Separate the decision to pause an unfinished batch from recovering a completed move; those actions have different consequences.

Resolve holds and retention requirements with the people responsible for them before scheduling affected data. Removing a hold merely to clear a migration error can undermine the reason the organization preserved the information in the first place.

Protect the access created for the migration as carefully as normal production access. Use named administrative identities, protect application credentials, scope permissions to the work, and document their removal. Keep monitoring active in both tenants. An unfamiliar forwarding rule or unexpected privilege grant deserves investigation even while legitimate migration activity is generating noise.

Close the project with the client doing its work

After cutover, reconcile migration reports with the agreed scope. Record failed and skipped items with enough detail to resolve them. Compare counts where meaningful, inspect representative content, and have the business owners repeat their acceptance tasks using ordinary accounts. An administrator’s access can conceal a permission problem that an employee will hit immediately.

Give desktop and mobile access their own checks. Confirm the intended device enrollment, application sign-in, file synchronization, and authentication behavior. Keep a named support owner through the agreed stabilization period, with particular attention to staff who were absent during the move.

Source retirement should be a separate decision. For example, Microsoft’s native OneDrive migration leaves redirects that remain only while the source tenant exists. Check whether users still depend on those links before deprovisioning it. Resolve retained content, outstanding applications, recovery requirements, and subscription timing as part of that review.

The final handoff should leave the next technician with an accurate map: tenant IDs, domain and DNS ownership, identity mappings, licensing, mail routing, backup coverage, and known exceptions with owners and dates. Remove migration-specific access and confirm the MSP’s ongoing administrative relationship works as intended.

For the accounting team in the opening example, closure means someone has sent an invoice from the correct mailbox, confirmed it reached an external recipient, and verified that the right staff can find the correspondence afterward. That is evidence the business can use. Put that task in the scope early enough that the project has time, money, and someone responsible for completing it.