Migrating to Microsoft 365 and Azure: a business guide

How to structure a project that combines Microsoft 365 and Azure

A migration to Microsoft 365 and Azure should be organized by services and dependencies. Email, collaboration tools, and documents have different requirements than servers and databases. Identity is often the common link, but an application might also rely on sending messages, querying a local directory, or accessing a network folder. These connections determine the sequence of work and the testing required for each phase.

Consider a company that wants to retire two servers: one stores documents, and the other runs a management application. The documents could be moved to SharePoint after reviewing their permissions and structure. The application, however, might require a virtual machine, a compatible database, and connectivity to the office. Moving both on the same day would unnecessarily complicate the cutover without providing any clear operational advantage. The sequence must be justified by how the services function.

For each service, a specification sheet is prepared, detailing the owner, affected users, data, dependencies, destination, change window, and acceptance criteria. This sheet also notes which elements will temporarily remain in the original environment. This document ensures that both the business and IT teams approve the same solution; an application might be technically available, yet still unusable if it fails to print, authenticate users, or connect to the system that receives its orders.

How to obtain a useful estimate of timeline and cost

While data volume (in gigabytes) helps in estimating transfer requirements, it does not capture the full scope of the effort. A server with very little data may actually require more work than a large mailbox if it depends on legacy software or an external provider. To estimate a project, it is advisable to break it down into analysis, preparation, migration, validation, and ongoing support. Each phase has a defined duration, assigned responsibilities, and specific prerequisites for commencement.

A pilot phase should be used to refine these estimates based on real-world data. In Microsoft 365, this involves observing the time required for a representative sample and identifying any exceptions that arise. In Azure, it entails verifying resource consumption, application responsiveness, connectivity, and recovery capabilities. If a machine is sized solely based on the resources allocated to it in the data center, there is a risk of carrying over excess capacity—effectively turning it into an ongoing, unnecessary expense.

Before decommissioning the source environment, a full end-to-end workflow must be validated—from initial user access to the generation of the final output required by the business. It must be clearly documented who will be responsible for managing accounts, addressing alerts, and monitoring consumption post-migration. This operational handover ensures that a properly deployed platform does not end up unmonitored once the project team has completed its work.

What migrating to Microsoft 365 and Azure really means

The term cloud migration encompasses a wide variety of projects. It could refer to a company with ten IMAP email accounts looking to switch to Exchange Online, or it could involve a large corporate group with multiple tenants, hundreds of servers, internal applications, hybrid directory structures, and several terabytes of data. In both cases, the term “migration” is used, even though, technically, the processes have very little in common.

A cloud strategy can encompass multiple projects. For example, an organization might: migrate email to Exchange Online, move departmental folders to SharePoint, introduce Teams, onboard devices to Intune, temporarily maintain an on-premises Active Directory, migrate various servers to Azure, modernize only specific applications, and decommission the datacenter six months later. All of this is part of a single transformation, but it should not be executed as one monolithic technical block.

Microsoft 365 and Azure: what each platform solves

Although they belong to the Microsoft Cloud ecosystem, Microsoft 365 and Azure have different objectives.

Identity connects both worlds. Microsoft Entra ID It becomes a cross-cutting element. You can control access to: Exchange, Teams, SharePoint, OneDrive as well as to: the Azure Portal, enterprise applications, and cloud resources. For this reason, identity design should be addressed before treating Microsoft 365 and Azure as two completely independent projects.

Why companies migrate to Microsoft 365 and Azure

There is no single reason; in many projects, we encounter several simultaneously.

Do not make “the cloud” the objective itself. The cloud is an architecture and an operating model. Objectives should be expressed in business terms. For example: Closing a data center by December 31st, reducing workplace-related incidents, achieving a four-hour RTO (Recovery Time Objective), consolidating three companies following an acquisition, or eliminating an unsupported platform. These objectives help determine which architecture makes sense.

Discovery: the phase that largely determines success

Migration issues rarely arise because a technician didn’t know how to click the “migrate” button. They occur because we discover something that wasn’t included in the inventory—and we discover it too late. In Microsoft 365: We need to identify, among other things:

