Complete Microsoft 365 migration guide: steps, costs, risks, security and checklist to move without losing data

Quick summary: Microsoft 365 migration in 15 points

1. Do not start with the tool: start with the assessment. First you need to know what will be migrated, how much space it uses, who uses it and what risks it has.
2. Define the real scope: email, calendars, contacts, files, Teams, users, groups, devices, applications, permissions, DNS and security.
3. Email is the most visible part: if Outlook does not work on day one, users will feel the whole project has failed.
4. IMAP does not migrate everything: it is useful for email and folders, but not for calendars, contacts, tasks, rules or signatures.
5. OneDrive does not replace SharePoint: OneDrive is for personal work files; SharePoint is for information shared by teams or departments.
6. Teams needs governance: if deployed without rules, duplicate teams, empty channels and scattered files appear.
7. Identity rules everything: UPN, aliases, groups, roles, MFA and Conditional Access must be defined before cutover.
8. DNS is critical: MX, SPF, DKIM, DMARC and Autodiscover must be prepared and tested before the final change.
9. Security must be enabled from the start: MFA, legacy authentication blocking, Defender, sharing policies and auditing.
10. Not all users need the same licence: combining plans by profile can reduce costs without losing security.
11. Power Platform can break: flows, connectors and apps depend on accounts, permissions and paths that may change.
12. Intune improves control: especially when there are laptops, mobile devices, BYOD or remote access to sensitive information.
13. Communication prevents tickets: users need brief instructions, not a twenty-page technical document.
14. A real pilot is worth more than many assumptions: it must include users with email, files, mobile access, permissions and real business cases.
15. The migration ends when the business validates it: not when the tool says “completed”.

Who is this guide for?

This guide is intended for IT managers, executives, general managers, operations managers and teams who need to make decisions about a Microsoft 365 migration. It is not just a technical guide: it also explains the business decisions that should be made before moving data.

You will find it useful if…

• Your company wants to move away from an old mail server or IMAP hosting.
• You want to migrate from Google Workspace, Zoho or another productivity suite.
• You have files scattered across a file server, NAS, Dropbox, Google Drive or local folders.
• You want to implement Teams in an organised way, not as “just another tool”.
• You need to improve security with MFA, Conditional Access, Defender, Intune or Purview.
• You want to estimate effort, cost, risks and timelines before starting.
• You need to justify internally why it is worth working with a specialised partner.

When does it make sense to migrate to Microsoft 365?

The decision to migrate usually appears when the current environment starts to fall short: lack of security, too many tools, remote access issues, ageing servers, limited traceability, duplicate files or users each working “their own way”.

Common reasons to migrate

• Unstable or limited email: small mailboxes, lack of anti-phishing, poor mobile experience or deliverability issues.
• Too many scattered tools: email with one provider, files with another, meetings on another platform and local documents.
• Hybrid or remote work: the need to access information securely from anywhere.
• On-premises servers reaching end of life: Exchange, file servers or infrastructure that is no longer worth maintaining.
• Company growth: more users, more offices, more collaboration and a greater need for governance.
• Mergers or reorganisations: unifying domains, users and data in a common platform.
• Insufficient security: no MFA, weak passwords, uncontrolled external access or limited auditing.
• Compliance requirements: retention, eDiscovery, DLP, information classification or audits.
• Teams adoption: centralising meetings, chat, documents and collaboration in an integrated experience.

When it is better to wait

Rushed migrations rarely go well. It may be better to wait or prepare the project more thoroughly if there is no inventory, if the domain is poorly documented, if there are critical applications without an owner, if nobody knows what permissions exist on the file server or if management has not approved a change window.

Where companies usually migrate to Microsoft 365 from

Not all migrations start from the same place. The source environment determines the method, the tool, the risks and the effort.

Introduction: migrating to Microsoft 365 is a business project

A Microsoft 365 migration is often sold as a technical project, but the real impact is felt by the business. If email fails, sales stops. If permissions are migrated incorrectly, finance is exposed. If users do not understand Teams, they go back to email and attachments. If SharePoint is designed as a folder dump, nobody finds anything.

That is why the migration should be approached as a cross-functional project. IT executes and coordinates, but the business must validate which information is critical, who can access what, which processes depend on email, which folders are archived and which users require special support.

1. Key decisions before getting started

In practice: the important decisions are made before migrating. After cutover, every unanswered question becomes an incident.

