Migrating your organisation's email to Microsoft 365 is one of the most impactful infrastructure decisions a UK business can make — and one of the most technically demanding if handled without proper planning. Whether you are moving from an ageing on-premises Exchange server, transitioning from Google Workspace, or upgrading from a basic POP3/IMAP hosting provider, the process involves far more than simply pointing your MX records at Microsoft's servers and hoping for the best.
This guide is designed for UK IT decision-makers, system administrators, and managed service providers who need a thorough, practical understanding of the entire Microsoft 365 migration lifecycle. We cover every phase — from the initial assessment and licensing decisions through to DNS cutover, user training, and post-migration optimisation. We address the specific compliance considerations that apply to British organisations, including GDPR, ICO requirements, and UK data residency expectations. And we provide the technical detail you need to execute a migration that causes zero data loss and minimal disruption to your users.
At Cloudswitched, a London-based managed service provider, we have completed hundreds of email migration services UK projects for organisations ranging from five-person start-ups in Shoreditch to 2,000-seat enterprises with offices across the UK and Europe. The advice in this guide reflects that real-world experience — not theoretical best practice, but the lessons we have learned from migrations that went smoothly and, just as importantly, from the ones where unexpected complications tested our processes.
The scale of Office 365 migration activity across the United Kingdom has been remarkable. The shift to remote and hybrid working that began in 2020 forced many organisations to accelerate cloud adoption plans that had been sitting on roadmaps for years. But even as the initial urgency has faded, migrations continue at pace — driven by the end of support for older Exchange versions, the compelling economics of cloud-based email, and the integration advantages that Microsoft 365 offers when combined with Teams, SharePoint, and the broader Microsoft ecosystem.
What many organisations underestimate is the complexity that lies beneath the surface of what appears to be a straightforward migration. Email is not just messages — it is calendars, contacts, shared mailboxes, distribution lists, public folders, transport rules, journal rules, retention policies, mobile device configurations, third-party integrations, and years of institutional knowledge stored in folder structures that users depend on daily. A successful migration preserves all of this whilst simultaneously improving the user experience. A poorly executed migration creates weeks of support tickets, lost calendar entries, and frustrated users who cannot find emails they know they sent last Tuesday.
Why UK Organisations Choose Microsoft 365 for Email
Before diving into the technical detail of how to migrate, it is worth understanding why Microsoft 365 migration has become the default path for British businesses. The decision is rarely about email alone — it is about the entire productivity ecosystem that Microsoft 365 provides and how that ecosystem integrates with the way modern UK organisations work.
Microsoft 365 offers a genuinely unified platform. Email, calendars, and contacts through Exchange Online form the communication backbone, but they sit alongside Teams for real-time collaboration, SharePoint for document management, OneDrive for personal file storage, and a growing suite of security and compliance tools that address the regulatory requirements UK businesses face. The integration between these services is native and deep — a shared calendar in Outlook can trigger a Teams meeting, a file attached in an email can be stored in SharePoint, and the compliance tools span the entire platform rather than operating in silos.
For UK organisations specifically, Microsoft's investment in UK-based data centres (located in London and Cardiff) means that data residency requirements can be met without complex contractual arrangements. Since Brexit, data protection considerations have become more nuanced, and having confidence that your email data resides on UK soil simplifies compliance with both UK GDPR and the Data Protection Act 2018.
The Business Case for Migration
The financial argument for moving to Microsoft 365 is compelling for most UK organisations, though it varies depending on what you are migrating from. Organisations running on-premises Exchange servers face the ongoing costs of hardware maintenance, software licensing, backup infrastructure, and the IT staff time required to manage it all. When you factor in electricity, cooling, physical security, and the opportunity cost of your IT team spending time on email server maintenance rather than strategic projects, the total cost of ownership for on-premises email typically exceeds Microsoft 365 subscription costs by a significant margin.
Even at the higher licence tiers, Microsoft 365 typically costs less than maintaining equivalent on-premises infrastructure — and that calculation does not account for the disaster recovery, geo-redundancy, and automatic patching that Microsoft provides as part of the service. For a 100-user UK organisation running Exchange Server 2019 on-premises, the move to Microsoft 365 Business Standard typically saves £15,000–£25,000 annually whilst simultaneously improving availability and reducing the IT team's maintenance burden.
When building your business case, don't forget to include the "hidden" costs of on-premises email: backup software licensing, UPS battery replacements, out-of-hours patching downtime, SSL certificate management, spam filter subscriptions, and the cost of your IT team's time responding to email delivery issues. These often add 40–60% on top of the headline server and licensing costs.
Pre-Migration Assessment: The Foundation of Success
Every successful Microsoft 365 migration begins with a thorough assessment of your current environment. This phase is not optional — it is the single most important determinant of whether your migration will be smooth or chaotic. At Cloudswitched, we dedicate more time to assessment than to the actual migration itself, because the work done here prevents the problems that would otherwise surface at the worst possible moment.
Inventory Your Current Environment
The first step is building a comprehensive inventory of everything that currently exists in your email environment. This goes far beyond simply counting mailboxes. You need to document:
Mailbox inventory: Every user mailbox, shared mailbox, resource mailbox (meeting rooms, equipment), and any mailboxes that serve automated functions (such as receiving forms from your website or processing incoming purchase orders). For each mailbox, record the current size, the number of items, any special permissions, and whether the mailbox has delegates or send-as permissions configured.
Distribution groups and mail-enabled security groups: These are often more numerous and complex than organisations realise. A typical 200-user Exchange environment may have 50–100 distribution groups, some nested inside each other, some with external members, and some with specific sender restrictions. All of these need to be recreated or migrated.
Public folders: If your organisation uses Exchange public folders — and many long-established UK businesses do — you need to understand what data they contain, who accesses them, and how they will be represented in Microsoft 365. Public folder migration is one of the most challenging aspects of any Office 365 migration and deserves careful planning.
Transport rules and connectors: Mail flow rules that route, modify, or filter messages based on conditions. These need to be documented and recreated in Exchange Online, and some on-premises rules may not have direct equivalents in the cloud.
Third-party integrations: Any system that sends or receives email through your current environment — CRM platforms, accounting software, helpdesk systems, marketing automation tools, printers that scan-to-email, CCTV systems that send alerts, and any other application that uses SMTP relay.
| Assessment Area | What to Document | Common Pitfalls |
|---|---|---|
| User mailboxes | Count, sizes, permissions, delegates, mobile devices | Oversized mailboxes exceeding 50 GB migration limits |
| Shared mailboxes | Ownership, full-access permissions, send-as/send-on-behalf | Unlicensed shared mailboxes over 50 GB need an Exchange Online Plan 2 licence |
| Distribution lists | Members, nesting, sender restrictions, external members | Nested groups with circular references cause migration failures |
| Public folders | Hierarchy, sizes, permissions, item types (mail, calendar, contacts) | Public folders with 1M+ items require batch migration planning |
| Transport rules | Conditions, actions, exceptions, priority order | Rules referencing on-premises DLP or header modifications |
| SMTP relay devices | Printers, scanners, LOB apps, monitoring systems | Devices using basic auth that won't work with Modern Auth |
| DNS records | MX, SPF, DKIM, DMARC, autodiscover, CNAME | SPF record exceeding 10 DNS lookups after adding Microsoft's include |
| Client versions | Outlook versions, mobile clients, third-party mail apps | Outlook 2013 and earlier don't support Modern Authentication |
Network and Bandwidth Assessment
Microsoft 365 is a cloud service, which means every email your users send and receive, every calendar invitation, and every attachment travels over your internet connection. Before migrating, you need to verify that your network infrastructure can handle the additional load — both during the migration itself (when large volumes of data are being transferred) and during normal operations afterwards.
For the migration phase, bandwidth requirements depend on your chosen migration method and the volume of data. A cutover migration of 100 mailboxes averaging 5 GB each means transferring approximately 500 GB of data. Over a standard UK business broadband connection delivering 80 Mbps upload, that transfer takes roughly 14 hours under ideal conditions — but real-world conditions are never ideal, so plan for 2–3 times longer.
For ongoing operations, Microsoft recommends a minimum of 25 Kbps per user for Exchange Online, with 50 Kbps recommended. A 200-user office therefore needs roughly 10 Mbps dedicated to email traffic alone. Most modern UK business internet connections can handle this comfortably, but organisations in rural areas or those sharing bandwidth with other cloud services should verify capacity before proceeding.
Licensing Decisions
Microsoft 365 licensing can be bewildering. The naming conventions have changed multiple times, the feature matrices are dense, and the difference between plans is not always obvious. For email migration services UK projects, the licensing decision should be driven by what your users actually need rather than by the most comprehensive (and expensive) plan available.
For organisations that primarily need email, calendar, and basic cloud storage, Microsoft 365 Business Basic (£3.80/user/month) provides Exchange Online with 50 GB mailboxes, 1 TB OneDrive storage, and web versions of the Office applications. This is often sufficient for organisations where users already have perpetual Office licences installed on their devices.
For organisations that also need desktop Office applications (Word, Excel, PowerPoint, Outlook), Microsoft 365 Business Standard (£9.50/user/month) adds full desktop apps and additional collaboration features. This is the most popular choice among our UK clients.
For organisations with advanced security and compliance requirements — financial services firms, legal practices, healthcare providers, and government suppliers — Microsoft 365 Business Premium (£16.50/user/month) or the Enterprise E3/E5 plans provide advanced threat protection, data loss prevention, eDiscovery, and information governance capabilities that address UK regulatory expectations.
Migration Methods: Choosing the Right Approach
The method you choose for your Microsoft 365 migration depends on your source environment, the number of mailboxes, your tolerance for downtime, and your technical capabilities. Microsoft supports several migration methods, each with distinct advantages and limitations. Choosing the wrong method is one of the most common causes of migration failures — and the choice is not always as straightforward as Microsoft's documentation suggests.
Cutover Migration
Hybrid Migration
Staged Migration
Cutover Migration
A cutover migration moves all mailboxes from your source environment to Microsoft 365 in a single operation. Despite the name, it is not truly instantaneous — the initial data synchronisation happens in the background over hours or days, but the DNS cutover (the moment when email starts flowing to Microsoft 365 instead of your old server) happens at a single point in time for all users.
Cutover migration is the simplest method technically, which makes it attractive to smaller organisations. You create a migration batch in the Exchange admin centre, point it at your existing Exchange server, and Microsoft 365 begins copying all mailbox data. Once the initial copy is complete and incremental synchronisation has caught up, you change your MX records, wait for DNS propagation, and the migration is effectively complete.
The limitation is that cutover migration does not support coexistence. Once you flip the switch, all users are on Microsoft 365 — there is no going back without significant effort. For organisations with more than about 150 mailboxes, the synchronisation time becomes impractical and the risk of something going wrong during the cutover increases substantially. Our recommendation at Cloudswitched is to use cutover migration only for organisations with fewer than 100 mailboxes and straightforward configurations.
Hybrid Migration (Exchange Hybrid)
Hybrid migration is the gold standard for Office 365 migration from on-premises Exchange. It establishes a permanent (or temporary) relationship between your on-premises Exchange environment and Exchange Online, allowing you to move mailboxes individually or in batches whilst maintaining full coexistence between the two environments.
During a hybrid migration, users whose mailboxes are still on-premises can seamlessly communicate with users whose mailboxes have already been moved to the cloud. Free/busy information works across both environments. The global address list is unified. Users see no difference in their Outlook experience regardless of where their mailbox physically resides. This transparency is what makes hybrid migration the preferred approach for most UK businesses — you can move users in carefully planned batches, starting with a pilot group, and roll back individual mailboxes if issues are discovered.
The trade-off is complexity. Hybrid migration requires configuring the Hybrid Configuration Wizard (HCW), establishing an OAuth trust between on-premises and cloud environments, configuring send and receive connectors, deploying Azure AD Connect for directory synchronisation, and ensuring that your on-premises Exchange server meets specific version and update requirements. For organisations without in-house Exchange expertise, this is where engaging professional Microsoft 365 migration services UK providers like Cloudswitched delivers significant value.
Staged Migration
Staged migration is available only for organisations running Exchange 2003 or Exchange 2007. It allows you to move mailboxes in batches (stages), with each batch being synchronised to Microsoft 365 before users are switched over. Unlike hybrid migration, staged migration does not provide the same seamless coexistence — calendar free/busy information between on-premises and cloud users requires additional configuration, and users in each batch need to manually reconfigure their Outlook profiles after migration.
Given that Exchange 2003 and 2007 are long past end of life, staged migration is relevant primarily to organisations that have been running these legacy versions far longer than they should have. If your organisation is still on Exchange 2007, the migration to Microsoft 365 is genuinely urgent from a security perspective — these servers have not received security patches for years and represent a significant vulnerability.
IMAP Migration
For organisations migrating from non-Exchange email systems — Gmail/Google Workspace, Zimbra, Kerio Connect, hMailServer, or basic IMAP hosting providers — IMAP migration is the primary option. This method connects to your source system using the IMAP protocol and copies email messages (not calendars, contacts, or tasks — only email) to Microsoft 365 mailboxes.
IMAP migration has notable limitations. It transfers only the contents of users' inbox and other mail folders. Calendars, contacts, tasks, and notes must be migrated separately using export/import (PST files for Outlook users) or third-party migration tools. For organisations moving from Google Workspace, this means calendar events, Google Drive files, and Google Contacts all need separate migration paths.
Third-Party Migration Tools
For complex migrations or migrations from non-Exchange sources, third-party tools such as BitTitan MigrationWiz, Quest On Demand Migration, or SkyKick provide capabilities that go beyond what Microsoft's native tools offer. These tools can migrate calendars and contacts from IMAP sources, handle Google Workspace migrations more comprehensively, provide better reporting and scheduling, and support scenarios that Microsoft's native tools do not address.
At Cloudswitched, we use third-party tools for approximately 60% of our email migration services projects because they provide better control, more detailed logging, and the ability to schedule migration batches outside business hours with automatic retry on failure. The investment in tooling typically pays for itself in reduced migration time and fewer post-migration support tickets.
Regardless of which migration method you choose, always run a pilot migration with 5–10 representative users first. Include users with large mailboxes, users with complex delegation setups, users with many mobile devices, and at least one shared mailbox. The pilot will reveal configuration issues, permission problems, and compatibility gaps that documentation alone cannot predict.
Migrating from Google Workspace to Microsoft 365
Google Workspace to Microsoft 365 migrations have become increasingly common among UK businesses. While Google Workspace is a capable platform, many organisations find that the deeper integration between Microsoft 365, Windows endpoints, and enterprise security tools makes Microsoft the better long-term choice — particularly as organisations grow and their compliance requirements become more demanding.
Google Workspace migrations present unique challenges because the two platforms handle email, calendars, and file storage in fundamentally different ways. Google's labels are not the same as Outlook's folders. Google's calendar sharing model differs from Exchange's delegate access model. Google Drive's sharing permissions do not map directly to SharePoint or OneDrive permissions. And Google Contacts stored at the organisational level need to be converted to Exchange shared contacts or shared mailboxes.
What Migrates and What Doesn't
| Google Workspace Item | Microsoft 365 Equivalent | Migration Complexity |
|---|---|---|
| Gmail messages and labels | Outlook mail and folders | Moderate — labels become folders, multi-label messages are duplicated |
| Google Calendar events | Outlook calendar | Low — most events migrate cleanly |
| Google Contacts | Outlook contacts | Low — direct mapping |
| Google Drive files | OneDrive for Business | High — permissions, shared drives, and Google-native formats need conversion |
| Google Sheets/Docs/Slides | Excel/Word/PowerPoint (converted) | High — formatting loss, macro incompatibility, collaborative features change |
| Google Groups | Microsoft 365 Groups or distribution lists | Moderate — group type mapping requires decisions |
| Google Sites | SharePoint sites | High — manual recreation usually required |
| Google Chat history | Microsoft Teams | Very high — no native migration path |
The critical decision in a Google Workspace migration is whether to use Microsoft's native migration tools or a third-party solution. Microsoft provides a built-in Google Workspace migration feature in the Exchange admin centre that handles email, calendar, and contacts. However, for a comprehensive migration that includes Google Drive content and preserves the maximum amount of data fidelity, third-party tools are almost always necessary.
DNS Configuration: MX Records, SPF, DKIM, and DMARC
DNS configuration is the most technically precise phase of any Microsoft 365 migration. A single typo in an MX record, a misconfigured SPF entry, or a missing DKIM signature can result in email delivery failures, messages being rejected by recipient servers, or your domain being flagged as a spam source. Understanding each record type and its purpose is essential.
MX Records
MX (Mail Exchanger) records tell the internet where to deliver email for your domain. Before migration, your MX records point to your current email server. After migration, they must point to Microsoft 365. The specific MX record value is unique to your tenant and follows the format yourdomain-com.mail.protection.outlook.com with a priority of 0.
The timing of MX record changes is critical. DNS propagation can take anywhere from minutes to 48 hours, depending on the TTL (Time to Live) values configured on your existing records and the caching behaviour of DNS servers worldwide. Best practice is to reduce the TTL on your MX records to 300 seconds (5 minutes) at least 48 hours before the planned migration cutover. This ensures that when you change the MX records, the change propagates quickly and the period during which some email might be delivered to your old server and some to Microsoft 365 is minimised.
SPF Records
SPF (Sender Policy Framework) records declare which servers are authorised to send email on behalf of your domain. Without a correct SPF record, emails sent from your Microsoft 365 environment may be rejected or flagged as spam by recipient servers. The SPF record for Microsoft 365 must include include:spf.protection.outlook.com.
A common mistake during migration is forgetting to update the SPF record, or creating a second SPF record instead of modifying the existing one (a domain must have only one SPF record). If your organisation also sends email through other services — marketing platforms like Mailchimp or HubSpot, transactional email services like SendGrid, or CRM systems — those services must also be included in your SPF record.
Be aware of the SPF 10-lookup limit. Each include: mechanism in your SPF record triggers a DNS lookup, and the SPF specification limits the total number of lookups to 10. Organisations that use multiple email-sending services can hit this limit, causing SPF validation to fail for some recipients. SPF flattening services can help work around this limitation, but they add complexity and ongoing maintenance.
DKIM (DomainKeys Identified Mail)
DKIM adds a cryptographic signature to outgoing emails that recipient servers can verify, confirming that the message was genuinely sent from your domain and has not been altered in transit. Microsoft 365 supports DKIM signing, but it is not enabled by default — you must configure it manually after migration.
Configuring DKIM for Microsoft 365 requires creating two CNAME records in your DNS:
| Record Type | Host Name | Points To |
|---|---|---|
| CNAME | selector1._domainkey | selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com |
| CNAME | selector2._domainkey | selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com |
After creating these DNS records and allowing propagation, you enable DKIM signing in the Microsoft 365 Defender portal. The two selectors allow Microsoft to rotate DKIM keys automatically without causing delivery interruptions — while one selector is active, the other can be updated with a new key.
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
DMARC ties SPF and DKIM together and tells recipient servers what to do when an email fails authentication checks. A DMARC policy is published as a TXT record in your DNS and specifies whether to monitor (p=none), quarantine (p=quarantine), or reject (p=reject) emails that fail validation.
For organisations new to DMARC, we strongly recommend starting with p=none during and immediately after migration. This monitoring-only mode sends you reports about authentication failures without affecting email delivery. Once you have analysed the reports and confirmed that all legitimate email sources are correctly authenticated via SPF and DKIM, you can progressively tighten the policy to quarantine and eventually reject.
Include a rua= tag in your DMARC record to receive aggregate reports. Services like DMARC Analyzer, Valimail, or even free options like Postmark's DMARC tool will parse these reports into readable dashboards, showing you exactly which IP addresses are sending email as your domain — legitimate or otherwise. This visibility is invaluable both during migration and for ongoing email security.
The Migration Timeline: A Step-by-Step Approach
A well-planned Microsoft 365 migration follows a structured timeline that accounts for each phase of the project. Rushing through these phases is the most common cause of migration failures. Based on our experience delivering email migration services UK projects, here is a realistic timeline for a mid-sized UK organisation of 100–500 users.
Week 1–2: Assessment and Planning
Conduct full environment audit. Document mailboxes, distribution groups, public folders, transport rules, third-party integrations, and client versions. Assess network bandwidth. Choose migration method. Define licensing requirements. Identify pilot users. Establish rollback procedures and success criteria.
Week 3: Tenant Configuration
Set up the Microsoft 365 tenant. Add and verify your custom domain. Configure Azure AD Connect for directory synchronisation (hybrid only). Set up Exchange hybrid configuration (hybrid only). Create user accounts and assign licences. Configure security defaults or Conditional Access policies. Set up multi-factor authentication.
Week 4: Pilot Migration
Migrate 5–10 pilot users representing different roles, mailbox sizes, and technical complexity. Test email sending and receiving, calendar sharing, mobile device connectivity, Outlook profile configuration, and all third-party integrations. Document any issues and refine the migration process based on findings.
Week 5: User Communication and Training
Send migration communications to all users explaining the timeline, what to expect, and what they need to do. Conduct training sessions covering the new Outlook interface, Teams basics, OneDrive, and password/MFA setup. Provide written quick-start guides and a dedicated support channel for migration questions.
Week 6–7: Batch Migration
Migrate users in planned batches of 25–50, starting with less critical departments. Each batch follows the same process: initial sync, incremental sync, cutover, verification, and user notification. Schedule batches over weekends or evenings to minimise disruption. Monitor migration logs for errors.
Week 8: DNS Cutover and Final Migration
Reduce MX record TTL to 300 seconds (done 48 hours prior). Migrate final batch of users. Update MX records to point to Microsoft 365. Update SPF record. Configure DKIM. Publish DMARC record in monitoring mode. Verify email flow from external senders. Update autodiscover records.
Week 9–10: Post-Migration Optimisation
Monitor for delivery issues. Reconfigure SMTP relay devices (printers, scanners, LOB apps). Migrate public folders. Configure retention policies and archiving. Set up data loss prevention rules. Review and close out migration support tickets. Conduct user satisfaction survey. Decommission old email server.
This timeline assumes a hybrid migration with moderate complexity. Cutover migrations for smaller organisations can compress this to 3–4 weeks. Large enterprise migrations with complex hybrid configurations, multiple domains, and regulatory requirements may extend to 12–16 weeks or longer.
Coexistence: Managing the Transition Period
For organisations using hybrid migration, the coexistence period — when some users are on Microsoft 365 and others remain on the on-premises server — is the most technically nuanced phase of the project. Getting coexistence right is what separates professional Microsoft 365 migration services UK providers from organisations attempting the migration without specialist support.
During coexistence, email routing must work seamlessly in both directions. A user on Microsoft 365 must be able to send email to a user still on-premises, and vice versa, with no visible difference from the user's perspective. Calendar free/busy information must be available across both environments. The global address list must be unified so that all users — regardless of where their mailbox resides — appear in the directory.
Azure AD Connect handles directory synchronisation, creating a unified view of all users across both environments. The Exchange hybrid configuration establishes the trust relationships and mail flow connectors that enable seamless email routing. When a user on-premises sends an email to a user in the cloud, the on-premises Exchange server routes the message through the hybrid send connector to Exchange Online. When a cloud user sends to an on-premises user, Exchange Online routes through the hybrid receive connector back to the on-premises server.
The most common coexistence issues we encounter at Cloudswitched are:
Free/busy failures: Users cannot see the availability of colleagues whose mailboxes are in the other environment. This is typically caused by OAuth misconfiguration or certificate issues on the hybrid server. The fix involves verifying the Intra-Organization Connector settings and ensuring that the Exchange hybrid server's certificate is valid and trusted by Microsoft 365.
Mail flow loops: Emails between on-premises and cloud users bounce or loop. This usually indicates incorrect send/receive connector configuration or conflicting transport rules. The hybrid configuration wizard should handle this automatically, but manual modifications to connectors (which well-meaning administrators sometimes make) can introduce routing loops.
Address book inconsistencies: New users created in one environment do not appear in the other, or user details are not synchronising correctly. This points to Azure AD Connect synchronisation issues — often related to OU filtering rules that exclude certain organisational units from synchronisation.
Data Migration: Beyond Email Messages
A complete email migration services project encompasses far more than just moving messages from one server to another. The ancillary data — calendars, contacts, tasks, public folders, archives, and shared resources — often takes more effort to migrate correctly than the email messages themselves.
Calendar Migration
Calendar data is arguably more critical than email for many organisations. A missed meeting because a calendar entry was lost during migration is an immediately visible failure that damages user confidence in the entire project. Calendar migration must preserve not just individual events but also recurring meeting series, meeting room bookings, delegate access permissions, and shared calendar subscriptions.
For Exchange-to-Exchange Online migrations (cutover or hybrid), calendar data migrates automatically alongside email. The mailbox move request transfers the entire mailbox contents, including all calendar folders. Recurring meetings, attendee lists, and room bookings are preserved with full fidelity.
For IMAP or Google Workspace migrations, calendar data requires separate handling. Google Calendar events can be migrated using the Google Workspace migration feature in Microsoft 365, but some nuances are lost — particularly around Google Calendar's more flexible recurring event patterns and the way Google handles all-day events across time zones.
Public Folder Migration
Public folders remain one of the most challenging aspects of any Office 365 migration. Many UK organisations that have been running Exchange for 15–20 years have accumulated enormous public folder hierarchies containing shared calendars, contact lists, email archives, and even custom forms. These structures often represent years of institutional knowledge and workflow that users depend on daily.
Microsoft 365 supports public folders in Exchange Online, and Microsoft provides a batch migration process for moving public folders from on-premises to the cloud. However, the process is complex, has strict size and item-count limits, and requires careful planning. Public folders exceeding 25 GB per mailbox (the cloud public folder mailbox limit) must be split across multiple public folder mailboxes. Folders with more than 1 million items may need special handling.
An alternative approach — and one we increasingly recommend — is to migrate public folder content to Microsoft 365 Groups or SharePoint document libraries. This modernises the collaboration model and aligns with Microsoft's long-term strategic direction, which clearly favours Groups over public folders. However, this approach requires more planning, user training, and careful mapping of permissions.
User Training and Change Management
Technical migration perfection means nothing if your users cannot work effectively in the new environment. Change management and user training are not afterthoughts — they are core components of any successful Microsoft 365 migration project, and neglecting them is the most common reason migrations are perceived as failures even when the technical execution was flawless.
The scope of user training depends on what you are migrating from. Users moving from an older version of Outlook connected to on-premises Exchange may find the transition to Outlook connected to Exchange Online nearly seamless — the interface is familiar, and the main differences are in the configuration rather than the daily workflow. Users moving from Google Workspace to Microsoft 365, on the other hand, face a much steeper learning curve: different keyboard shortcuts, different folder/label paradigms, different calendar sharing models, and an entirely new set of collaboration tools.
Training Priorities
Based on our experience with hundreds of email migration services UK projects, these are the training topics that generate the most support tickets when inadequately covered:
Outlook profile configuration: Users need to understand how to set up their Outlook profile to connect to Microsoft 365. For hybrid migrations, this happens automatically through Autodiscover. For cutover or IMAP migrations, users may need to create a new Outlook profile manually — and the process of doing this while preserving their existing local data (autocomplete cache, rules, signatures) requires clear step-by-step instructions.
Multi-factor authentication (MFA): If your organisation is implementing MFA as part of the migration (which it should be — MFA is the single most effective security measure available), users need training on how to set up and use the Microsoft Authenticator app, how to handle MFA prompts, and what to do if they lose access to their authentication device.
Mobile device reconfiguration: Every user with email on their mobile phone will need to reconfigure their mail app. For iPhones and iPads, this typically means removing the existing Exchange account and adding a new one with the Microsoft 365 server settings. For Android devices, the process varies by manufacturer and mail app. The Outlook mobile app simplifies this, but not all users will want to switch from their device's native mail app.
OneDrive and SharePoint: If the migration includes moving from a file server or Google Drive to OneDrive and SharePoint, users need to understand the new file storage model — what goes in OneDrive (personal files), what goes in SharePoint (team files), how sharing works, and how to sync files to their desktop using the OneDrive sync client.
UK Compliance and Data Protection Considerations
UK organisations migrating to Microsoft 365 must navigate a regulatory landscape that has become more complex since Brexit. While the UK GDPR largely mirrors the EU GDPR, there are nuances around international data transfers, sector-specific requirements, and the role of the Information Commissioner's Office (ICO) that UK businesses must understand and address during their migration planning.
UK GDPR and the Data Protection Act 2018
Email systems contain vast quantities of personal data — names, addresses, phone numbers, financial details, health information, and more. Migrating this data to Microsoft 365 constitutes "processing" under UK GDPR, which means your organisation must have a lawful basis for the transfer, ensure appropriate security measures are in place, and potentially update your data processing records and privacy notices.
Microsoft acts as a data processor when handling your organisation's email data in Microsoft 365. Microsoft's Data Processing Addendum (DPA) provides the contractual framework required under UK GDPR, including commitments around data security, breach notification, and sub-processor management. However, your organisation remains the data controller and retains ultimate responsibility for how that data is handled.
Data Residency
Microsoft operates data centres in the United Kingdom (London and Cardiff). For UK tenants, Exchange Online data is stored at rest in these UK data centres by default. This addresses the data residency concerns that many UK organisations — particularly those in regulated sectors — have about their email data being stored overseas.
However, it is important to understand that "data at rest" does not mean "data at all times." Email in transit may pass through non-UK infrastructure, and certain Microsoft 365 services may process data in other regions. For organisations with strict data sovereignty requirements, Microsoft's Advanced Data Residency add-on provides broader guarantees about where data is stored and processed.
Sector-Specific Requirements
Certain UK sectors have additional requirements that must be considered during migration:
Financial services: The FCA's operational resilience requirements mean that regulated firms must ensure their email migration does not create concentration risk and that they can continue to operate if Microsoft 365 experiences an outage. This typically means maintaining business continuity plans that account for cloud service disruption.
Healthcare: NHS organisations and private healthcare providers handling patient data must ensure their Microsoft 365 configuration meets the requirements of the NHS Digital Data Security and Protection Toolkit. This includes specific requirements around access controls, audit logging, and encryption.
Legal services: Law firms have professional obligations around client confidentiality and legal professional privilege. The SRA's (Solicitors Regulation Authority) guidance on cloud computing applies to email migration, and firms must ensure that their Microsoft 365 configuration preserves client confidentiality protections.
Government and public sector: UK government organisations must comply with the National Cyber Security Centre's (NCSC) cloud security guidance. Microsoft 365 is approved for use at OFFICIAL classification (including OFFICIAL-SENSITIVE), but specific configuration requirements apply.
Post-Migration Tasks and Optimisation
The work does not end when the last mailbox has been migrated and the MX records have been updated. Post-migration tasks are critical for ensuring long-term stability, security, and user satisfaction. Many organisations treat migration as a "done" project the moment email is flowing through Microsoft 365, only to discover weeks later that important configurations were missed.
SMTP Relay Reconfiguration
Every device and application in your organisation that sends email — printers that scan to email, monitoring systems that send alerts, line-of-business applications that generate invoices or notifications, website contact forms — needs to be reconfigured to send through Microsoft 365 instead of your old email server. Microsoft supports three SMTP relay methods:
SMTP client submission (port 587): Requires authentication with a licensed Microsoft 365 account. Best for applications that need to send as a specific user and support Modern Authentication or basic authentication (being deprecated).
Direct send (port 25): Sends email directly to Microsoft 365 without authentication, but can only send to recipients within your organisation. Best for devices that need to send internal notifications only.
SMTP relay via connector (port 25): Uses a receive connector in Exchange Online to accept email from your organisation's IP address(es) and relay it to internal and external recipients. Best for devices and applications that need to send to external recipients but cannot authenticate.
Retention Policies and Archiving
Microsoft 365 provides powerful retention and archiving capabilities that most organisations should configure after migration. Exchange Online retention policies can automatically move old messages to archive mailboxes, delete messages after a specified period, or preserve messages for legal hold — all without user intervention.
For UK organisations, retention policies should reflect both business requirements and legal obligations. The Limitation Act 1980 creates a six-year limitation period for most contractual and tortious claims, which many organisations use as the basis for a six-year email retention policy. Regulated sectors may have longer or shorter requirements — HMRC requires financial records to be kept for six years, while healthcare records may need to be retained for 25 years or longer.
Security Hardening
With email migrated to Microsoft 365, your security posture should be strengthened to take advantage of the platform's built-in security features:
Multi-factor authentication: If not already enabled, MFA should be mandatory for all users. Microsoft Security Defaults provides basic MFA at no additional cost. Organisations with Business Premium or E3/E5 licences should implement Conditional Access policies for more granular control.
Anti-phishing policies: Exchange Online Protection (EOP) provides baseline protection, but organisations should configure anti-phishing policies in Microsoft 365 Defender to enable mailbox intelligence, impersonation detection, and spoof protection tailored to their specific domain and user environment.
Audit logging: Enable unified audit logging to track administrative actions, mailbox access, and file sharing activity. This logging is essential for incident investigation, compliance reporting, and demonstrating due diligence to regulators.
| Post-Migration Task | Priority | Timeline | Impact of Skipping |
|---|---|---|---|
| SMTP relay device reconfiguration | Critical | Week 1 | Devices cannot send email; scan-to-email, alerts, and automated emails fail |
| MFA enforcement | Critical | Week 1 | Accounts vulnerable to credential-based attacks |
| DKIM and DMARC configuration | High | Week 1–2 | Email deliverability issues; domain vulnerable to spoofing |
| Retention policy configuration | High | Week 2–3 | Non-compliance with retention obligations; uncontrolled mailbox growth |
| Anti-phishing policy tuning | High | Week 2–3 | Increased phishing risk; false positives disrupting legitimate email |
| Audit logging enablement | Medium | Week 2 | Cannot investigate incidents; compliance gaps |
| Old server decommission | Medium | Week 4–8 | Ongoing costs; security risk from unpatched server |
| User satisfaction survey | Low | Week 4 | Unidentified user issues; missed training gaps |
Decommissioning the Old Email Server
Once you are confident that the migration is complete, all email is flowing through Microsoft 365, and no devices or applications still depend on the old server, you can decommission the legacy environment. However, do not rush this step. We recommend keeping the old email server available (but with its MX records removed) for at least 4–8 weeks after migration. This provides a safety net in case any data was missed during migration, and it allows you to retrieve any emails that may have been delivered to the old server during the DNS propagation period.
Before decommissioning, verify that:
All mailbox data has been successfully migrated and is accessible in Microsoft 365. All public folder data has been migrated or archived. All shared mailboxes, distribution groups, and mail-enabled contacts have been recreated in Exchange Online. No devices or applications are still configured to use the old server for SMTP relay. All transport rules and mail flow configurations have been recreated in Exchange Online. Server backups have been taken and stored in accordance with your retention policy, in case historical data needs to be accessed later.
Common Migration Pitfalls and How to Avoid Them
Having completed hundreds of email migration services UK projects, we have seen the same mistakes repeated across organisations of all sizes. Learning from these common pitfalls can save your organisation significant time, frustration, and cost.
Pitfall 1: Underestimating Mailbox Sizes
Large mailboxes are the single most common cause of migration delays. A mailbox that has grown to 80 GB over a decade will take significantly longer to migrate than the 5 GB average you planned for. Worse, some migration methods have hard limits on mailbox size that can cause migration failures mid-process. The solution is simple: audit mailbox sizes during assessment and plan migration batch sizes and schedules accordingly.
Pitfall 2: Forgetting About Mobile Devices
Every user with email on their mobile phone will be affected by the migration. For Exchange-to-Exchange Online migrations with hybrid configuration, mobile devices typically reconnect automatically through Autodiscover. But for cutover, IMAP, or Google Workspace migrations, every mobile device needs manual reconfiguration. For an organisation with 200 users where 80% have email on their phones, that is 160 devices that need attention — and many users will need hands-on support to complete the process.
Pitfall 3: SPF Record Issues
The most common DNS-related migration failure is an incorrect or incomplete SPF record. Adding Microsoft 365's SPF include without removing the reference to your old email server creates a valid but potentially problematic record. Failing to add Microsoft's include at all means your outgoing emails from Microsoft 365 will fail SPF checks at recipient servers. And exceeding the 10-lookup limit by including too many services causes intermittent delivery failures that are extremely difficult to diagnose.
Pitfall 4: Ignoring Legacy Applications
That ancient CRM system that sends email notifications through your SMTP server. The PHP contact form on your website. The payroll system that emails payslips. The monitoring tool that sends alerts at 3 AM. These legacy applications are easy to overlook during migration planning but will cause immediate, visible failures the moment your old email server is decommissioned. Document every application that sends email and plan its reconfiguration as part of the migration project.
Pitfall 5: Insufficient User Communication
Users who are surprised by migration experience it negatively. Users who are prepared, trained, and informed experience it positively — even if the same technical issues occur. Communication should start at least two weeks before the migration, include clear timelines, set expectations about temporary disruptions, provide simple instructions for common tasks (reconfiguring mobile devices, setting up MFA), and include a clear escalation path for problems.
Why Choose Professional Microsoft 365 Migration Services
While smaller organisations with straightforward configurations can sometimes manage a Microsoft 365 migration internally, the reality is that most UK businesses benefit significantly from engaging professional Microsoft 365 migration services UK providers. The cost of professional assistance is almost always less than the cost of a failed or problematic migration — measured in lost productivity, user frustration, data loss risk, and the IT team's time spent firefighting issues that proper planning would have prevented.
At Cloudswitched, our London-based team brings deep expertise in every aspect of email migration services. We have migrated organisations from every source environment — Exchange 2007 through to 2019, Google Workspace, Zimbra, Kerio Connect, Lotus Notes, GroupWise, and dozens of IMAP hosting providers. We handle the entire process from assessment through to post-migration optimisation, and we provide dedicated support during and after the migration to ensure your users' experience is seamless.
Our approach includes comprehensive pre-migration assessment, pilot migration with detailed testing, batched user migration scheduled outside business hours, DNS configuration and email authentication (SPF, DKIM, DMARC), SMTP relay reconfiguration for all devices and applications, user training sessions and documentation, and 30 days of post-migration priority support. Every migration is project-managed with clear milestones, regular progress updates, and defined rollback procedures.
For UK organisations, working with a London-based MSP means your migration team understands the UK regulatory landscape, operates in your time zone, and can provide on-site support when needed. We hold Microsoft Gold Partner status and our engineers maintain current Microsoft 365 certifications, ensuring that the advice and technical execution you receive reflects current best practice rather than outdated approaches.
Ready to Migrate Your Email to Microsoft 365?
Cloudswitched provides end-to-end Microsoft 365 migration services for UK businesses. From initial assessment through to post-migration support, our London-based team ensures zero data loss, minimal disruption, and a seamless transition for your users. Book a free consultation to discuss your migration requirements.
Frequently Asked Questions
How long does a Microsoft 365 email migration take?
The duration depends on the number of mailboxes, the total data volume, the source environment, and the migration method chosen. A small organisation with 20–50 mailboxes can typically complete a cutover migration in 1–2 weeks. A mid-sized organisation with 100–500 mailboxes using hybrid migration should plan for 6–10 weeks. Large enterprises with complex configurations may require 12–16 weeks or longer. The assessment and planning phase alone should take at least 1–2 weeks regardless of organisation size.
Will users lose any email during the migration?
With proper planning and execution, no. Both cutover and hybrid migration methods use incremental synchronisation, which means changes made to mailboxes on the source server after the initial copy are automatically synchronised to Microsoft 365. The only risk period is the brief window during DNS propagation when some email might be delivered to the old server — and this risk is mitigated by keeping the old server active and monitoring for straggler messages.
Can we migrate from Google Workspace to Microsoft 365?
Yes. Google Workspace to Microsoft 365 migration is fully supported, though it requires different tools and approaches than Exchange-to-Exchange migrations. Email, calendar, and contacts can be migrated using Microsoft's built-in Google Workspace migration feature or third-party tools. Google Drive content can be migrated to OneDrive and SharePoint, though Google-native file formats (Docs, Sheets, Slides) are converted to their Microsoft equivalents with some potential formatting differences.
What happens to our existing email addresses?
Your email addresses remain exactly the same. Microsoft 365 uses your existing custom domain (e.g., yourcompany.co.uk), so users keep their current email addresses. The migration changes where email is stored and processed (from your old server to Microsoft's cloud), not the addresses themselves.
Is Microsoft 365 email compliant with UK data protection law?
Yes. Microsoft 365 is designed to meet UK GDPR and Data Protection Act 2018 requirements. Microsoft's Data Processing Addendum provides the contractual framework required for data processor relationships under UK GDPR. For UK tenants, Exchange Online data is stored at rest in Microsoft's UK data centres (London and Cardiff). However, your organisation remains the data controller and must ensure that your own configuration — access controls, retention policies, sharing settings — meets your regulatory obligations.
Do we need to upgrade our internet connection before migrating?
Possibly, but most UK business internet connections are sufficient. Microsoft recommends 50 Kbps per user for Exchange Online. A 100-user organisation therefore needs approximately 5 Mbps dedicated to email traffic. Most business broadband, leased line, or FTTP connections in the UK provide this comfortably. However, if you are also moving to Teams, SharePoint, and OneDrive simultaneously, the total bandwidth requirements increase and should be assessed as part of the pre-migration planning.
What if something goes wrong during the migration?
A well-planned migration includes defined rollback procedures. For hybrid migrations, individual mailbox moves can be reversed by moving the mailbox back to the on-premises server. For cutover migrations, reverting MX records to point back to the old server restores email flow to the original environment. The key is planning: rollback procedures should be documented before the migration begins, not improvised when problems arise. Professional email migration services UK providers like Cloudswitched include rollback planning as a standard part of every migration project.
Conclusion: Planning Is Everything
A Microsoft 365 migration is not a weekend project — it is a business transformation that, when executed correctly, delivers measurable improvements in productivity, security, collaboration, and cost efficiency. The technical complexity is real but manageable with proper planning, the right tools, and the expertise that comes from having done it many times before.
The UK market for Office 365 migration services continues to grow as organisations recognise the strategic advantages of cloud-based email and productivity. Whether you are migrating from a decade-old Exchange server, moving from Google Workspace, or upgrading from a basic hosted email provider, the fundamental principles remain the same: assess thoroughly, plan meticulously, migrate methodically, and support your users through the change.
At Cloudswitched, we believe that every UK organisation deserves a migration experience that is seamless, secure, and stress-free. Our team has the expertise, the tools, and the track record to deliver exactly that. If your organisation is considering a move to Microsoft 365, we would welcome the opportunity to discuss your requirements and demonstrate how our Microsoft 365 migration services UK approach can get you there with confidence.
Start Your Microsoft 365 Migration Journey
Whether you are migrating 10 mailboxes or 10,000, Cloudswitched has the expertise and experience to ensure your transition to Microsoft 365 is smooth, secure, and successful. Contact our London-based team today for a free, no-obligation migration assessment.
CloudSwitched
London-based managed IT services provider offering support, cloud solutions and cybersecurity for SMEs.