In Azure or infrastructure: Simply creating an inventory of servers is not enough. We need to identify: CPU and memory, storage and IOPS, operating systems, databases, applications, ports, dependencies, connectivity, RTO/RPO, licensing, integrations, maintenance windows, technical owner, and business owner. An incomplete CMDB should not be considered a definitive inventory. It is advisable to cross-reference documented information with technical discovery. A server that does not appear in an Excel spreadsheet may still be receiving connections every single day.

What can be migrated to Microsoft 365

The destination should not be chosen solely based on technical similarity. For example, not every folder on a server should automatically be converted into a SharePoint library with the exact same structure. We must first identify the nature of the content.

Migrating email to Microsoft 365

Exchange Online is one of the most common entry points into Microsoft 365. The migration method depends fundamentally on the source.

Before moving mailboxes. Review: Primary SMTP, aliases, shared mailboxes, groups, delegations, permissions, calendars, rules, SMTP applications, size, archiving, and retention. DNS is part of the project. Email-related changes may affect: MX, SPF, DKIM, DMARC, Autodiscover, and applications that send email. Do not confuse migrating a mailbox with configuring all devices. The fact that the content is correctly located in Exchange Online does not necessarily mean that every personal device, application, or email client is automatically reconfigured.

Endpoint support must be explicitly defined within the project scope. Official reference: Microsoft – Ways to migrate mailboxes to Microsoft 365.

Migrating files to SharePoint and OneDrive

In a document migration, the copy speed is often only part of the challenge. We must first review the information. What to analyze.

SharePoint is not just a file server with a web interface. While some structure can be maintained, it is better to leverage features such as: sites, libraries, metadata, group-based permissions, versioning, co-authoring, and search. Applications that use UNC paths. If a program expects to find: \\SERVIDOR\Departamento\archivo.xml moving that file to SharePoint does not automatically make the application compatible with a cloud URL. Application dependencies must be identified before decommissioning the file server.

Microsoft Teams: migrating collaboration is more complex than just copying files

Microsoft Teams combines various services. A Team may depend on: Microsoft 365 Groups, SharePoint, Exchange, Teams, OneDrive, and other applications. That is why we must define the scope.

Do not promise a 1:1 migration without validating the tool. Especially regarding: chats, apps, bots, Loop, tabs, special channels, meetings.

Identity and devices: the migration that users actually notice

Identity design establishes which account each user will work with and which systems will continue to be involved in their authentication. The first decision is whether the environment needs to maintain a connection to an on-premises Active Directory or if identities can be managed entirely from the cloud. This choice impacts the lifecycle of user provisioning and deprovisioning, password management, application access, and incident recovery.

The login name and the primary email address should be reviewed separately, even if the decision is made to keep them the same for the sake of convenience. It is also necessary to verify applications that identify a user by their email address or by a directory identifier. Changing an account may require updating an integration or re-associating permissions; simply copying a mailbox does not automatically resolve these underlying relationships.

Devices require their own specific scope of work. A laptop might need to be re-enrolled, have Outlook reconfigured, and require the OneDrive client to be reconnected. If the device also receives certificates, Wi-Fi settings, or VPN configurations from a management platform, these services must be tested using the target identity. The project plan should specify how many devices will be handled and who will be responsible for resolving any issues that arise during the initial login.

Before the cutover, a pilot group should complete the entire workflow: logging in, successfully navigating the required authentication steps, accessing email, and using departmental applications. Administrative accounts and recovery procedures must also be tested. This ensures that a change in access does not leave the IT team unable to correct a policy or recover a user who is otherwise unable to work.

Microsoft 365 tenant-to-tenant migrations

Migrations between tenants typically occur during mergers, acquisitions, carve-outs, divestitures, consolidations, and internal reorganizations. Why they are particularly sensitive. When migrating from another system to Microsoft 365, the destination typically does not share the same identity restrictions. In a tenant-to-tenant migration, however, it does. We are dealing with two independent Microsoft 365 environments that may contain: users, Exchange, SharePoint, Teams, domains, security, and applications. The corporate domain is one of the primary cutover points.