Questions that should be answered in writing

• Which workloads will be migrated: email, files, Teams, devices, applications?
• Who approves the domain change?
• Which users are considered critical?
• Which information should not be migrated because it is obsolete?
• Which data requires retention or compliance?
• Who decides permissions in SharePoint?
• What level of support will be available on cutover day?
• When can the old environment be retired?

2. Recommended methodology: from assessment to stabilisation

In practice: an organised migration is divided into phases. Each phase has deliverables, owners and exit criteria.

2.1 Discovery and assessment

Technical and functional information is collected. Counting users is not enough: you need to understand mailboxes, calendars, permissions, files, devices, applications and dependencies. This phase makes it possible to estimate effort, risks and the tools required.

2.2 Target design

The future Microsoft 365 environment is defined: licences, users, groups, domains, security policies, Teams, SharePoint sites, OneDrive structure, retention and support model.

2.3 Tenant preparation

The environment is configured: domains, users, licences, groups, Exchange Online, OneDrive, SharePoint, Teams, baseline security, administrative roles and initial policies.

2.4 Pilot

Representative users are migrated. The pilot must test email, Outlook, mobile, files, Teams, MFA, permissions and real processes. A pilot with “easy” users is not useful for detecting problems.

2.5 Pre-stage and waves

Data is migrated before the final cutover to reduce timings. For email, initial and incremental synchronisation can be performed. For files, pre-loads can be executed and changes synchronised before the final window.

2.6 Controlled cutover

DNS is updated, mail flow is changed, services are validated and users are informed. There must be owners, a checklist and a rollback plan.

2.7 Stabilisation

Incidents, permissions, access, adoption, security and user experience are reviewed. This phase is essential to close the project properly and avoid leaving a long list of “pending items”.

3. Roles and responsibilities: who decides what

In practice: many delays are not technical; they are decision-related. That is why roles should be defined from the beginning.

The migration should have a short and operational committee. A long meeting every day is not necessary, but there must be a clear channel for decisions: approving windows, resolving exceptions, prioritising incidents and deciding whether to proceed or postpone a cutover.

4. Assessment: technical and functional inventory

In practice: the assessment prevents surprises. Every item that is not reviewed beforehand can become an incident later.

4.1 Email inventory

• Active and inactive user mailboxes.
• Shared mailboxes.
• Resource mailboxes: rooms, equipment, shared calendars.
• Aliases and secondary addresses.
• Distribution lists and groups.
• Transport rules.
• SMTP connectors.
• Automatic forwarding.
• Delegated permissions: Full Access, Send As, Send on Behalf.
• Mailbox size and number of items.
• Critical calendars and shared calendars.
• Clients used: Outlook, webmail, mobile, third-party apps.

4.2 File inventory

• Source repositories: file server, NAS, Google Drive, Dropbox, Zoho WorkDrive, Box or others.
• Total volume and estimated growth.
• Number of files and folders.
• Long paths.
• Unsupported or problematic names.
• Duplicates.
• Inherited permissions.
• Folders without a clear owner.
• Obsolete or historical data.
• Sensitive information: personal data, payroll, contracts, financial data.
• External links.
• Retention or archive needs.

4.3 Identity inventory

• Current users.
• External users or guests.
• Security groups.
• Distribution groups.
• Administrative roles.
• Current UPN and desired UPN.
• Verified domains.
• Applications with SSO.
• Service accounts.
• On-premises Active Directory, if any.
• Need for synchronisation with Entra ID.

4.4 Device inventory

• Corporate laptops.
• Shared computers.
• Corporate mobile devices.
• BYOD.
• Windows, macOS, iOS and Android versions.
• Current antivirus.
• Disk encryption.
• Need for VPN.
• Installed applications.
• Email profiles on mobile devices.

4.5 Application and automation inventory

• Applications that send email via SMTP.
• ERP, CRM, billing or ticketing software.
• Power Automate flows.
• Power Apps.
• Power BI reports.
• Data gateways.
• Connectors with SharePoint, Exchange, SQL or external services.
• Internal scripts.
• Applications registered in Entra ID.

5. Microsoft 365 licences: how to choose without overpaying

In practice: well-designed licensing can save costs and avoid limitations. The typical mistake is giving everyone the same licence without analysing profiles.

The licence should not be chosen on price alone. It should answer a simple question: what does this user need to do, and what level of security is required? An administrative user, a sales representative, a field technician and an executive do not have the same needs.

