Microsoft 365 data migration: planning and validation

Why a migration unit must include data and context

In a data migration to Microsoft 365, an individual file is not always a sufficient unit for defining the scope of work. A case file or dossier may require its constituent documents, structure, metadata, versions, and permissions. If you only verify that the files have reached the destination, you risk losing the context necessary to locate or use them correctly within the department’s operational processes.

An illustrative example is a contract library, where each document is associated with a client, a date, and a review status. These fields may be more important for searching than the original folder location. Before copying, you must decide how these will be represented at the destination and whether the chosen method supports the required handling. Validation should include the types of searches and queries that the team uses in their day-to-day work.

Migration also presents an opportunity to organize access rights, though any changes require approval. Legacy permissions should not be retained without review, nor should they be deleted simply because they are difficult to interpret. The data owner identifies who needs to work with the information, and the IT team determines how to implement this requirement using groups and permissions that can be maintained long after the project is complete.

How to build an acceptance sample that detects issues

The sample set must account for complex scenarios, in addition to simpler, more straightforward documents. It is advisable to include libraries containing metadata, shared content, specific permissions, and files used by various applications. The characteristics of the source, the expected outcome, and the verification at the destination are all recorded. This allows for distinguishing between a limitation inherent to the method and a configuration error.

The owner must test opening, editing, searching, and accessing items using different user profiles. If a document is accessed via a link within an application or an internal page, that path must also be verified. Issues are grouped by cause and resolved before the sample is re-tested; a bulk retry is no substitute for proper analysis and can complicate version control or lead to the creation of duplicates.

What a data migration to Microsoft 365 really entails

A migration consists of moving information from a source system to one or more Microsoft 365 services. However, this definition is incomplete, as the project also requires transferring or reconstructing the context of the data. A file without its owner, a mailbox without its delegated access, or a SharePoint site without its permissions may be technically migrated, yet remain functionally useless.

That is why the acceptance criteria for a migration should not simply be: “1.8 TB has been copied.” It should be something more like: “The appropriate users can access the correct information from the new environment, and the associated processes continue to function as intended.”

Three principles to consider before starting

1. Not everything should be migrated. A migration is an opportunity to identify: obsolete data, inactive users, duplicates, temporary files, legacy permissions, and content that no longer has operational value. Moving unnecessary data consumes time, storage, and validation effort. 2. The destination should not automatically replicate the structure of the source. A network drive created fifteen years ago does not necessarily need to be transformed into a SharePoint library with the exact same folders and permissions.

Microsoft 365 uses a different model, and it may be preferable to reorganize some of the content. 3. “Completed” does not mean “validated.” Tools report the technical status of their jobs. However, a completed task may contain: warnings, skipped files, conversions, permissions that were not reconstructed, or unsupported items. Subsequent validation is still necessary.

Key migration scenarios for Microsoft 365

Not all scenarios require a third-party tool. Microsoft has significantly expanded its native capabilities. Currently, its documentation distinguishes between two broad categories:

Specialized tools remain relevant when they provide capabilities required for a specific project.

Assessment: understanding data before moving it

A good assessment should provide enough information to answer four questions: what we have;, who uses it;, where it should end up; and what might hinder the migration..

GB and TB don’t tell the whole story

A 1 TB repository consisting of large files can be migrated more easily than a 300 GB one made up of millions of small files. That is why it is useful to know: total volume, number of objects, size distribution, permissions, and complexity.

Classify before copying

A document migration should include a content classification phase.

There is no need to clean up every single file manually. The cleanup effort should be proportional to the project. In some cases, it may be sufficient to simply delete clearly obsolete folders and fix the most problematic permissions. In other instances—especially when Microsoft 365 is replacing a file server that has been in use for decades—it may be worth investing more time in a redesign.

OneDrive or SharePoint: arguably the most important document-related decision

OneDrive and SharePoint share much of the same technology, but they serve different purposes.

Simple rule. Ask yourself: “If this person leaves the company tomorrow, should others be able to continue working with these documents as usual?” If the answer is yes, we should probably consider SharePoint. A common mistake. Migrating a departmental folder to a manager’s OneDrive might work technically, but it creates an unnecessary dependency on an individual identity.

Migrating a file server or NAS to Microsoft 365

This is one of the most common document-related projects. Microsoft currently provides its own tools for moving file shares to SharePoint, OneDrive, and other related destinations. Before migrating. It is advisable to analyze:

Don’t forget about applications that use network paths. An application may depend on: \\servidor\contabilidad\facturas Moving these files to SharePoint does not guarantee that the software will still be able to use them in the same way. These dependencies must be identified before decommissioning the file server.

