How to migrate to Microsoft 365: planning and checks

How to build a migration plan based on progression criteria

A migration plan for Microsoft 365 is most effective when each phase concludes with a verifiable condition. An inventory is considered complete only when the necessary sources and dependencies are identified—not simply when a spreadsheet of unreviewed data is delivered. Preparation is complete when the target environment is ready for a pilot. The cutover is approved only once testing is finished and the relevant stakeholders confirm that all agreed-upon conditions have been met.

This approach avoids the pitfall of setting dates as if tasks were independent of one another. If an application requires an authentication change, or if a department needs to review its permissions, that dependency is mapped out in the schedule, along with the person responsible for it. The team can then decide whether to address it immediately, move it to a different phase, or acknowledge that it acts as a blocker for that specific part of the project.

The pilot phase should test scenarios that have the potential to alter the migration plan. While a standard user account is useful for verifying the technical foundation, it does not account for complexities like delegated mailboxes, libraries with unique permission structures, or devices running mission-critical applications. The results should be used to refine the project’s scope and timeline, rather than being treated as a mere demonstration assumed to be approved in advance.

How to determine whether an issue allows you to proceed

Before the change window, criteria for severity and the individuals responsible for decision-making are agreed upon. An incident that prevents access to a critical process can halt progress, even if it affects only a few users. A minor discrepancy in presentation—once understood and accepted—can be addressed later without compromising system functionality. Priority is determined by the actual impact and the available alternatives.

The record must detail what is failing, who is affected, and what evidence confirms that a fix has been successful. It must also include a decision point to determine whether to proceed, halt, or implement a pre-planned contingency. A rollback plan must be evaluated based on the specific methodology and the changes applied; for instance, if users have already generated new data within the system, a rollback is not as simple as merely reverting a configuration setting.

What migrating to Microsoft 365 really means

Microsoft 365 is a suite of related services. A migration can affect one of these services or virtually the entire platform. A simple migration might involve nothing more than replacing an IMAP email provider with Exchange Online. A broader transformation, however, may encompass email, documents, identity, security, collaboration, devices, and applications.

Therefore, an organization should not use the term “migration to Microsoft 365” as if it described a single technical operation. Instead, it should be defined in terms of a specific scope: which services will be activated, which data will be moved, which elements will not be migrated, what will be rebuilt, and who will be responsible for each component.

Why migrate to Microsoft 365

The primary reason should not simply be “moving to the cloud.” Microsoft 365 can provide value by helping to simplify systems, improve collaboration, centralize identity, and reduce reliance on infrastructure that the company no longer needs to maintain. Email without the need for an in-house Exchange infrastructure. Exchange Online allows for the use of business email, calendars, contacts, shared mailboxes, and room or resource scheduling, without the need to maintain traditional organizational mail servers.

This does not eliminate the need to manage Exchange, but it shifts the nature of that management: instead of maintaining infrastructure, the focus moves toward configuration, security, permissions, and governance. Accessible, shared business documentation. SharePoint and OneDrive allow information to exist independently of network drives, VPNs, or files sent via email. However, the true benefit is realized only when the document architecture is well-designed. Simply uploading legacy folders to SharePoint without reorganizing them does not automatically transform a file server into an effective collaboration platform.

A unified identity. Microsoft Entra ID enables the centralization of identities, providing access to Microsoft 365 and other applications through SSO (Single Sign-On), MFA (Multi-Factor Authentication), and access policies. For companies with an on-premises Active Directory, a hybrid model can be maintained for as long as necessary. Collaboration via Teams. Teams brings together chat, meetings, and collaborative workspaces, while also integrating closely with SharePoint, OneDrive, Exchange, and Microsoft 365 Groups.

This facilitates a consistent user experience—provided there is a baseline level of governance regarding teams, channels, guest access, and applications. Security with greater context. A well-designed Microsoft 365 architecture can implement controls based not only on a user’s password, but also on identity, role, device, risk, application, and other factors. The technology is available, but it requires proper configuration and licensing. Migrating to Microsoft 365 while deferring the implementation of security policies until months later means missing out on a key aspect of the project.

Before migrating: define your desired future environment

A migration is an opportunity to move away from decisions made years ago that may no longer make sense. Before copying any data, it is advisable to define the desired future state.