Common mistakes when choosing licences

• Buying the cheapest plan and later discovering that device management or security is missing.
• Buying the highest plan for everyone without analysing profiles.
• Not reserving licences for shared mailboxes that actually need a licence for advanced features.
• Not planning for storage growth.
• Not considering Defender, Intune or Purview from the design stage.
• Not reviewing add-ons needed for telephony, audio conferencing, compliance or security.

Related service: Business licence supply and sales.

6. Preparing the Microsoft 365 tenant

In practice: the tenant must be ready before migration. If it is configured on the fly, permission, licence, DNS and security errors appear.

Elements to prepare

• Tenant created and administrators defined.
• Corporate domain verified.
• Users created or synchronised.
• Licences assigned.
• Exchange Online prepared.
• OneDrive provisioned for users.
• Base SharePoint sites created.
• Teams configured with minimum policies.
• MFA and Conditional Access defined.
• External sharing policy reviewed.
• Administrative roles assigned with least privilege.
• Emergency accounts documented.
• Auditing enabled.

Best practices for administrators

• Do not use personal daily-work accounts for global administration.
• Assign specific roles instead of giving Global Admin to the whole team.
• Protect administrators with strong MFA.
• Record relevant changes during the migration.
• Document initial configurations.

7. Identity with Microsoft Entra ID

In practice: identity is the foundation of Microsoft 365. If the user cannot sign in properly, nothing else matters.

Microsoft Entra ID manages sign-in, users, groups, roles, applications, MFA and Conditional Access. In a migration, it defines who each user is, how they sign in, what permissions they have and where they can access from.

Cloud-only model

In a cloud-only model, users are managed directly in Microsoft 365 / Entra ID. It is simpler and usually fits companies without on-premises Active Directory or those that want to reduce dependency on internal servers.

Hybrid model with Active Directory

If on-premises Active Directory exists and remains important for applications, devices or internal authentication, it may be necessary to synchronise identities with Entra ID. This requires reviewing UPNs, attributes, OUs, groups, passwords and the user lifecycle.

Identity checklist

• Define the final UPN.
• Review domains and aliases.
• Remove duplicates.
• Create groups by role and department.
• Define administrators and roles.
• Apply MFA.
• Create Conditional Access policies.
• Review enterprise applications.
• Document service accounts.
• Define the joiner, mover and leaver lifecycle.

8. Migrating email to Exchange Online

In practice: email is the most sensitive part because it affects everyone. The goal is for users to open Outlook and keep working.

Exchange Online is Microsoft 365’s business email service. It provides cloud mailboxes, calendars, rules, shared mailboxes, lists, email protection and centralised administration. The migration method depends on the source environment.

8.1 IMAP migration

IMAP migration is used when the source is an IMAP-compatible email system: traditional hosting, some legacy servers, Zoho Mail or other providers. It is useful for moving messages and folders, but it does not migrate calendars, contacts, tasks, rules or signatures.

• Advantage: simple and compatible with many source environments.
• Limitation: email and folders only.
• When to use it: when the source is not Exchange or Google and the goal is to migrate basic email.

8.2 Cutover migration

A cutover migration moves all mailboxes in a single or highly concentrated window. It can work in small and controlled environments, but it requires impeccable preparation.

8.3 Staged migration

A staged migration allows users to be moved in phases. It reduces pressure, but requires coexistence and good communication. It is useful when the whole company should not be changed at once.

8.4 Hybrid migration

Hybrid migration fits when on-premises Exchange will coexist with Exchange Online for a period of time. It provides advanced coexistence, but also more complexity: certificates, connectors, Autodiscover, directory and mail flow.

8.5 Third-party tools

Tools such as BitTitan, Quest, Cloudiway and others can help when there are multiple sources, reporting requirements, tight deadlines or complex scenarios.

Email checklist

• Mailbox inventory.
• Mailbox size and online archive.
• Shared mailbox review.
• Delegated permissions.
• Aliases and domains.
• Transport rules.
• SMTP connectors.
• Applications that send email.
• Critical users.
• Selected migration method.
• Pilot test.
• Pre-synchronisation.
• DNS cutover plan.
• Send and receive tests.
• Outlook and mobile reconfiguration.

Connect-ExchangeOnline