Migration Manager for file shares

Migration Manager It is integrated into the SharePoint admin center and allows for the management of file share migrations to Microsoft 365. The current model uses migration agents installed on Windows computers or virtual machines that have access to the source content. What it offers.

Pilot and incremental. For file shares, Microsoft recommends using a pilot group and performing an incremental migration before the cutover. Afterward—during the final transition—the source must no longer be used, and users should work within SharePoint or OneDrive. Official reference: Microsoft – Migration Manager for File Shares.

SharePoint Migration Tool (SPMT)

SharePoint Migration Tool It remains an important tool within Microsoft’s native capabilities. Microsoft provides it free of charge for migrating content to Microsoft 365. Supported SharePoint sources. Current documentation includes:

SPMT or Migration Manager. There are scenarios where both tools can work with file shares; the choice depends on the project. Migration Manager is particularly useful for managing large-scale file share migrations from a central console and distributing tasks among agents. SPMT is especially relevant for projects involving SharePoint Server, though it can also be used for file shares. Official reference: Microsoft – SharePoint Migration Tool.

SharePoint Server to SharePoint Online

Migrating SharePoint Server requires more analysis than simply moving documents. What might exist in an older SharePoint environment: For example: sites, sub-sites, lists, libraries, metadata, content types, workflows, forms, web parts, custom solutions, master pages, scripts, and applications. Not everything is automatically transformed into modern SharePoint. A portal developed years ago on SharePoint Server may require: content migration and a functional redesign. Especially when it utilizes customizations that have no direct equivalent in SharePoint Online.

Workflows deserve their own separate review. SPMT (SharePoint Migration Tool) offers capabilities for certain SharePoint Server workflows, but any significant automation should be specifically tested. In some cases, it may be preferable to modernize it using Power Automate or another technology.

Google Workspace to Microsoft 365 migration

A Google Workspace migration is typically divided into two major technical projects.

We do not recommend reducing a Google Workspace migration to a simple IMAP transfer. Microsoft provides a specialized process for Google Workspace that can handle more data than a conventional IMAP migration—which is particularly important for calendars and contacts. Google Drive. Migration Manager allows for assessments, destination and identity mapping, and incremental migrations. Compatible Google documents can be converted into Office formats during the migration process.

External links require attention. Google’s and Microsoft’s sharing models are not identical; therefore, certain access permissions or external links will need to be reconstructed. Official reference: Microsoft – Google Workspace Migration with Migration Manager.

Dropbox, Box, and other cloud repositories

Microsoft has expanded Migration Manager to work with various external platforms. Current Microsoft 365 migration documentation presents Migration Manager as the central hub for external scenarios, such as: Google Workspace, Dropbox, Box, and file shares, among other supported sources. The same rule still applies. We should not automatically assume: “User Dropbox → OneDrive.” Dropbox may contain departmental or shared documentation that should instead be moved to SharePoint.

What to review.

Exchange Server to Exchange Online

Exchange Server can be migrated using various strategies. The choice depends on the version, number of users, coexistence requirements, Active Directory, applications, and calendar data.

Email is not the only dependency of Exchange. We must review: SMTP relay, applications, printers, scanners, connectors, certificates, Autodiscover, shared mailboxes, rooms, archives, and delegated permissions.

Exchange Server 2016 and 2019 in 2026

This article should reflect a significant change. Support for Exchange Server 2016 and Exchange Server 2019 ended on October 14, 2025. Microsoft is directing organizations toward Microsoft 365 or Exchange Server Subscription Edition. Extended Security Updates (ESU). Microsoft maintains an ESU program for certain Exchange Server 2016 and 2019 customers. This does not change the fact that these versions have reached the end of their standard support lifecycle.

Why it matters for a migration. If a company is still running Exchange 2016 or 2019 in 2026, the project should review: Current Cumulative Update (CU), security updates, ESU status, Active Directory, applications, and the definitive path toward Microsoft 365 or Exchange SE. Official reference: Microsoft – Exchange 2016 and 2019 End of Support.

IMAP migrations

IMAP allows for the migration of primarily email and folders. It does not represent a complete mailbox in the way Exchange does.

The source server may impose speed limits. Hosting providers often set limits on connections, throughput, or sessions. For this reason, a pilot test is useful for estimating actual performance. Not all IMAP systems are the same. Systems such as Zimbra, cPanel, Dovecot, or Courier may offer additional features beyond standard IMAP. If calendars or contacts are required, it is necessary to check for an API, an export function, or a specialized tool capable of retrieving them.

POP3, PST, and locally stored data

POP3 introduces a significant challenge: the server may not retain the full history, as messages might have already been downloaded to the user’s device. Before migrating. You must determine where the data is located:

Consequently, a POP-based migration may require more operational effort than an IMAP-based migration for the same number of users.

Microsoft 365 tenant-to-tenant migration

Migrations between tenants occur during mergers, acquisitions, carve-outs, consolidations, and corporate reorganizations. Even when both the source and destination are Microsoft 365, these projects tend to be particularly complex because each tenant has its own directory, domains, objects, permissions, and applications. There is no universal “move tenant” operation. Workloads must be handled in a coordinated manner.

Microsoft currently offers three approaches. Its documentation distinguishes between:

Official reference: Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration.

What Microsoft Migration Orchestrator actually moves

As of 2026, it is important to be very precise regarding this functionality, as it is evolving rapidly. Current Microsoft documentation specifies four supported workloads within an orchestrated user data migration:

What should not be assumed to migrate. Microsoft explicitly states that this solution does not migrate shared data such as Teams/Channels or SharePoint sites. These components require the corresponding SharePoint path or the tool that has been defined for the project. Move content, not identities. Users must exist and be correctly prepared in the target tenant. Identity mapping is a prerequisite.

Dependencies. Teams Meetings depend on Exchange and Teams Chats within the corresponding batch. The Orchestrator itself sequences the supported workloads to respect their dependencies. OneDrive does not function like a traditional pre-migration. The native cross-tenant migration for OneDrive involves a move; Microsoft states that there are no subsequent incremental or delta passes. This must be taken into account when designing the cutover.

Official reference: Microsoft – Migration Orchestrator Overview.

Cross-tenant tools, categorized by… Workload

Microsoft also provides separate procedures. Cross-Tenant Mailbox Migration. Allows for the transfer of Exchange Online mailboxes between tenants. It requires proper preparation of identities and attributes in the target environment. Mailboxes subject to certain holds may be ineligible for this procedure. Cross-Tenant OneDrive Migration. Allows for the movement of OneDrive between tenants. This is a definitive move and has specific requirements regarding the preparation of the target environment. Cross-Tenant SharePoint Migration.

Allows for the movement of SharePoint sites between tenants. It also has requirements regarding identity, the target environment, and structure. Official references:

• Cross-Tenant Mailbox Migration
• Cross-Tenant OneDrive Migration
• Cross-Tenant SharePoint Migration

Migrating Microsoft Teams requires understanding what lies behind Teams

Teams uses various Microsoft 365 services.

Therefore, “migrating Teams” should be broken down into its components. The scope must be clearly defined. For example: Teams, channels, files, 1:1 chats, group chats, meetings, Planner, tabs, apps, guests, and permissions. Not all tools migrate all these elements, nor do they do so with the same level of fidelity.

Microsoft Entra ID: data needs owners

Data migration depends on identities. Before moving content, the appropriate users and groups must be in place at the destination. What to review.

Microsoft Entra Cloud Sync or Connect Sync

If an organization maintains an on-premises Active Directory, Microsoft Entra Connect Sync should no longer be considered the only option. Microsoft currently defines Entra Cloud Sync as its strategic direction for hybrid identity synchronization. New synchronization capabilities are primarily being developed for Cloud Sync, and Microsoft recommends it as the future path for most organizations, provided the scenario is supported.

Therefore, the decision depends on the features currently in use. Official reference: Microsoft – Connect Sync to Cloud Sync Decision Guide.

Permissions, owners, and external access

Migrating documents without their permissions can be a problem. Migrating them while preserving all historical permissions can also be problematic. A migration is an opportunity to review access rights. In particular: Inactive users, former vendors, temporary access, personal accounts, and groups without an owner. NTFS and SharePoint permissions. There is no perfect conceptual equivalent between a highly granular NTFS structure and a modern SharePoint permission design.

In many cases, it is preferable to use: groups, clear owners, and permissions at the site or library level instead of replicating hundreds of distinct ACLs. External sharing. External links and guest permissions must be validated on an individual basis, depending on the tool and the source. It should not be assumed that a link created in a Google, Dropbox, or SharePoint source will continue to function after the migration.

Metadata, versions, and file types

Enterprise content consists of more than just the binary file.

Google Workspace. For example, native Google formats can be converted to Word, Excel, or PowerPoint using the supported capabilities of Migration Manager. Such conversions should be tested using complex documents.

Technical limits: don’t memorize outdated figures

Microsoft’s limits are subject to change and should be verified before each project. As of the date this guide was updated, Microsoft documents a maximum file size of 250 GB for the primary migration paths using Migration Manager and SPMT:

This figure does not mean that a file of that size is always appropriate, nor is it the only relevant limit. We must also consider: paths, names, number of items, character counts, destination quotas, throttling, speeds, and source-specific restrictions. Official reference: Microsoft – File Size Limitations for Migration.

Applications and integrations: data that doesn’t appear in a folder

There are dependencies that are not apparent when simply looking at the size of the repositories.

Especially important for file servers. Before decommissioning a file server, check whether any applications are using UNC paths directly. Especially important for tenant-to-tenant migrations. An app registration from the source tenant does not automatically appear in the new tenant with its associated secrets, permissions, and consents; it must be planned for separately.

Security before, during, and after migration

A migration may require administrative permissions and elevated consents. This must be managed and monitored. Basic principles.

Do not enable complex security configurations during the cutover without prior testing. If using Conditional Access, perform testing—utilizing “Report-only” mode where appropriate—before applying any policy that could potentially block users or administrators.

Retention, holds, and Microsoft Purview

Compliance requirements can fundamentally alter a migration. Do not delete information subject to a retention policy without first analyzing it. Especially in Exchange and tenant-to-tenant scenarios, certain holds may even block specific native methods. Before migrating. It is important to be aware of: Retention policies, retention labels, Litigation Hold, eDiscovery cases, auditing, and legal obligations. After migration. Policies in the destination environment must be validated to confirm that the new data is handled appropriately.

How to choose a migration tool

There is no universal “best tool.”

Questions we use for selection. Primarily: Source, destination, volume, number of objects, permissions, deltas, coexistence, reporting, required fidelity, timeline, and cost.

PowerShell and Microsoft Graph during a migration

PowerShell and Microsoft Graph are particularly useful for: Assessment, preparation, automation, reporting, and validation. However, they should not be presented as a universal data-copying tool.

Microsoft Graph PowerShell

Can be used to inventory users:

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"

Get-MgUser -All -Property DisplayName,UserPrincipalName,Mail,AccountEnabled |
    Select-Object DisplayName,UserPrincipalName,Mail,AccountEnabled |
    Export-Csv "C:\Temp\usuarios-microsoft-365.csv" -NoTypeInformation -Encoding UTF8

Exchange Online PowerShell

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
    Select-Object DisplayName,PrimarySmtpAddress,RecipientTypeDetails |
    Export-Csv "C:\Temp\buzones-exchange-online.csv" -NoTypeInformation -Encoding UTF8

These examples are provided for guidance. Permissions, modules, and commands should be reviewed before being used in a production environment. Useful automation. PowerShell is also particularly useful for:

Phases of a well-structured data migration

The pilot phase should aim to uncover issues

A pilot consisting of only three users with small mailboxes and ten documents does not provide much useful information. Representative use cases.

What we gain from the pilot. Actual speed, types of errors, manual tasks, changes for users, and necessary adjustments to the runbook.

Pre-migrations and incremental migrations

When supported by the technology, migrating data before the cutover helps reduce the final cutover window. Standard model. This scenario includes: initial migration, users continuing to work in the source environment, delta synchronization, cutover, final synchronization, and validation. Not all methods support delta synchronization. This point is particularly important. Third-party tools and Migration Manager may offer incremental models for certain workloads.

Some native Microsoft cross-tenant migrations, such as those for OneDrive, function as a definitive move and do not support a classic pre-migration/delta sequence. The runbook must be designed based on the actual behavior of the tool.

Cutover: the moment the working system changes

The cutover process may vary depending on the type of data.

A well-structured runbook specifies: what is to be done, who is responsible, the sequence of actions, how validation is performed, and the conditions that require the process to be halted.

Validating data, not just migration jobs

Validation should consist of multiple layers. 1. Quantitative validation. Compare: files, sizes, mailboxes, objects, sites, and errors. 2. Technical validation. Check: Permissions, versions, metadata, email, DNS, and applications. 3. Functional validation. Actual users should confirm that they can perform their usual tasks.

Reports must be retained. It is useful to save: Initial inventory, mappings, errors, exceptions, and final validations as project documentation.

Communicating with users

A technically flawless migration can still lead to frustration if users do not know where their documents are on Monday morning. What users need to know beforehand.

Cloud migration and end-user device support are distinct scopes. Users may need to sign in again, configure Outlook, or update access credentials. However, providing individual, hands-on support for each computer is a separate task from migrating data within Microsoft 365; if required, it should be explicitly included in the project scope.

How long does a data migration to Microsoft 365 take?

There is no formula based solely on terabytes (TB) or the number of users.

A pilot phase is the best source for estimating performance. Once a real-world sample has been observed, we can adjust: concurrency, migration waves, the change window, and total duration.

What determines the cost