This phase helps avoid one of the most common mistakes: replicating all the issues from the previous environment within Microsoft 365..

Assessment: what you need to know before moving data

A good assessment is not just a theoretical document. Its purpose is to translate the current environment into data that enables informed decision-making. The level of detail depends on the project, but at a minimum, it should cover the following areas:

The number of users does not determine the level of difficulty.

A company with 40 users might face a complex migration if it involves multiple domains, integrated applications, a large volume of shared data, and a hybrid identity setup. Conversely, a company with 300 users and a straightforward email environment might be more predictable. The effort depends on volume, dependencies, and exceptions—not just the number of accounts.

Microsoft Entra ID: identity must be designed before data

Microsoft Entra ID This is Microsoft’s identity and access service, formerly known as Azure Active Directory. In a Microsoft 365 project, it affects virtually everything: sign-in, UPNs, groups, permissions, Teams, SharePoint, applications, MFA, Conditional Access, and devices. That is why it is best to resolve identity-related decisions before carrying out large-scale migrations. Cloud-only or hybrid. Not every company needs to eliminate its on-premises Active Directory.

We can distinguish between two basic models.

The choice depends on on-premises applications, servers, devices, authentication requirements, and technology strategy. UPN and domain. The UPN used by the user to sign in should be reviewed before migration. In many projects, it is desirable for users to be able to identify themselves using a consistent address, for example: nombre.apellido@empresa.com If Active Directory remains the authoritative source for certain attributes, changes must be applied consistently from that source, rather than just from the cloud portal.

Microsoft Entra Cloud Sync or Connect Sync

By 2026, it is no longer advisable to present Microsoft Entra Connect Sync as the only option for synchronizing Active Directory with Microsoft Entra ID. Microsoft is positioning Microsoft Entra Cloud Sync as its strategic direction for most new hybrid synchronization scenarios. Cloud Sync uses lightweight agents in the on-premises environment, while configuration and orchestration are managed from Microsoft Entra.

Therefore, there is no universal answer. For a simple scenario or one involving multiple disconnected forests, Cloud Sync can be a particularly attractive option. If the organization relies on Hybrid Join for devices or on advanced synchronization rules that do not yet have an equivalent, Connect Sync may still be necessary. Official reference: Microsoft – Entra Connect Sync to Cloud Sync decision guide.

Licensing: designing it based on users and services

Licensing should be reviewed during the design phase, not the week before the cutover. Not all users necessarily require the same plan.

Do not base your project design on plan names. Microsoft periodically changes its packaging, naming, and commercial terms. It is safer to start with the requirements: what each user profile needs to do, and what security or management capabilities the company requires. Then, select the plan that meets those needs. Dual licensing during a transition. In certain migrations, there may be a temporary period during which some users require services or licenses in both the source and destination environments.

This cost must be included in the project budget.

Migrating email to Exchange Online

Email is typically the component with the lowest tolerance for errors. While a user might accept a delay of a few hours for historical documents to appear, they expect to be able to send and receive email immediately following the transition. For this reason, Exchange requires its own dedicated assessment.

Possible migration paths. The procedure depends on the source environment.

Official reference: Microsoft – Ways to migrate multiple email accounts to Microsoft 365.

Migrating IMAP email to Microsoft 365

IMAP is one of the conceptually simplest methods, but it also has a fundamental limitation: it is designed primarily for email. An IMAP migration allows for the transfer of messages and folders, but it should not be expected to automatically migrate:

This distinction should be communicated before starting, because for a user, “my mailbox” might encompass email, a schedule, and a calendar, whereas, technically, an IMAP migration covers only a portion of that.

Exchange Server and hybrid migration

When the source is Exchange Server, the design can be considerably more sophisticated. In medium-sized or large environments, it may make sense to establish a hybrid configuration between Exchange Server and Exchange Online. This allows for coexistence during the transition and enables the progressive migration of mailboxes. When a hybrid strategy might make sense. For example, when: there are many users, the migration will take weeks, calendar coexistence is required, or there are still significant dependencies on Exchange Server.

Not all Exchange Server environments require a complex hybrid setup. In smaller organizations, other migration paths may exist. The Exchange version, the number of mailboxes, the required coexistence, and related applications should determine the method. Official reference: Microsoft – Exchange hybrid deployments.