A custom domain cannot be verified in two tenants simultaneously. This necessitates careful preparation of: UPNs, SMTP addresses, aliases, groups, MailUsers, DNS, and the cutover process. Coexistence is also required. If migrating in batches, users in both tenants must be able to continue collaborating for a period of time. Official reference: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.

Native cross-tenant tools from Microsoft in 2026

Microsoft has significantly expanded its native offerings. Cross-tenant mailbox migration. This allows for the movement of Exchange Online mailboxes between tenants. The target user must be properly prepared, and there is a specific identity mapping model in place. Cross-tenant OneDrive migration. This allows for moving a OneDrive instance from one tenant to another. There is one fundamental characteristic: it is a “one-and-done” move. It does not support the traditional pattern of: pre-migration, delta syncs, and a final delta sync.

After the move, a redirect is left at the source for compatible links. Cross-tenant SharePoint migration. Microsoft currently offers the capability to move SharePoint sites between tenants using SharePoint Online PowerShell. Current requirements include: identity mapping, pre-creation of users/groups, a compatible destination, ensuring the target site has not been pre-created, adhering to volume and item limits, and reviewing associated workflows, apps, and Power Platform components.

SharePoint moves do not support delta transfers. As with OneDrive, Microsoft defines this as a one-time move. Teams connected to SharePoint. It is possible to move the SharePoint site associated with a Team. However, this does not constitute a migration of the entire Team.The structure, channels, and specific content within Teams must be handled using the appropriate mechanisms. Migration Orchestrator. Microsoft also provides an orchestrated workflow to coordinate specific user workloads.

The Orchestrator moves content, not identities. Preparing users in the target tenant remains the responsibility of the project team. Official references:

• Microsoft – Migration Orchestrator
• Microsoft – Cross-tenant mailbox migration
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration

Coexistence during a phased migration

For small projects, a single cutover may be sufficient. For large projects, a period of coexistence—lasting days, weeks, or months—is often necessary. What might need to coexist:

Coexistence must have an expiration date. If the target state is a single tenant, maintaining the following for years: routing, guests, duplicate identities, cross-tenant permissions, duplicate licenses adds unnecessary cost and complexity.

What migrating to Azure entails

Migrating to Azure does not necessarily mean converting all your servers into Azure Virtual Machines. That is just one of the possible destinations. Examples.

Do not determine the destination based solely on compatibility. We must also consider: Operations, availability, security, cost, scalability, skills, and lifecycle.

The eight strategies for migrating to Azure

Microsoft currently uses a more comprehensive rationalization model, commonly referred to as the 8 Rs.

“Retire” is a strategy, not a failure. A migration is an excellent opportunity to discover servers that have spent years consuming: licenses, backups, antivirus, storage, and administration without providing any real value. “Retain” can also be the right choice. Not everything needs to be migrated immediately. A critical industrial application that functions correctly—and for which there is no business driver to change—can remain on-premises temporarily while other workloads are modernized.

“Rehost” does not fix a bad application. If a server already has performance, availability, or architectural issues, moving it to Azure “as-is” may simply carry those problems over—while also adding a cloud bill. “Replatforming” is often a good middle ground. It allows for a reduction in operational burden without necessarily requiring a complete rewrite. Official reference: Microsoft – Select your cloud migration strategy.

Azure Migrate: discovering and assessing before moving

Azure Migrate This is Microsoft’s suite of tools designed for the discovery, assessment, and migration of workloads to Azure. A modern assessment does more than just answer the question, “What VM do I need?” Microsoft evaluates aspects such as:

Rightsizing is particularly important. We should not assume that: VM on-premises 8 vCPU / 32 GB → Azure VM 8 vCPU / 32 GB is necessarily the correct approach. An over-provisioned on-premises server will remain over-provisioned if we copy the exact same configuration. Use actual performance data. Collecting metrics over a representative period helps determine: CPU, memory, storage, IOPS, and network. Dependency analysis. Before moving workloads, it is essential to understand which systems communicate with each other.

This helps in creating coherent migration groups. Official reference: Microsoft – Azure Migrate.

Dependencies are more important than the number of servers