A data migration may involve several cost components.

A free tool does not always mean a cheaper project.

It may be perfectly adequate if it covers the scenario well. However, if a specialized solution reduces weeks of manual work, its license cost may prove to be economically sound.

Common mistakes in a data migration to Microsoft 365

Checklist before migrating data to Microsoft 365

Frequently asked questions about migrating data to Microsoft 365

What should the scope of a data migration include?

It must identify sources and destinations, as well as the context that needs to be preserved—such as permissions, owners, metadata, versions, and related processes, where applicable. Each item should be linked to a specific migration method and acceptance test. This ensures clarity regarding what will be copied versus what requires adaptation or reconstruction.

Is it advisable to clean up information before migrating it?

While it can reduce complexity, it requires clear criteria and designated owners. The department must decide what content remains necessary and how to handle information that is obsolete or subject to retention requirements. Cleanup should not be based solely on age or size; while these indicators help identify potential candidates for removal, they do not replace the need for a decision by the owner.

How do you verify that permissions are correct?

A matrix of profiles and resources is used to test both permitted access and access that should be restricted. Simply counting the number of assignments does not prove that the outcome is appropriate. Testing must be conducted using representative accounts—including those involving external collaboration, where applicable—and documentation of any approved exceptions must be maintained.

Why is comparing the number of gigabytes copied insufficient?

Size provides information about volume, but it does not confirm structure, metadata, searchability, or usage. A destination may contain the same amount of data and still be unsuitable for a critical process. Acceptance criteria must incorporate technical reports, a review of discrepancies, and testing of the tasks users perform with that information.

Final recommendations: migrating data to Microsoft 365 is a matter of deciding first and copying later

A Data migration to Microsoft 365 This can encompass email, documents, users, SharePoint, OneDrive, Teams, applications, and identity. Microsoft’s technology has evolved significantly, and there are now native pathways for a wide range of scenarios. Migration Manager allows for the centralization of migrations from file shares and various external platforms. The SharePoint Migration Tool remains particularly useful for SharePoint Server and file shares. Exchange Online has its own dedicated migration paths. Furthermore, Microsoft’s cross-tenant capabilities enable the handling of Exchange, OneDrive, SharePoint, and specific Teams data through specialized tools.

However, no tool can replace the design phase. Before moving a file, we must determine whether it belongs to an individual user or the organization. Before relocating a site, we need to identify its owners and permissions. Before migrating a mailbox, we must understand its delegations and associated applications. And before consolidating tenants, we must define identity, domains, and dependencies between workloads.

There are also technological shifts that should be integrated into any current project. Exchange Server 2016 and 2019 will be beyond their standard support lifecycle as of October 2025. Microsoft Entra Cloud Sync now represents the strategic direction for many new hybrid identity scenarios. Migration Orchestrator offers new tenant-to-tenant possibilities, but its scope should be understood correctly—it is not a “magic button” that migrates an entire Microsoft 365 environment.

A sound methodology begins with discovery and assessment, followed by classification and architecture; it then involves selecting the appropriate tool, running a pilot, and utilizing pre-migration steps whenever possible. The cutover process should be documented, and final acceptance should combine technical metrics with functional testing. A migration is considered complete when the appropriate users and processes can access the correct data within Microsoft 365, using the intended identities, permissions, and structure..

Recommended official documentation

Microsoft 365 Migration.

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

Migration Manager.

• Microsoft – Migration Manager for File Shares
• Microsoft – How Migration Manager Works
• Microsoft – File Share to SharePoint and OneDrive Migration Guide
• Microsoft – File Size Limitations for Migration

SharePoint Migration Tool.

• Microsoft – SharePoint Migration Tool
• Microsoft – How to Use SPMT

Google Workspace.

• Microsoft – Google Workspace Mail Migration
• Microsoft – Google Workspace Migration with Migration Manager

Exchange Online.

• Microsoft – Ways to Migrate Email to Microsoft 365
• Microsoft – Exchange Hybrid Deployments
• Microsoft – Exchange Server 2016 and 2019 End of Support
• Microsoft – Exchange Supportability Matrix

IMAP.

• Microsoft – IMAP Mailbox Migration

Tenant-to-Tenant.

• Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
• Microsoft – Migration Orchestrator Overview
• Microsoft – Running a Migration with Migration Orchestrator
• Microsoft – Cross-Tenant Mailbox Migration
• Microsoft – Cross-Tenant OneDrive Migration
• Microsoft – Cross-Tenant SharePoint Migration

Microsoft Entra ID.

• Microsoft – What is Microsoft Entra Cloud Sync?
• Microsoft – Connect Sync to Cloud Sync Decision Guide