Google Workspace to Microsoft 365 migration

Migrating from Google Workspace can involve much more than just moving Gmail. The various services must be separated.

Google Drive should not be copied without redesigning the destination. A shared folder in Google does not always have a direct equivalent in OneDrive. If the documentation belongs to a department or a business process, SharePoint is usually a more logical destination. For this reason, mapping should be carried out before the migration job.

Migrating files to Microsoft 365

Document migrations often lead to many issues when treated as a bulk copy of folders. Microsoft 365 is not simply a file server hosted on the Internet. SharePoint and OneDrive operate using concepts such as: sites, libraries, permissions, metadata, versioning, sharing, synchronization, and collaboration. Before moving content, it is advisable to decide which information belongs to each service.

OneDrive or SharePoint: a fundamental decision

The simplest way to distinguish between them is to consider the ownership of the information.

A common mistake. Moving a shared drive from a server to the OneDrive of a department head. While technically feasible, this turns company information into data dependent on an individual account. When content belongs to a team, SharePoint should generally be considered instead.

Migrating to SharePoint Online

SharePoint can ingest content from file servers, SharePoint Server, Dropbox, Google Drive, Box, and other platforms. However, the source structure must be evaluated before migration.

Microsoft tools. Microsoft currently offers several paths. SharePoint Migration Tool It remains an option for SharePoint Server and file shares. Migration Manager It allows for the management of migrations from various external sources to Microsoft 365, including file shares and supported cloud platforms. Official reference: Microsoft – Migrate your content to Microsoft 365.

Migrating to OneDrive

OneDrive is typically used to replace personal folders or storage linked to individual users. During a migration, it is advisable to check not only how many gigabytes each person has, but also what they are sharing. Why sharing matters. A user might have only a few files, but hundreds of links shared with colleagues and vendors. If the content changes location, those access permissions may need to be reviewed.

Inactive users. You must also decide how to handle the accounts of employees who no longer work for the organization. It does not always make sense to create a new account solely to replicate an old OneDrive. In some cases, it is preferable to consolidate relevant information into a corporate location.

Microsoft Teams: collaboration, not just chat

Teams serves as the visible layer for various Microsoft 365 services.

This architecture has two implications. The first is that Teams should not be implemented without considering SharePoint and OneDrive. The second is that a migration of Teams between tenants or platforms may involve multiple workloads. Basic governance before rolling out Teams to the entire organization. There is no need to build a bureaucratic system, but it is advisable to define at least the following:

Official reference: Microsoft – Microsoft Teams overview.

Security must be designed into the migration process

For years, many migrations followed this sequence: move the data first, and configure security later. It is better to avoid this approach. The tenant should be prepared with a security foundation before users begin working within it.

MFA and Conditional Access in 2026

MFA should no longer be treated as an optional enhancement to be implemented “later.” Microsoft has been introducing mandatory MFA for its administrative portals and tools; any new project should be designed with the assumption that administrative access will require multi-factor authentication. Security Defaults. For environments that do not use Microsoft Entra ID P1 or P2, Security Defaults provide a baseline of protection managed by Microsoft.

This is a simple option for organizations that do not require exceptions or highly detailed policies. Conditional Access. When an organization has the appropriate licensing, Conditional Access allows for the creation of more granular policies. For example: requiring MFA, blocking legacy authentication, mandating the use of specific devices, or applying additional controls based on risk. Do not activate complex policies directly in a production environment. For Conditional Access policies, it is recommended to first use Report-onlymode, review which users and applications would be affected, and then activate the policy.

Administrators: Phishing-resistant MFA

For privileged accounts, it is worth going beyond traditional MFA. Microsoft recommends phishing-resistant methods for administrative roles—utilizing technologies such as passkeys/FIDO2—whenever the specific scenario and the organization are ready. Official reference: Microsoft – Require phishing-resistant MFA for administrators.

SPF, DKIM, and DMARC during migration

A migration to a new email platform is the perfect opportunity to review your domain authentication.

Don’t forget about your applications. Problems often arise when SPF records are updated with only Exchange Online in mind, while overlooking: ERPs, CRMs, printers, web applications, ticketing systems, newsletters, and other systems that send email on behalf of the company. These senders must be inventoried before the change.