Get-MigrationBatch |
  Select-Object Name,Status,TotalCount,ActiveCount,StoppedCount,FailedCount

Get-MigrationUser |
  Get-MigrationUserStatistics -IncludeReport |
  Select-Object Identity,Status,PercentComplete,ItemsTransferred,BytesTransferred,ErrorSummary |
  Export-Csv ".\exchange-migration-status.csv" -NoTypeInformation -Encoding UTF8

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
  Get-EXOMailboxStatistics |
  Select-Object DisplayName,TotalItemSize,ItemCount,LastLogonTime |
  Export-Csv ".\mailbox-sizes.csv" -NoTypeInformation -Encoding UTF8

9. Calendars, contacts, rules and signatures

In practice: these elements seem secondary until they are missing. For users, their calendar and contacts are an essential part of email.

Calendars

Calendars must be reviewed with special care when there are recurring meetings, rooms, shared calendars, delegations or users who organise many external meetings. Depending on the source and migration method, it may be necessary to export/import calendars or recreate specific meetings.

Contacts

Personal contacts, shared contacts and corporate lists are not the same thing. Before migrating, it is useful to decide which contacts go into the user’s mailbox, which should be organisational contacts and which belong in a CRM.

Rules

Email rules can be useful, but they can also be dangerous. During a migration, old rules appear that forward email, move messages or depend on folders that change. They should be reviewed and rules that no longer make sense should be cleaned up.

Signatures

Signatures are not always migrated automatically. If the company wants a standard corporate signature, the migration is a good time to standardise it.

Specific checklist

• Identify shared calendars.
• Review calendar delegations.
• Validate rooms and resources.
• Export/import contacts if the method does not migrate them.
• Review forwarding rules.
• Document corporate signatures.
• Test users with high calendar activity.

10. Migrating files to OneDrive and SharePoint

In practice: file migration is not about uploading folders. It is about deciding where information should live and who should access it.

OneDrive and SharePoint are not the same. One of the most common mistakes is putting everything in OneDrive because it seems faster, or copying an entire file server into a single SharePoint site. This usually creates confusion, poorly designed permissions and low adoption.

Correct destination

• OneDrive: personal work files, drafts, documents that do not yet belong to a team.
• SharePoint: area, department, process, client, project or corporate knowledge documentation.
• Teams: daily collaboration associated with a working group. Teams files are stored in SharePoint.

What to review before migrating

• Total volume.
• Number of files.
• File types.
• Long paths.
• Unsupported names.
• Inherited permissions.
• Folders without an owner.
• Duplicate content.
• Obsolete content.
• Sensitive data.
• External links.
• Need for metadata.

Common tools

• Migration Manager: useful for migrating file shares and other sources to Microsoft 365.
• SharePoint Migration Tool: Microsoft’s tool for migrating content from SharePoint Server and file shares to Microsoft 365.
• Third-party tools: useful for complex permissions, reporting, reorganisation or multiple sources.

11. SharePoint design: structure, permissions and governance

In practice: SharePoint works very well when it is designed; it works poorly when used as a giant folder drawer.

Design principles

• Create sites by area, process or stable project.
• Avoid a single library for the whole company.
• Use groups instead of user-by-user permissions.
• Define site owners.
• Separate active documentation from historical documentation.
• Avoid overly deep permission inheritance.
• Use metadata when it adds value, not because it is fashionable.
• Define external sharing rules.

Basic site model

Recommended minimum governance

• Site creation policy.
• Site and Teams naming convention.
• Mandatory owners.
• Periodic permission review.
• External sharing rules.
• Retention by information type.
• Library and metadata templates.

12. Microsoft Teams: deployment, migration and adoption

In practice: Teams can organise collaboration or multiply chaos. It depends on governance.

Teams is not just a chat tool. Each team can have members, owners, channels, files, tabs, applications, meetings, recordings and connections to SharePoint. That is why it is important to define a strategy before deploying or migrating it.

What to decide before using Teams

• Who can create teams.
• How teams are named.
• When to use chat and when to use a channel.
• Which channels are created by default.
• How guests are managed.
• When a team is archived.
• Which apps are allowed.
• How Planner, OneNote, SharePoint or Power BI are integrated.

Recommended team types

Common mistakes in Teams

• Creating too many teams without a clear purpose.
• Not assigning owners.
• Using chats for decisions that should be in channels.
• Uploading files to chat instead of using team libraries.
• Not managing guests.
• Not training users on the difference between Teams, SharePoint and OneDrive.