Imagine we have: APP01 → SQL01 → FILE01 → LDAP01 → External API. If we migrate APP01 to Azure but leave SQL01 on-premises with insufficient connectivity, the application’s performance may degrade significantly, even if the server itself was migrated successfully. That is why we group by workload. A workload may include: front-end, API, database, file storage, identity, integrations, monitoring, backup, and networking. The unit of migration should not always be “a single server.”

It could be: an entire business application.

Cloud Adoption Framework: structuring the adoption of Azure

Microsoft has updated the Cloud Adoption Framework to clearly separate various areas of the adoption process. 1. Foundation.

2. Operational standards.

3. Workload onboarding.

Governance and security should not begin after migration. They should be in place before onboarding the first production workload. Official reference: Microsoft – Cloud Adoption Framework.

Azure Landing Zone: building the foundation before populating Azure Resources

A Azure Landing Zone provides a repeatable architecture for deploying and governing Azure at scale. Microsoft distinguishes between two components.

A Landing Zone can encompass: management groups, subscriptions, Azure Policy, RBAC, networking, connectivity, security, logging, monitoring, cost management, naming/tagging, and shared services. A common mistake. Creating the first VM in a subscription and thinking: “We’ll organize Azure later on.” Once fifty subscriptions and hundreds of resources are in place, correcting the structure becomes significantly more difficult. Official reference: Microsoft – Azure Landing Zones.

Security by design

Migration offers an opportunity to improve security, but it can also expand the attack surface if the cloud environment is enabled without defined controls. Microsoft 365.

Azure.

Do not deploy all restrictions on the day of the cutover. “Security by design” does not mean activating twenty new policies five minutes after migrating users. We need: design → pilot → report/monitor → remediate → enforce.

FinOps: managing cloud value, not just the bill

Azure uses an economic model that is very different from traditional hardware. We can create resources in minutes, but that also means we can incur costs in minutes. FinOps does not simply mean “reducing spending.” Its goal is to maximize the business value derived from the cloud. A workload that is cheap but slow, insecure, or unreliable is not necessarily a good optimization. Microsoft structures FinOps around collaboration.

The following should participate: technology, finance, and the business. Three operational stages.

First level of economic governance. At a minimum: consistent naming, tags, cost allocation, budgets, alerts, assigned owners, anomaly review, rightsizing, shutting down temporary resources, and using Azure Advisor. Do not purchase reservations before optimizing. This order is important. Microsoft recommends: Right-size first → eliminate waste → analyze stable consumption → then evaluate commitments. Reservations vs. Savings Plans.

Azure Hybrid Benefit. If the organization holds specific Windows Server or SQL Server license rights, it should check whether it can take advantage of the Azure Hybrid Benefit. Optimization is an ongoing process. A resource that is correctly sized on day one may no longer be correctly sized six months later. Official references:

• Microsoft – What is FinOps?
• Microsoft – FinOps Framework
• Microsoft – Cost Management

Migration as preparation for Microsoft 365 Copilot

Migrating information to Microsoft 365 can create an excellent foundation for Microsoft 365 Copilot. However, it may also bring to light long-standing governance issues. Copilot respects existing permissions. This means it does not automatically grant access to documents that the user could not previously consult. However, if a user already has access to information they arguably should not have, Copilot may make it easier for that information to surface within their work context.

The real issue is oversharing. Therefore, before deploying Copilot, it is advisable to review:

Content Management Assessment. Microsoft is incorporating specific capabilities into SharePoint Advanced Management to help assess: oversharing, inactive sites, sites without an owner, and readiness for Copilot and agents. Migrating everything “just in case” has consequences. If we copy twenty years’ worth of unclassified content—retaining its legacy permissions—we are creating an even larger information footprint that will subsequently need to be governed. Official reference: Microsoft – Prepare SharePoint for Microsoft 365 Copilot and agents.

Migrating data does not mean users have adopted Microsoft 365

A migration can be technically flawless and yet still yield a poor outcome. For instance, we might migrate a departmental folder to SharePoint, only for users to continue: downloading documents → sending them via email → creating duplicates. In that scenario, we have changed the platform, but not the way of working. Practical training. There is no need to turn every user into a Microsoft 365 administrator.

They should be taught what they need for their specific role.

Phased communication. A user should know: what is changing, when, what they need to do, and where to ask for help.