Microsoft Purview: compliance and information protection

Microsoft Purview brings together various capabilities related to data governance, security, and compliance. Depending on the organization’s licensing and needs, the following may come into play:

A migration does not mean that all these functions must be implemented from day one. However, if any legal or retention policies exist in the previous system, they must be identified before moving or deleting data. Official reference: Microsoft – Purview documentation.

Microsoft Intune and device management

If the Microsoft 365 transformation also includes devices, Microsoft Intune can be used to manage policies, applications, and compliance. Note, however, that the migration of email and data does not necessarily have to take place on the same day as the device transformation.

Decisions to be made

This phase must be coordinated with the team that manages endpoints. A Microsoft 365 migration should not automatically assume physical support or individual configuration of all workstations unless explicitly included in the scope.

Applications and Integrations: the area most easily overlooked

An organization might successfully migrate all mailboxes and files, yet still face a major issue on Monday if its ERP system can no longer send emails or its HR application stops authenticating users.

Applications using user accounts as a service. It is also a good time to identify automations that rely on a user account and password. Whenever possible, new integrations should use workload identities, managed identities, service principals, or certificates, rather than maintaining interactive user accounts with permanent passwords.

Tools for migrating to Microsoft 365

There is no single tool that works for all source environments. Microsoft currently organizes its tools based on the type of migration. Migrations from external platforms. Migration Manager This is currently one of Microsoft’s primary tools for managing the migration of external content to Microsoft 365. Microsoft provides support for sources such as: File shares, Google Workspace/Drive, Dropbox, Box, and other supported scenarios.

SharePoint Migration Tool. SPMT continues to play an important role for SharePoint Server and file shares. Tenant-to-Tenant. For migrations between Microsoft 365 tenants, Microsoft currently offers specific tools for:

Specialist tools

There are also third-party platforms that may be better suited for certain projects.

The choice should be made after the inventory, not before. Official reference: Microsoft – Microsoft 365 Migration Overview.

Recommended phases for a Microsoft 365 migration

The exact procedure varies depending on the environment, but an enterprise project typically benefits from a structured sequence.

Discovery. This must provide a sufficiently reliable picture of the source environment. While it is not necessary to document every single file before beginning, you must understand the factors that could impact the architecture, budget, and timeline. Design. This is where decisions are made regarding the destination of the information, identity, licensing, security, domains, and the migration method. Preparation. It is better to set up the tenant correctly before moving any data, rather than attempting to make corrections during the cutover.

Phased migration (migration in waves). For medium to large organizations, it is generally more practical to group users by department or functional unit. This simplifies support and allows for lessons learned from one wave to be applied to the next.

How to design a pilot that effectively uncovers issues

A pilot group should not consist solely of the IT director and a couple of small, low-activity mailboxes; representative use cases must be selected.

Following the pilot, the following should be documented: Actual timeframes, errors, functional differences, manual actions, and necessary changes to the runbook.

The cutover: preparing for the change, not improvising it

The cutover is the phase in which operations that could not be performed normally beforehand are executed. This may include DNS changes, final user activation, domain modifications, and delta synchronizations. A good runbook should specify who is responsible for each task.

Actual timeframes must be defined for each individual project. The table above represents a work structure, not a guaranteed duration.

Communication and adoption: the migration from the user’s perspective

The user does not see the tool’s dashboard. They see Outlook, Teams, and their documents. Therefore, they need to know what is going to change.

Don’t turn a migration into an eight-hour Microsoft 365 training course. The most useful training is usually related to the actual changes the user will experience. For example: how to properly share a document, where to save files, how to use Teams, how to register for MFA, or how to distinguish between OneDrive and SharePoint.

How to validate that the migration has been completed successfully

A job in a specific state Completed is not a sufficient acceptance criterion. Validation must combine technical data with functional testing.

Functional validation. Key users should also be involved. The technical team might confirm that a library contains 20,000 files, but the Finance manager will know whether the documents they need for month-end closing are where they expected them to be.

How long does a migration to Microsoft 365 take?

There is no standard duration. Two projects with 100 users each can have completely different timelines.

The timeline should be estimated after the discovery phase and adjusted based on the results of the pilot.

How much does it cost to migrate to Microsoft 365?

Costs should not be calculated simply by multiplying the number of users by a fixed rate; there are several components involved.