13. Power Platform, Power BI and connected applications

In practice: a migration can stop working even if email is perfect when flows, connectors or reports break.

Many companies have small automations that nobody considers “critical” until they fail: approvals, email alerts, forms, reports, integrations with SharePoint or exports to Excel. During a migration, these pieces must be reviewed.

What to inventory

• Power Automate flows.
• Power Apps.
• SharePoint lists used by apps.
• Connectors with Outlook, SharePoint, SQL, ERP or CRM.
• Owner accounts of flows.
• Data gateways.
• Power BI workspaces.
• Datasets and credentials.
• Applications registered in Entra ID.

Best practices

• Avoid having a critical flow depend on a personal account.
• Assign co-owners.
• Document connectors and permissions.
• Test flows with business users.
• Review credentials after the migration.
• Separate development, testing and production when applicable.

14. Devices, Intune and first-day experience

In practice: for the user, the migration comes down to whether their laptop and mobile work.

Microsoft Intune enables device, application, compliance policy and corporate data access management. In a Microsoft 365 migration, Intune is especially important when there is remote work, mobile access, BYOD or a need to control access by device.

Device scenarios

• Corporate Windows devices: can be managed with Intune and, where applicable, Autopilot.
• Personal computers: application management can be applied without controlling the entire device.
• Corporate mobile devices: full device management.
• BYOD: protection of corporate data in applications such as Outlook and Teams.
• Shared computers: require specific profiles and policies.

Intune checklist

• Device inventory.
• Compliance policies.
• Configuration profiles.
• Required applications.
• App protection policies.
• Encryption requirements.
• Windows Autopilot where applicable.
• User enrolment guide.
• Testing with pilot users.

15. DNS: MX, SPF, DKIM, DMARC and Autodiscover

In practice: the DNS change is the moment when the world starts sending email to Microsoft 365. Everything must be ready by then.

To connect a domain to Microsoft 365, you must verify ownership and add the required records. Microsoft recommends creating users and mailboxes before updating the MX record to avoid interruptions in mail delivery.

# MX to Exchange Online Protection
MX @ 0 company-com.mail.protection.outlook.com

# SPF
TXT @ "v=spf1 include:spf.protection.outlook.com -all"

# DKIM (the specific values are generated by Microsoft 365)
CNAME selector1._domainkey selector1-company-com._domainkey.company.onmicrosoft.com
CNAME selector2._domainkey selector2-company-com._domainkey.company.onmicrosoft.com

# Initial DMARC in monitoring mode
TXT _dmarc "v=DMARC1; p=none; rua=mailto:dmarc@company.com"

# Autodiscover
CNAME autodiscover autodiscover.outlook.com

Common DNS mistakes

• Changing MX before mailboxes are ready.
• Not including all legitimate senders in SPF.
• Enabling strict DMARC without reviewing reports.
• Not configuring DKIM.
• Forgetting Autodiscover.
• Not documenting previous records.

16. Security and compliance in Microsoft 365

In practice: a migration is the best time to raise the security level. Later, it is harder to change habits and close exceptions.

Recommended minimum controls

• MFA for all users.
• Strong MFA for administrators.
• Conditional Access to control access by location, device, risk and application.
• Legacy authentication blocking when it is not needed.
• Defender for Office 365 for Safe Links, Safe Attachments and anti-phishing.
• SPF, DKIM and DMARC for email authentication.
• External sharing policies in SharePoint and OneDrive.
• Auditing and administrative role review.
• Retention policies for critical information.
• DLP to prevent sensitive information leakage.

Conditional Access: baseline policies

• MFA for all users.
• Block legacy authentication.
• Mandatory MFA for administrators.
• Block or control unexpected countries.
• Require compliant devices for sensitive data.
• Session control for critical applications.

Defender for Office 365

Defender for Office 365 adds protection against email and collaboration threats. Safe Links helps protect against malicious links and Safe Attachments analyses attachments in a safe environment before delivering them according to the configured policy.

17. Data governance: retention, DLP, labels and eDiscovery

In practice: migrating data without governance only moves the risk to another platform.

Retention

Retention policies allow information to be preserved or deleted according to business, legal or regulatory criteria. They should be defined before SharePoint and Exchange begin growing without control.

DLP

