A Microsoft 365 tenant migration can affect email, files, collaboration, sign-ins, and day-to-day work. How should a business plan a Microsoft 365 tenant migration? Start by defining what is changing, who owns each decision, and how employees will keep working during the move. Then inventory the current environment, test the highest-risk workloads, and set a cutover plan with clear checks and rollback decisions.
Discuss your Microsoft 365 migration needs
What does a tenant migration include?
A tenant is the organization’s Microsoft 365 environment. A tenant-to-tenant migration moves some or all of an organization’s accounts, data, and services from one environment to another. The exact work depends on what the business uses and what must remain available throughout the transition.
Do not treat the project as an email-copy exercise. A workable plan considers user identities and sign-in, mailboxes and calendars, shared mailboxes, groups, SharePoint sites, OneDrive files, Teams content and configuration, devices, applications, security policies, licenses, and domain names. Some items may be moved, recreated, reconnected, or left behind. The project team should explicitly decide which applies to each item rather than assume everything transfers in the same way.
For a plain-language overview of the platform’s services, review what Microsoft 365 includes. For migration planning, IGTech365 also describes its migration services. These are useful starting points, but the source and destination tenants still need an environment-specific assessment.
How should you define the scope and success criteria?
Write down why the migration is happening and what a successful result looks like for users and the business. The reason might be a company acquisition, a tenant consolidation, a business separation, or a change in how Microsoft 365 is administered. That context affects which data, domains, policies, and user experiences matter most.
Agree on measurable, observable outcomes without promising that every workload will behave identically on day one. Examples include:
- Employees can sign in with the intended account and reach the services they need.
- Priority mailboxes, calendars, shared mailboxes, and distribution groups are available and tested.
- Named SharePoint sites and OneDrive content are accessible to the right people.
- Critical Teams, business applications, and workflows have been checked with their owners.
- Required security controls, administrative access, and support routes are in place.
- Users know when the change happens and where to get help.
Set boundaries, too. Identify data that is out of scope, temporary exceptions, retention or compliance requirements, and anything that must remain accessible in the original tenant. If the organization has legal, contractual, or regulatory duties, ask the appropriate internal owner to confirm the requirements before deciding what to move or retire.
Who needs to be involved in planning?
Name a business sponsor, a technical owner, and a decision-maker for each major workload. Include representatives from operations, finance, human resources, security, and any department with specialized tools or sensitive information. The project lead coordinates dependencies and decisions; workload owners confirm that the migrated service supports real work.
Microsoft 365 tenant-level administration involves deployment and management responsibilities. Make sure the people assigned to the project have the needed access and experience, or arrange qualified support. The MS-102 Microsoft 365 Administrator course description, for example, identifies deployment, management, and tenant-level implementation as administrator work.
Keep an owner-and-decision log. Record who can approve scope changes, who will validate each workload, who communicates with staff, and who can authorize a pause or rollback. Define how the migration team will handle an urgent issue outside normal working hours. This prevents a technical question from stalling because nobody knows who can make the business decision.
What should you inventory before choosing a migration approach?
Build a current-state inventory from the source tenant and verify it with users and service owners. Do not rely on memory or a single spreadsheet that only lists accounts. The purpose is to find dependencies, exceptions, and high-impact users before a change window is booked.
- People and identities: active users, guests, administrators, shared accounts, aliases, groups, and accounts that should be disabled or retained.
- Email and scheduling: mailbox sizes and types, shared mailboxes, distribution lists, resource calendars, delegates, forwarding, and important calendar workflows.
- Files and collaboration: SharePoint sites, OneDrive accounts, Teams, permissions, external sharing, ownership, and links embedded in documents or procedures.
- Devices and access: managed computers and phones, sign-in methods, device policies, multifactor authentication, conditional access, and remote access requirements.
- Applications and integrations: line-of-business apps, scanners, email-enabled systems, automation, service accounts, and anything using Microsoft 365 sign-in or data.
- Governance and security: retention, sensitivity or sharing rules, audit needs, backup arrangements, administrative roles, and incident-response contacts.
- Domains and licensing: verified domains, DNS ownership and access, current subscriptions, license assignment, and renewal dates.
Mark each inventory item as move, recreate, reconnect, retain, or retire. Add an owner, business priority, estimated size or complexity, dependencies, and a validation method. Confirm the list with the people who use the system; technical inventories may not reveal a department’s informal but business-critical process.
How do you choose the migration sequence?
There is no universal sequence that fits every tenant. Choose an order based on dependencies, user impact, data volume, and the time available for testing. A phased approach can make learning and support easier, while a single cutover may be appropriate for some environments. Either way, plan a pilot or other representative test before moving the full population.
| Workstream | Planning action | What to validate |
|---|---|---|
| Accounts and access | Map users, groups, administrators, sign-in, and license needs. | Test sign-in, permissions, and access to required services. |
| Email and calendars | List mailboxes, shared resources, delegates, and mail-flow dependencies. | Send and receive test messages; check calendar access and key delegates. |
| Files and collaboration | Identify priority SharePoint sites, OneDrive content, Teams, and owners. | Check representative files, sharing, permissions, and team workflows. |
| Devices and applications | Identify endpoints, integrations, service accounts, and app owners. | Confirm users can connect and critical apps work with the intended identity. |
| Cutover and support | Set change windows, communications, escalation, and go/no-go owners. | Use agreed acceptance checks and document the response to a failed check. |
For a business that relies heavily on SharePoint, map sites and owners early; see the overview of SharePoint solutions. If desktop and mobile endpoints rely on Microsoft Intune, include device enrollment, policy, and user access checks in the plan. The plain-English guide to Microsoft Intune can help nontechnical stakeholders understand why device management is a separate workstream.
How should you plan testing and cutover?
Testing should be designed around real work, not only whether a migration task reports completion. Select pilot users who represent different roles, devices, locations, and access needs. Include at least one person who uses each important shared mailbox, site, app, or workflow. Tell pilot participants what to check and where to report a problem.
Write test cases in plain language. For example: sign in from a managed laptop, open a priority document, confirm that a colleague has the correct access, send a message to an external contact if permitted, open a shared calendar, and complete a representative business process. Record expected results, actual results, the tester, and any follow-up. Repeat the test after a fix where the issue could affect other users.
Before cutover, confirm the change window, dependency order, data handling plan, communications, support coverage, and decision authority. Check that the team can access the required administrative accounts and that DNS or domain changes have a named owner. Document what must be true to proceed, what conditions mean “pause,” and what action the team will take if a critical service is unavailable.
Be careful with the word rollback. Some changes may be reversible, while data changes or user activity after cutover can make a simple return to the previous state impractical. Define the rollback or recovery decision for each major step with the technical team, including what happens to new messages or files created during the transition. Preserve appropriate backups or exports according to the organization’s requirements, and do not retire the source environment until owners have accepted the outcome and retention obligations are addressed.
What should the employee communication plan say?
Tell employees what is changing, when it will happen, what they need to do, and how to get help. Keep notices short and specific. Avoid vague instructions such as “your account may change.” Explain whether a person will use a different sign-in, need to set up an app again, or see a temporary interruption. Only include instructions the project team has tested.
- Send an initial notice with the purpose, broad schedule, and expected user impact.
- Provide role-specific steps for sign-in, devices, Outlook, Teams, and file access as needed.
- Send a reminder before the change and a completion notice with support instructions.
- Give managers and help desk staff a short troubleshooting guide and escalation path.
- Collect issues in one place and identify urgent access or business-continuity problems.
Schedule the change to limit disruption, but do not assume a weekend or after-hours cutover is automatically safer. Consider who can support the work, when business processes run, and when users can validate the result. Make sure the help route is staffed when employees are expected to test access.
How can you keep the project on track?
Use a simple plan with owners, dates, dependencies, risks, decisions, and acceptance checks. Review it regularly with business and technical leads. Keep a risk register focused on concrete issues such as unknown data ownership, untested applications, incomplete DNS access, complex permissions, or a limited support window. Give each risk an owner and a next action.
Check licensing as part of the design rather than waiting until users report missing capabilities. Confirm which users need which services and who will manage assignment during the move. IGTech365’s page on Microsoft 365 licensing and servicing is a useful reference for discussing that work. Do not assume that changing tenants automatically preserves subscriptions, configuration, or the same user experience.
Set checkpoints for discovery, scope approval, pilot completion, cutover readiness, and post-migration acceptance. At each checkpoint, ask whether the evidence supports moving forward. If a key workflow has no owner or a critical test has not passed, resolve it or formally accept the risk before proceeding. This is more reliable than treating a calendar date as proof of readiness.
Talk with IGTech365 about planning your Microsoft 365 move
What should you review after the migration?
Keep the project open long enough to catch issues that only appear in everyday use. Have workload owners verify access and business processes, review help requests for repeated patterns, and address problems by priority. Check mail flow, shared resources, file permissions, sign-in, devices, and integrations against the acceptance criteria agreed before cutover.
Reconcile the final user and license lists. Confirm administrative access is appropriate, temporary privileges are removed when no longer needed, and security and sharing settings match the approved design. Document exceptions, unresolved items, and their owners. Retain or decommission the source tenant only after the responsible people have checked data needs, business sign-off, and applicable retention requirements.
A short lessons-learned review can improve future changes. Record which dependencies were missed, which communication worked, where users needed more help, and what should be updated in the organization’s procedures. The goal is not simply to complete a technical move; it is to leave employees with dependable access and a supportable environment.
Call IGTech365 at (866) 365-7798 to discuss your migration
Frequently asked questions
How early should a business start planning?
Start once the business has a reason and a likely scope, before setting a firm cutover date. The time needed depends on tenant complexity, data, dependencies, testing, and decision speed. An inventory and discovery review reveal whether the proposed schedule is realistic.
Can employees keep using Microsoft 365 during the move?
Often, project teams plan work to reduce disruption, but the user experience and availability depend on the migration approach and the workloads involved. Identify any expected interruption for each service, test the plan, and communicate clear steps and support options in advance.
Does everything in the old tenant move automatically?
No. Treat each workload, setting, identity, and integration as a separate planning item. Some items may need to be moved, recreated, reconnected, or retained. Verify the treatment and acceptance test with the owner of each important service.
What is the most important first step?
Define the business outcome and build a verified inventory of users, data, workloads, dependencies, and owners. That groundwork helps the team choose a migration sequence, identify risks, and estimate what testing and employee support will be needed.
A well-planned tenant migration gives the business a clear scope, accountable owners, tested workflows, and a support plan before users are asked to change how they work.