A free tool does not always result in the most cost-effective project if it requires significantly more hours spent on manual processes. Conversely, an advanced tool is not necessarily required for a simple environment.

Common mistakes when migrating to Microsoft 365

Checklist for a Microsoft 365 migration

Frequently asked questions about migrating to Microsoft 365

What should be the first step in migrating to Microsoft 365?

Define the objective and review the environment that supports the company’s operations. The inventory must include relevant data, identities, applications, and dependencies, with designated individuals capable of validating decisions. This foundation allows for the selection of the destination and the method; choosing a tool first may overlook requirements that could shape the entire project.

How are users for the pilot selected?

Select profiles that represent actual usage and scenarios that might present challenges. In addition to standard users, this may include branch offices, mobile users, specific applications, or shared information. The pilot should include defined tests and expected outcomes, and its findings must be incorporated into the plan before scaling up the migration.

What is required to approve the change window?

Approval should be based on agreed-upon conditions: the destination must be prepared, pilot testing must be completed, key personnel must be available, and validation and contingency procedures must be established. External dependencies and user communications must also be reviewed. While the successful completion of an initial transfer is a useful indicator, it does not, on its own, satisfy all these conditions.

Can an automatic rollback be prepared for any migration?

This should not be assumed. The ability to reverse a migration depends on the method used, changes to identities and domains, and any new data generated at the destination. The plan must document what can be reversed, the timeframe for doing so, and the associated consequences. These conditions must be understood before the cutover, while there is still an opportunity to adjust the scope and strategy.

Final recommendations: migrating to Microsoft 365 is about designing a new environment, not just moving data

A migration to Microsoft 365 It may begin with a seemingly simple need—such as changing email systems, decommissioning a file server, or adopting Teams—but end up impacting identity, documents, applications, and security. Therefore, the best approach is to break the project down into manageable decisions. First, we assess the current environment. Next, we define the desired future state. Then, we design the identity, licensing, security, and document architecture. Only after that do we select the tools and begin migrating information.

Microsoft now offers more native migration capabilities than it did a few years ago: Migration Manager for various external sources, the SharePoint Migration Tool, and cross-tenant tools for multiple workloads, as well as Migration Orchestrator for specific, coordinated migration tasks. Third-party tools continue to play an important role when they offer superior capabilities for discovery, data transformation, incremental migrations, reporting, Teams-related tasks, coexistence, or multi-workload support. Identity management has also evolved. Microsoft Entra Cloud Sync is now Microsoft’s strategic direction for many new hybrid scenarios, although Connect Sync remains relevant when specific functionalities—not yet available in Cloud Sync—are required.

Security should no longer be left until after the project is complete. MFA, Conditional Access, administrative roles, email security, and data protection should all be part of the initial design. A well-executed migration is complete when users are able to log in, send emails, locate their documents, collaborate, and use their applications—all with the intended security controls in place..

Recommended official documentation

Microsoft 365 Migration.

• Microsoft – Microsoft 365 Migration Overview
• Microsoft – Microsoft 365 Migration Documentation

Exchange Online.

• Microsoft – Ways to migrate multiple email accounts to Microsoft 365
• Microsoft – Exchange Hybrid Deployments
• Microsoft – Cross-Tenant Mailbox Migration

SharePoint, OneDrive, and content.

• Microsoft – Migrate your content to Microsoft 365
• Microsoft – SharePoint Migration Tool
• Microsoft – Migration Manager

Microsoft Entra ID and hybrid identity.

• Microsoft – Microsoft Entra ID name change
• Microsoft – What is Microsoft Entra Cloud Sync?
• Microsoft – Connect Sync to Cloud Sync decision guide

MFA and Conditional Access.

• Microsoft – Mandatory Multifactor Authentication
• Microsoft – Conditional Access Overview
• Microsoft – Security Defaults
• Microsoft – Require Phishing-Resistant MFA for Administrators

Microsoft Teams.

• Microsoft – Microsoft Teams Overview

Microsoft Purview.

• Microsoft – Microsoft Purview Documentation

Tenant-to-Tenant.

• Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
• Microsoft – Migration Orchestrator
• Microsoft – Cross-Tenant OneDrive Migration
• Microsoft – Cross-Tenant SharePoint Migration