Data loss prevention policies help detect and control sensitive information, such as personal, financial or confidential data, in email, SharePoint, OneDrive and Teams.

Sensitivity labels

Labels allow documents and emails to be classified as public, internal, confidential or restricted. They can apply encryption, visual markings or access restrictions.

eDiscovery

eDiscovery makes it possible to search, preserve and export information in legal or audit scenarios. If the company has regulatory requirements, it must be included in the design.

18. User communication and adoption

In practice: adoption cannot be improvised on cutover day. If users do not understand the change, they will experience it as a problem.

What to communicate

• Why the migration is happening.
• What changes and what does not change.
• When the change will take place.
• How to access Microsoft 365.
• How to use Outlook.
• How to set up mobile access.
• Where files will be.
• How to use Teams.
• How to approve MFA.
• Where to request support.

Recommended guides

• First access to Microsoft 365.
• Quick Outlook guide.
• Quick Teams guide.
• How to find files in OneDrive and SharePoint.
• How to share documents securely.
• How to configure Outlook on mobile.
• What to do if MFA does not work.

19. Microsoft 365 migration costs

In practice: cost depends less on the number of users than it may seem, and more on the complexity of the environment.

Factors that affect cost

• Number of users.
• Mailbox size.
• Number of shared mailboxes.
• Email source.
• File volume.
• Permission complexity.
• Number of sites and Teams.
• Need for third-party tools.
• Required security and compliance.
• Devices to manage.
• Power Platform and integrations.
• Support and training.
• Out-of-hours work windows.

How to avoid extra costs

• Perform assessment before contracting tools.
• Clean data before migrating.
• Do not migrate obsolete content.
• Group users into intelligent waves.
• Choose licences by profile.
• Automate inventory and validations.
• Avoid scope changes in the middle of cutover.

20. Project, quality and adoption KPIs

In practice: a migration without metrics is managed by feelings. And feelings usually arrive late.

21. Common risks and how to mitigate them

22. Operational checklists

22.1 Pre-migration checklist

• Domain verified in Microsoft 365.
• Users created or synchronised.
• Licences assigned.
• Pilot users selected.
• MFA prepared.
• Conditional Access designed.
• Mailbox inventory.
• File inventory.
• Application inventory.
• DNS plan prepared.
• Communication plan prepared.
• Rollback plan written.

22.2 Email checklist

• Migration method selected.
• Migration endpoint validated.
• Target mailboxes created.
• Pilot test completed.
• Batches defined.
• Errors reviewed.
• Calendars validated.
• Shared mailboxes reviewed.
• Outlook and mobile tested.

22.3 File checklist

• Source identified.
• Destination defined: OneDrive, SharePoint or Teams.
• Permissions reviewed.
• Obsolete content separated.
• Long paths reviewed.
• User owners defined.
• Pilot migration executed.
• Access validation completed.

22.4 Cutover-day checklist

• Support team available.
• Communication sent.
• Final synchronisation reviewed.
• DNS prepared.
• Rollback plan available.
• Critical users informed.
• Send and receive tests ready.
• Incident log open.

22.5 Post-migration checklist

• Email validated.
• Outlook validated.
• Mobile devices validated.
• Critical files validated.
• Teams validated.
• Permissions reviewed.
• Security reviewed.
• Recurring incidents analysed.
• Documentation updated.
• Source retired or moved to read-only when safe.

23. Useful snippets and scripts

In practice: scripts help with inventory, validation and control, but they must be tested in the pilot first.

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
  Select-Object DisplayName,UserPrincipalName,PrimarySmtpAddress,RecipientTypeDetails |
  Export-Csv ".\mailbox-inventory.csv" -NoTypeInformation -Encoding UTF8

Get-MigrationBatch |
  Select-Object Name,Status,TotalCount,FailedCount

Get-MigrationUser |
  Get-MigrationUserStatistics -IncludeReport |
  Select-Object Identity,Status,PercentComplete,ItemsTransferred,ErrorSummary |
  Export-Csv ".\migration-status.csv" -NoTypeInformation -Encoding UTF8

Get-CASMailbox -ResultSize Unlimited |
  Set-CASMailbox -ImapEnabled:$false -PopEnabled:$false

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 ".\users.csv" -NoTypeInformation -Encoding UTF8

Connect-SPOService -Url "https://tenant-admin.sharepoint.com"