Which tool to use for each migration

There is no single tool that is the best for every project.

Native vs. third-party. Native tools can be a good option when: the workload is supported, the cutover model fits, and no additional capabilities are required. A specialized tool may make sense when you need: more reporting, advanced coexistence, delta synchronization, remapping, automation, or support for content not covered by the native tool. Choose the tool after the assessment. Not the other way around.

Recommended phases for a cloud migration

Phase 1: Objectives. Define: the problem being solved, target date, constraints, and success criteria. Phase 2: Discovery. Inventory identity, data, applications, servers, dependencies, and security. Phase 3: Assessment. Classify: migrate, modernize, retain, retire, replace. Phase 4: Target architecture. Design: Microsoft 365, Entra, SharePoint, Teams, Intune, Azure Landing Zone, networking, security, monitoring, and FinOps. Phase 5: Preparation. Create: Identities, licenses, networking, subscriptions, policies, tools, and permissions.

Phase 6: Pilot. Select representative users and workloads. Do not choose only the easiest ones. Phase 7: Pre-migration. When the tool allows, move a significant portion of the data before the cutover. Phase 8: Waves. Group users or applications based on: Department, country, organizational unit, criticality, schedule. Phase 9: Cutover. Implement final changes. This includes: DNS, domain, mail routing, identity, applications, network routes, and failover.

Phase 10: Validation. Validate content, functionality, permissions, and user experience. Phase 11: Stabilization. Resolve incidents and monitor the environment during the agreed-upon period. Phase 12: Decommission. Remove: Servers, licenses, connectors, accounts, temporary rules, tenants, or source systems when it is safe to do so.

How to properly validate a migration

“The job appears as ‘Completed’” should not be the only success criterion. Quantitative validation.

Technical validation. Check for: errors, omitted objects, permissions, version history, links, authentication, networking, backup, and monitoring. Functional validation. This is the most important aspect. Users must be able to perform their work. Example. An application might respond to a ping and still fail to function because: the API fails to connect, the printer is unavailable, the SQL database has latency, or the certificate has changed.

Rollback: knowing when to stop

Not all migrations allow for a complete rollback. Therefore, before making any changes, we must define: what can be reverted, up to what point in time, and with what impact. Examples.

Define “go/no-go” criteria. For example: if 5% of pilot users encounter a critical issue → do not proceed with the next wave.

After migration, a new phase begins: operations

A cloud environment requires an operating model. Microsoft 365. Define ownership for: users, groups, Teams, SharePoint, guests, Conditional Access, Intune, Defender, and Purview. Azure. Define ownership for: subscriptions, networking, security, backup, monitoring, patching, costs, incidents, DR (disaster recovery), and platform services. Infrastructure as Code (IaC). For repeatable and governed Azure environments, it is worth using IaC whenever the operating model allows it.

Documentation. A migration should conclude with: architecture, inventory, procedures, permissions, owners, runbooks, and known exceptions.

Metrics to determine if a migration was successful

Common mistakes when migrating to Microsoft 365 and Azure

Comprehensive pre-migration checklist

Frequently asked questions about migrations to Microsoft 365 and Azure

Should Microsoft 365 and Azure be migrated at the same time?

This is not a general requirement. The sequence depends on the relationships between identities, applications, data, and services. It may be simpler to migrate email first, followed by an application, or to prepare connectivity and identity beforehand. Each phase should include its own testing, while ensuring that components the business still relies on remain operational.

What information is needed to budget for a cloud migration?

You need to account for users, services, data, applications, infrastructure and operational constraints. The destination, the devices covered by support and the acceptance tests must also be defined. A budget based only on mailbox or server counts overlooks work such as correcting permissions, adapting integrations and supporting users through an identity change.

Does moving an application to an Azure virtual machine constitute modernization?

Moving infrastructure changes where an application runs, but it does not automatically fix its architecture, dependencies, or support model. This can be a valid first step, provided it is justified. True modernization requires a separate assessment of which components can be adapted or replaced, along with a plan to verify that the necessary functionality is maintained.

When can the legacy environment be decommissioned?

The source environment should be decommissioned only after services have been validated, dependencies relying on it have been resolved, and an agreement has been reached regarding the retention of any necessary data. Furthermore, support for the target environment must be fully operational. Before shutting down the legacy system, it is advisable to verify applications, scheduled tasks, integrations, and recovery processes; the mere completion of a data copy does not guarantee that all these elements no longer depend on the original system.

Final recommendations: migrating to the cloud is not just about moving servers and mailboxes; it is about deciding how you want to operate afterward

A Migration to Microsoft 365 and Azure A migration may begin with a very specific technical need—such as replacing Exchange, closing a data center, migrating an acquired tenant, or decommissioning an old server. However, the quality of the project depends on looking beyond the mere movement of data. In Microsoft 365, you must determine the appropriate destination for each type of information. Personal documents serve a different purpose than departmental documents; Exchange has different dependencies than Teams; and a tenant-to-tenant migration requires special attention to identity, domains, and coexistence.

Microsoft has significantly expanded its native cross-tenant capabilities, offering specific tools for Exchange, OneDrive, and SharePoint, as well as the Migration Orchestrator for certain user workloads. Even so, each workload has its own unique requirements, and there is no single operation capable of automatically transforming an entire tenant into an identical copy. The same applies to Azure: the question should not just be where to host each server, but rather which strategy makes the most sense for that specific workload.

Microsoft’s eight current strategies—Retire, Retain, Rehost, Replatform, Refactor, Rearchitect, Rebuild, and Replace—allow for tailored decisions for each application. While Azure Migrate can assist in discovering your environment and evaluating readiness, performance, sizing, and costs, a technical assessment must be complemented by business context. Furthermore, you need a solid foundation before onboarding workloads. The Cloud Adoption Framework and Azure Landing Zones provide a model for structuring identity, subscriptions, governance, networking, security, monitoring, and operations—helping to prevent the environment from growing in an uncontrolled manner.

The same applies to costs. FinOps should not be introduced only after an unexpected bill arrives six months down the line. Cost allocation, tagging, budgeting, rightsizing, and accountability should be integrated into the architecture from the very beginning. Additionally, artificial intelligence provides yet another compelling reason to ensure your data is well-organized. Microsoft 365 Copilot uses existing permissions. If SharePoint and OneDrive are properly governed, that works in our favor. If we have carried over years of overshared, unowned, and unclassified content, we will need to address that issue either before or during the adoption of Copilot.

A well-designed migration should, therefore, result in more than just having your data in a new destination. It should result in: fewer unnecessary systems, a well-understood architecture, organized identities, better-placed data, defined security, managed costs, clear ownership, and a defined operational model for the environment post-project. That is the true objective.

Recommended official documentation

Microsoft 365 Migration.

• Microsoft – Microsoft 365 migration overview
• Microsoft – Exchange mailbox migration
• Microsoft – File share to SharePoint and OneDrive migration

Tenant-to-tenant.

• Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
• Microsoft – Migration Orchestrator
• Microsoft – Cross-tenant mailbox migration
• Microsoft – Cross-tenant OneDrive migration
• Microsoft – Cross-tenant SharePoint migration

Azure Cloud Adoption Framework.

• Microsoft – Cloud Adoption Framework
• Microsoft – Select cloud migration strategies
• Microsoft – Execute a cloud migration

Azure Landing Zones.

• Microsoft – Azure Landing Zone
• Microsoft – Azure Landing Zone design areas

Azure Migrate.

• Microsoft – Azure Migrate documentation
• Microsoft – Azure Migrate assessments
• Microsoft – Azure Migrate discovery

FinOps and Azure costs.

• Microsoft – What is FinOps?
• Microsoft – FinOps Framework
• Microsoft – Azure Cost Management
• Microsoft – Savings Plans vs. Reservations

Microsoft 365 Copilot and data governance.

• Microsoft – Security for Microsoft 365 Copilot
• Microsoft – Prepare SharePoint for Copilot and agents
• Microsoft – Microsoft 365 Copilot data protection architecture
• Microsoft – Purview for Microsoft 365 Copilot

Endpoint and security.

• Microsoft – Microsoft Intune
• Microsoft – Conditional Access
• Microsoft – Defender for Office 365