Get-SPOSite -Limit All |
  Select-Object Url,Owner,Template,StorageUsageCurrent,LastContentModifiedDate |
  Export-Csv ".\sharepoint-sites.csv" -NoTypeInformation -Encoding UTF8

Connect-MicrosoftTeams

Get-Team |
  Select-Object GroupId,DisplayName,Visibility,Archived |
  Export-Csv ".\teams-inventory.csv" -NoTypeInformation -Encoding UTF8

EmailAddress
ana.perez@company.com
juan.garcia@company.com
support@company.com

24. Communication and go/no-go templates

Pre-migration communication: project announcement

Subject: Upcoming migration to Microsoft 365

Hello,

We are going to migrate our email, file and collaboration tools to Microsoft 365. The goal is to work more securely, improve collaboration and organise access to information.

You do not need to do anything yet. We will send simple instructions before the change.

Thank you,
IT Team

Instruction communication

Subject: Instructions for the move to Microsoft 365

Hello,

During the migration window, your email will be moved to Microsoft 365. When we notify you, you will need to open Outlook, sign in with your corporate account and approve MFA if requested.

You will also have access to Teams, OneDrive and SharePoint. If you need help, support will be available through the usual channels.

Thank you,
IT Team

Cutover-day communication

Subject: We are moving to Microsoft 365

Hello,

We are carrying out the change of email and services to Microsoft 365. There may be brief interruptions or sign-in requests during the transition.

If you need help, please contact support. We will notify you when validation has been completed.

Thank you for your patience,
IT Team

Go/No-Go: review points

• Target users created and licensed.
• Final synchronisation reviewed.
• Critical errors resolved.
• DNS prepared.
• Support available.
• Communication sent.
• Rollback plan prepared.
• Business informed.

25. Rollback and contingency plan

In practice: rollback should not be improvised when something fails. It must exist before cutover.

When to activate contingency

• Email is not being received or sent.
• Critical users cannot access services.
• The error rate exceeds the agreed threshold.
• DNS does not behave as expected.
• The migration tool returns widespread errors.
• There is not enough time to validate before business hours.

What the plan should include

• Decision owner.
• Steps to pause batches.
• Previous DNS records documented.
• Procedure to temporarily return to the source where applicable.
• User communication message.
• Validations after rollback.
• Root cause analysis before retrying.

26. What to do after migrating

In practice: the project does not end on cutover day. The following week often determines how users perceive the migration.

Post-migration actions

• Review repeated incidents.
• Validate shared mailboxes and calendars.
• Review SharePoint permissions.
• Recertify external access.
• Check security policies.
• Review Teams adoption.
• Remove temporary rules.
• Disable legacy protocols if they are no longer needed.
• Update documentation.
• Retire or archive the old system in a controlled way.

Recommended improvements after stabilisation

• Implement sensitivity labels.
• Enable DLP in phases.
• Review Secure Score.
• Implement Intune if it was not included.
• Optimise Teams and SharePoint.
• Train internal champions.
• Review licences after real usage.

27. Frequently asked questions about Microsoft 365 migration

28. Official resources and external links

Official Microsoft documentation

• Ways to migrate email to Microsoft 365
• Best practices and performance for Exchange Online migrations
• IMAP migration to Microsoft 365
• Migration Manager for migrating file shares to Microsoft 365
• SharePoint Migration Tool
• Connect a domain to Microsoft 365 with DNS records
• External DNS records for Microsoft 365
• Email authentication: SPF, DKIM and DMARC
• Conditional Access in Microsoft Entra
• Safe Links in Defender for Office 365
• Safe Attachments in Defender for Office 365
• What is Microsoft Intune?
• Microsoft Purview Information Protection

Related MSAdvance services

• Microsoft 365 migration
• Microsoft 365 Modern Workplace
• Microsoft 365 security and compliance
• Licence supply and sales
• Azure architecture
• All services

29. Conclusion and next steps

A well-executed Microsoft 365 migration can significantly improve how a company works: stronger email, organised files, Teams as the collaboration hub, protected identities, managed devices and better-governed data.

But achieving this requires method. Buying licences and changing the MX is not enough. You need to understand the environment, decide what is migrated, design the target, test with real users, execute in phases, validate results and support users.

The difference between a smooth migration and a problematic migration is usually found in what happens before cutover: assessment, communication, security, pilot and checklists. If those pieces are solid, the change feels like an improvement. If not, it feels like a disruption.