Exchange vs Google Workspace to Office 365: Migration Paths Compared

Migrating your organisation's email and collaboration platform is one of the most consequential IT decisions you will make. Whether you are running an ageing on-premise Exchange server in a London data centre, managing a fleet of Google Workspace licences, or operating a hybrid environment that has grown unwieldy over the years, the destination for most UK businesses in 2026 is Microsoft 365. The question is not whether to move — it is how to get there with minimal disruption, zero data loss, and a user experience that keeps your teams productive throughout the transition.

This comprehensive guide compares every major migration path — from Exchange migration to 365 via cutover, staged, and hybrid methods, through Google Workspace to Microsoft 365 cross-platform moves, to complex coexistence strategies for enterprises that cannot afford a single hour of downtime. We cover planning, tooling, timelines, costs, and the pitfalls that trip up even experienced IT departments. If you are a UK business evaluating your options, this is the only resource you need.

Understanding the Migration Landscape in the UK

The migration landscape for UK businesses in 2026 is shaped by several converging forces. Microsoft's end-of-support lifecycle for on-premise Exchange Server versions continues to push organisations cloudward. Exchange Server 2016 entered extended support's final phase, and Exchange Server 2019 follows closely behind. For businesses still running these platforms — particularly those in regulated sectors such as financial services, legal, and healthcare — the urgency to migrate has never been greater.

Simultaneously, organisations that adopted Google Workspace (formerly G Suite) during the remote working boom of 2020–2022 are increasingly finding that their broader technology stack — Active Directory, Windows endpoints, SharePoint, Teams — aligns more naturally with the Microsoft ecosystem. The result is a growing wave of Google Workspace to Office 365 migrations across the UK, driven not by dissatisfaction with Google's platform but by the practical reality of ecosystem consolidation.

The UK market presents unique considerations that generic migration guides overlook. Data residency requirements under UK GDPR demand careful attention to where mailbox data is processed and stored during migration. Many UK organisations operate across multiple time zones (London, Edinburgh, Belfast, plus European offices), requiring migration scheduling that minimises disruption across all locations. And the prevalence of hybrid working models means that migration must account for users accessing email from home broadband connections, not just high-speed office networks.

Why Microsoft 365 Has Become the Default Destination

Microsoft 365's dominance in the UK enterprise market is not accidental. The platform offers a unified experience across email (Exchange Online), collaboration (Teams and SharePoint), productivity (the Office suite), and security (Microsoft Defender, Purview, and Entra ID). For IT teams managing compliance obligations under UK GDPR, the FCA's operational resilience framework, or NHS data security standards, having a single vendor with UK-based data centres and comprehensive compliance certifications simplifies governance enormously.

The licensing model has also evolved. Microsoft 365 Business Premium, at approximately £18.70 per user per month, bundles email, Office applications, advanced security, and device management into a single SKU. For many UK SMEs, this represents better value than maintaining separate subscriptions for email hosting, antivirus, mobile device management, and productivity software.

Exchange to Microsoft 365: The Three Core Migration Paths

If your organisation runs on-premise Exchange Server, you have three primary methods for migrating to Exchange Online within Microsoft 365. Each method suits different organisation sizes, Exchange versions, and tolerance for downtime. Choosing the wrong path is costly — not just in terms of project budget, but in lost productivity and user frustration. Let us examine each approach in detail.

Cutover Migration: The Clean Break

A cutover migration moves all mailboxes, contacts, and distribution groups from on-premise Exchange to Microsoft 365 in a single batch. Think of it as ripping off the plaster — everything moves at once, typically over a weekend, and on Monday morning your users log into Exchange Online instead of the on-premise server.

Cutover migration is the simplest approach conceptually, but it comes with hard constraints. Microsoft officially supports cutover migration for organisations with fewer than 2,000 mailboxes, though in practice, performance degrades significantly beyond 150–300 mailboxes. The migration uses Exchange Web Services (EWS) to synchronise data, and the throughput is limited by network bandwidth, server resources, and Microsoft's throttling policies.

For a typical UK SME with 50–150 users, a cutover migration can be completed in a single weekend. The process follows a predictable pattern: verify your domain in Microsoft 365, create a migration endpoint pointing to your on-premise Exchange server, initiate the migration batch, wait for initial synchronisation, perform a final incremental sync, update DNS MX records to point to Exchange Online, and decommission the on-premise server once you have confirmed everything is working.

The primary advantage of cutover migration is simplicity. There is no prolonged coexistence period, no complex routing rules, and no split-brain scenarios where some users are in the cloud whilst others remain on-premise. The primary disadvantage is the all-or-nothing nature — if something goes wrong mid-migration, rollback means reverting DNS and restoring from backup, which is time-consuming and stressful.

Staged Migration: The Phased Approach

Staged migration moves mailboxes to Microsoft 365 in batches over a period of weeks or months. This approach is designed for organisations running Exchange Server 2003 or Exchange Server 2007 — versions so old that they do not support the hybrid migration method. You create CSV files listing the mailboxes in each batch, and the migration service processes them sequentially.

In the UK context, staged migration is increasingly rare because very few organisations still run Exchange 2003 or 2007. However, some businesses in regulated sectors — particularly those with legacy compliance archiving systems tied to older Exchange versions — may still find themselves in this situation. If you are running Exchange 2003 or 2007 and have not yet migrated, the urgency cannot be overstated: these platforms have been out of all support for years and represent significant security risks.

The staged migration process involves directory synchronisation between on-premise Active Directory and Microsoft Entra ID (formerly Azure AD) using Entra Connect. Each batch of mailboxes is migrated via CSV file upload, and users are converted from on-premise to cloud mailboxes incrementally. During the migration period, some users will be on-premise and others in the cloud, requiring mail flow routing configuration to ensure messages reach the correct destination.

Hybrid Migration: The Enterprise Standard

Hybrid migration — often referred to as an Exchange hybrid migration UK deployment — is the gold standard for organisations with more than 150 mailboxes or those requiring extended coexistence between on-premise Exchange and Exchange Online. It provides the most flexibility, the best user experience during migration, and the most graceful rollback options if issues arise.

In a hybrid configuration, your on-premise Exchange organisation and Exchange Online are federated. Users can be moved between on-premise and cloud mailboxes individually or in batches, and the experience is seamless — a user on-premise can view the free/busy status of a colleague in the cloud, share calendars, and send encrypted messages as if they were on the same system. The migration is essentially invisible to end users.

Setting up hybrid requires several components: Entra Connect for directory synchronisation, an Exchange Hybrid Configuration Wizard (HCW) run, proper certificates for secure communication, and network configuration to allow Exchange Online to communicate with your on-premise servers. For UK organisations, this typically means ensuring your firewall allows inbound connections on ports 443 and 25 from Microsoft's IP ranges, and that your SSL certificates are issued by a publicly trusted certificate authority.

The hybrid approach also supports what Microsoft calls a "minimal hybrid" or "express migration" configuration, which provides a streamlined setup for organisations that plan to move all mailboxes to the cloud but want the superior migration experience of hybrid moves. This is increasingly the recommended approach for UK mid-market organisations with 150–5,000 users.

On-Premise Exchange to 365 Migration: Step-by-Step Planning

Regardless of which migration method you choose, a successful on-premise Exchange to 365 migration follows a structured planning process. The organisations that experience the smoothest migrations are those that invest the most time in preparation — and the least time in firefighting during the actual move. Here is the process that Cloudswitched follows for every UK client engagement.

Phase 1: Discovery and Assessment

The discovery phase is where you map your current environment in exhaustive detail. This is not a cursory glance at your Exchange Management Console — it is a systematic audit of every element that will be affected by the migration. Start with your mailbox inventory: how many user mailboxes, shared mailboxes, resource mailboxes (rooms and equipment), and linked mailboxes do you have? What is the size distribution? A single 100 GB executive mailbox can take longer to migrate than fifty 2 GB mailboxes combined.

Next, catalogue your public folders. Public folders are one of the most common sources of migration complications. If your organisation has been running Exchange for a decade or more, you likely have a sprawling public folder hierarchy containing everything from shared calendars to departmental document repositories. Microsoft 365 supports public folder migration, but the process requires careful planning — particularly for folders exceeding 25 GB or those with complex permission structures.

Document your mail flow architecture. Where are your MX records pointed? Do you use a third-party spam filter or email security gateway (such as Mimecast, Proofpoint, or Barracuda)? Do you have transport rules, journal rules, or DLP policies on your on-premise Exchange server? All of these must be replicated or replaced in Exchange Online before you cut over mail flow.

Finally, identify all third-party integrations. CRM systems that send email through Exchange, line-of-business applications that use SMTP relay, multifunction printers that scan to email, and monitoring systems that send alerts — all of these depend on your current mail infrastructure and must be reconfigured to work with Microsoft 365.

Phase 2: Tenant Preparation and Identity Configuration

With your discovery complete, the next phase is preparing your Microsoft 365 tenant. This involves domain verification, licence assignment, and — critically for hybrid and staged migrations — directory synchronisation configuration.

Domain verification is straightforward: you add a TXT record to your public DNS zone to prove ownership of your email domain. For UK organisations with multiple domains (which is common — many businesses operate .co.uk, .com, and sometimes .org.uk variants), each domain must be verified individually.

Entra Connect (formerly Azure AD Connect) is the bridge between your on-premise Active Directory and Microsoft Entra ID. It synchronises user accounts, groups, and contacts, ensuring that your cloud identities match your on-premise directory. For UK organisations, we recommend deploying Entra Connect on a dedicated Windows Server VM — not on your domain controller — and configuring password hash synchronisation as the authentication method. This provides the best balance of simplicity and resilience.

Phase 3: Pilot Migration

Never migrate your entire organisation at once without first running a pilot. Select 10–20 users from different departments, with varying mailbox sizes and usage patterns, and migrate them first. The pilot group should include at least one executive with a large mailbox, one user who relies heavily on shared mailboxes and public folders, one user with complex calendar delegation, and one user who uses Outlook on a Mac (which has its own quirks during migration).

The pilot serves multiple purposes. It validates your technical configuration, identifies unexpected issues before they affect the entire organisation, gives your IT helpdesk team practice handling migration-related support tickets, and provides real-world performance data for estimating the full migration timeline.

Phase 4: Batch Migration and Cutover

With the pilot successful, you proceed to batch migration. For hybrid deployments, this involves scheduling migration batches — typically by department or location — and executing them during off-peak hours. For UK organisations, Friday evening through Sunday is the most common migration window, as it provides the maximum time for data transfer and issue resolution before the working week begins.

The final step is the MX record cutover. Once all mailboxes have been migrated and verified, you update your public DNS MX records to point to Exchange Online. DNS propagation typically completes within an hour for most UK ISPs, but you should allow 24–48 hours before considering the cutover complete. During this propagation window, mail may arrive at either the on-premise server or Exchange Online, so both systems must remain operational.

Google Workspace to Microsoft 365: Cross-Platform Migration

Migrating from Google Workspace to Microsoft 365 is fundamentally different from an Exchange-to-Exchange move. You are not just changing where mailboxes are hosted — you are transitioning between two entirely different ecosystems with different file formats, collaboration models, and user workflows. Google Docs becomes Word. Google Sheets becomes Excel. Google Drive becomes OneDrive and SharePoint. Google Meet becomes Teams. Gmail becomes Outlook. Every user's muscle memory must be retrained.

The technical migration itself is well-supported by Microsoft's tooling, but the human and organisational challenges are where most Google Workspace to Office 365 projects stumble. We have seen UK organisations execute technically flawless migrations only to face user revolts because people had spent years building workflows around Google's collaboration model and found the transition to Microsoft's approach disorienting.

Why UK Organisations Move from Google to Microsoft

The motivations for moving from Google Workspace to Microsoft 365 vary, but several themes recur in our UK client conversations. The most common driver is ecosystem alignment: the organisation uses Active Directory for identity, Windows for endpoints, and has invested in SharePoint or Teams for internal collaboration. Running Google Workspace for email whilst everything else is Microsoft creates friction, duplicated administration, and licensing inefficiency.

Compliance is another significant driver. UK financial services firms regulated by the FCA often find that Microsoft's compliance tooling — particularly Microsoft Purview for data loss prevention, eDiscovery, and information governance — is more mature and better integrated than Google's equivalent offerings. When your regulators ask for an audit trail, having everything in one platform simplifies the response enormously.

Security integration also plays a role. Microsoft Defender for Office 365, conditional access policies in Entra ID, and Microsoft Sentinel for SIEM all work natively with Exchange Online. Achieving the same level of security integration with Google Workspace typically requires additional third-party tools and more complex configuration.

Data Migration: What Moves and What Doesn't

The core migration covers email, contacts, calendars, and files. Microsoft provides a native migration tool within the Microsoft 365 admin centre that supports Google Workspace as a source, using the Google Workspace migration API. This tool handles Gmail messages (preserving labels as folders), Google Calendar events, and Google Contacts.

For Google Drive to OneDrive migration, Microsoft's SharePoint Migration Tool (SPMT) or the Migration Manager within the SharePoint admin centre handles the heavy lifting. Google Docs, Sheets, and Slides are automatically converted to their Microsoft Office equivalents during migration. However, this conversion is not always perfect — complex Google Sheets with Apps Script macros, Google Docs with advanced formatting, and Google Slides with embedded Google-specific elements may require manual review after migration.

What does not migrate automatically includes Google Forms (no direct equivalent in Microsoft 365 without Power Apps or Microsoft Forms recreation), Google Sites (must be rebuilt in SharePoint), Google Keep notes (must be manually moved to OneNote or Sticky Notes), and Google Chat history (Teams does not import Google Chat conversations). Plan for these gaps in your migration timeline.

The Cross-Platform Migration Process

A successful Google Workspace to Microsoft 365 migration follows a structured process that accounts for both technical and human factors. The technical migration typically takes 2–4 weeks for a 100–500 user organisation, but the full project — including user training, communication, and post-migration support — should be planned over 6–10 weeks.

Begin by provisioning your Microsoft 365 tenant and verifying your domains. If your email domain is currently managed in Google Workspace, you will need to update your MX records as part of the cutover — but not yet. First, configure Entra ID (you can sync from an on-premise AD if you have one, or manage identities directly in the cloud), assign licences, and set up Exchange Online policies.

Next, configure the migration batch in the Exchange admin centre. You will need a Google Workspace super admin account and must enable API access for the Microsoft migration service. The migration runs in the background, copying email data from Gmail to Exchange Online mailboxes. Initial synchronisation can take hours to days depending on mailbox sizes and the number of mailboxes being migrated.

Drive migration runs in parallel. Using Migration Manager, you map Google Drive accounts to OneDrive for Business accounts, configure file conversion settings, and initiate the transfer. Large Google Drives (50 GB+) can take several days to fully migrate, so start this process early in the migration window.

The cutover itself — updating MX records from Google to Microsoft — should be scheduled for a Friday evening or Saturday morning, giving you the weekend to monitor mail flow and resolve any issues before Monday. After the DNS cutover, new mail flows to Exchange Online, and the migration service performs a final incremental sync to capture any messages that arrived in Gmail between the last sync and the MX change.

Migration Data Fidelity and Performance Benchmarks

One of the most common concerns UK organisations raise during migration planning is data integrity. Will all emails arrive intact? Will calendar appointments retain their correct times, attendees, and recurrence patterns? Will attachments survive the transfer? The answer, with properly planned migrations, is overwhelmingly yes — but the details matter.

For Exchange-to-Exchange Online migrations, data fidelity is exceptionally high. The migration service operates at the MAPI level, transferring messages with their full properties — sender, recipients, timestamps, read/unread status, categories, flags, and folder structure. Attachments, embedded images, and S/MIME encrypted messages all transfer correctly. The only common data loss scenario involves items in the Recoverable Items folder exceeding the target mailbox's recoverable items quota.

For Google Workspace to Microsoft 365 migrations, fidelity is slightly more nuanced. Gmail labels map to Outlook folders, but Gmail's multi-label system (where a single message can have multiple labels) does not translate perfectly to Outlook's single-folder model. Messages with multiple labels will be duplicated across the corresponding folders in Outlook. Google Calendar events transfer accurately, including attendees, recurrence, and reminders, but Google Calendar's "out of office" entries may require manual recreation in Outlook.

Migration Throughput and Performance

Migration speed is a critical planning factor, especially for UK organisations that need to minimise weekend working for IT staff. The throughput you can achieve depends on the migration method, source environment health, network bandwidth, and Microsoft's service-side throttling.

For Exchange hybrid migrations, Microsoft's migration service typically achieves 0.5–1 GB per mailbox per hour under optimal conditions. A 10 GB mailbox might take 10–20 hours to fully synchronise, though the initial sync runs in the background whilst the user continues working on the on-premise server. The final switchover — which is the only part that causes user disruption — typically completes in minutes.

For Google Workspace migrations, throughput depends heavily on Google's API rate limits. Microsoft's migration tool uses the Gmail API and Google Drive API, both of which have per-user and per-domain rate limits. With proper configuration (including enabling pre-provisioning and using a dedicated service account), you can expect to migrate approximately 1–2 GB per user per hour for email, and 0.5–1 GB per user per hour for Drive content.

Coexistence Strategies for Complex Environments

Not every migration can happen overnight. Large UK organisations — particularly those with thousands of users across multiple offices, complex compliance requirements, or dependencies on legacy systems — often need to operate in a coexistence state for weeks, months, or even years. Coexistence means that some users are on the new platform (Microsoft 365) whilst others remain on the old platform (on-premise Exchange or Google Workspace), and both groups need to communicate seamlessly.

Exchange Hybrid Coexistence

Exchange hybrid coexistence is the most mature and well-supported coexistence model. When properly configured, users on-premise and users in the cloud can share calendars, view free/busy information, send and receive email without any visible difference, and even access each other's shared mailboxes. The experience is truly seamless — a user in the cloud can book a meeting with a user on-premise, and both see the appointment in their calendars with correct free/busy data.

This coexistence model is underpinned by organisation relationships between on-premise Exchange and Exchange Online, OAuth authentication for server-to-server communication, and Entra Connect for continuous directory synchronisation. Mail flow during coexistence uses a centralised transport model (all outbound mail routes through one location, typically the on-premise server) or a decentralised model (each environment routes its own outbound mail). The centralised model is recommended for UK organisations that use third-party email security gateways, as it avoids the complexity of updating gateway configurations during the migration.

Google Workspace and Microsoft 365 Coexistence

Cross-platform coexistence between Google Workspace and Microsoft 365 is significantly more challenging than Exchange hybrid coexistence. There is no native federation between the two platforms, so achieving seamless communication requires additional tooling and configuration.

The most common approach is dual delivery during the transition period. You configure mail routing so that messages sent to your domain are delivered to both Google Workspace and Exchange Online during the migration. This ensures that no messages are lost during the cutover, but it also means users may receive duplicates — which must be communicated clearly to avoid confusion.

Calendar sharing between Google Calendar and Outlook Calendar is not natively supported during coexistence. Users on Google can see free/busy information for Microsoft 365 users if you configure Google Calendar Interop for Microsoft, but the setup is complex and limited compared to Exchange hybrid's native calendar sharing.

For UK organisations migrating from Google Workspace to Microsoft 365, we generally recommend minimising the coexistence period. Unlike Exchange hybrid, where you can comfortably operate in a mixed state for months, Google-to-Microsoft coexistence involves enough friction that a faster cutover — migrating all users within 2–3 weekends — is usually preferable.

Third-Party Migration Tools: When Native Isn't Enough

Microsoft's native migration tools are capable, but they have limitations — particularly around throughput, reporting, and complex scenarios like tenant-to-tenant migrations or multi-source consolidations. Several third-party tools have emerged to fill these gaps, and UK migration specialists (including Cloudswitched) often use them to deliver faster, more reliable migrations.

BitTitan MigrationWiz

BitTitan MigrationWiz is the most widely used third-party migration tool in the UK market. It supports a vast array of source and destination combinations — on-premise Exchange to Microsoft 365, Google Workspace to Microsoft 365, IMAP servers to Exchange Online, and even Microsoft 365 tenant-to-tenant migrations. MigrationWiz operates entirely in the cloud, requiring no software installation on-premise, and provides detailed per-mailbox migration reporting.

For UK organisations, MigrationWiz offers several advantages over native tools: faster migration speeds (it uses multiple parallel connections per mailbox), more granular scheduling (you can throttle migration during business hours and accelerate overnight), and comprehensive error reporting that makes troubleshooting straightforward. It is licensed per mailbox, with pricing typically ranging from £8–£12 per user mailbox depending on the migration type and volume.

Quest On Demand Migration

Quest (formerly Dell Software) offers a comprehensive migration platform that is particularly strong for large enterprise migrations. Quest On Demand Migration supports Exchange, Google Workspace, and other sources, and excels at complex scenarios involving Active Directory restructuring, multi-forest consolidations, and compliance-heavy migrations where detailed audit trails are required.

AvePoint and ShareGate

For organisations where the primary migration challenge is not email but collaboration content — SharePoint sites, Teams data, and file shares — AvePoint and ShareGate provide specialised tooling. Both are widely used in the UK market for SharePoint-to-SharePoint Online migrations, and they complement email migration tools nicely in projects where the full Microsoft 365 suite is being deployed.

User Experience During Migration: Minimising Disruption

Technical success means nothing if your users are confused, frustrated, or unable to do their jobs during the migration. The user experience during migration is where many IT projects fail — not because the technology breaks, but because the communication and change management are inadequate. Here is how to get it right.

Communication Strategy

Start communicating at least four weeks before the migration begins. Users need to understand what is changing, why it is changing, what they need to do (if anything), and where to get help. The communication should be multi-channel: email announcements, intranet posts, team briefings, and — for larger organisations — a dedicated migration FAQ page.

Be honest about what will change. If users are moving from Gmail to Outlook, do not pretend the experience will be identical. Acknowledge that there will be a learning curve, highlight the benefits (such as deeper integration with Teams and Office apps), and provide concrete resources for getting up to speed. If the migration will require users to reset their Outlook profile, reconfigure their mobile email, or log out and back in on a specific date, tell them exactly what to do with step-by-step instructions.

Outlook Profile and Mobile Device Management

One of the most common sources of post-migration support tickets is Outlook profile issues. When a mailbox is moved from on-premise Exchange to Exchange Online, the Outlook client needs to detect the new mailbox location and create a new profile. In most hybrid migration scenarios, Outlook's Autodiscover mechanism handles this automatically — the user may see a prompt to restart Outlook, and the transition is seamless.

However, for cutover migrations or environments where Autodiscover is not correctly configured, users may need to manually remove and re-add their Outlook profile. Provide clear, screenshot-laden instructions for this process, and have your helpdesk team ready for a surge of tickets on the first working day after cutover.

Mobile devices (iPhones, Android phones, iPads) typically handle the transition well if you use Exchange ActiveSync or the Outlook mobile app. For organisations using Microsoft Intune for mobile device management, the migration is particularly smooth — Intune can push updated email profiles to managed devices automatically, eliminating manual reconfiguration entirely.

Post-Migration Support and Hypercare

Plan for a "hypercare" period of 1–2 weeks immediately following the migration. During this period, augment your normal helpdesk staffing with additional support resources — either internal staff who have been trained on the new environment, or external consultants from your migration partner. The volume of support requests will spike in the first 48 hours and gradually taper off over the following week.

Common post-migration issues include: Outlook prompting for credentials repeatedly (usually a cached credential issue, resolved by clearing the Credential Manager), shared mailbox access not working (permissions may need to be re-applied in Exchange Online), mobile email not syncing (ActiveSync profile may need manual recreation), and calendar permissions lost on shared calendars (a known limitation of some migration methods that must be addressed manually).

Security and Compliance During Migration

Migration introduces a temporary period of elevated security risk. Data is in transit between platforms, user accounts may have new or changed credentials, and the attack surface is expanded whilst both old and new systems are operational. For UK organisations subject to GDPR, FCA regulations, or sector-specific compliance frameworks, managing this risk is non-negotiable.

UK GDPR Considerations

Under UK GDPR, you must ensure that personal data processed during migration remains protected and that any data transfers comply with applicable regulations. For most UK-to-UK migrations (on-premise server in the UK to Microsoft 365 with UK data residency), this is straightforward — but you must verify your Microsoft 365 tenant's data location settings to ensure mailbox data is stored in the UK.

Microsoft offers a Multi-Geo capability and, for UK tenants provisioned in the UK data centre region, mailbox data at rest is stored in UK data centres (London and Durham). However, during migration, data in transit passes through Microsoft's global network. Ensure your data processing agreement with Microsoft covers this transit, and document the migration as a processing activity in your ROPA (Record of Processing Activities) as required by Article 30 of UK GDPR.

If you are migrating from Google Workspace and your Google tenant stores data in EU/UK data centres, verify that your Microsoft 365 tenant is also configured for UK data residency before initiating the migration. A migration that inadvertently moves personal data from UK data centres to US data centres could constitute a restricted international transfer under UK GDPR.

Multi-Factor Authentication and Conditional Access

Migration is an excellent opportunity to strengthen your authentication posture. If your on-premise Exchange environment relies on single-factor authentication (username and password only), the move to Microsoft 365 should include enabling multi-factor authentication (MFA) for all users. Microsoft Entra ID's security defaults provide a baseline MFA configuration at no additional cost, and organisations with Microsoft 365 Business Premium or E3/E5 licences can implement conditional access policies for more granular control.

For UK organisations, we recommend implementing conditional access policies that require MFA for all external access (connections from outside your office network), block legacy authentication protocols (which cannot support MFA and are frequently exploited by attackers), and restrict access to compliant devices only (if using Intune for device management).

Data Loss Prevention During Transition

During the coexistence period, ensure that your data loss prevention (DLP) policies cover both environments. If you have DLP policies on your on-premise Exchange server, recreate them in Exchange Online Protection before migrating users. If you are moving from Google Workspace, replicate your Google DLP rules in Microsoft Purview DLP. There should be no gap in coverage during the transition.

Cost Analysis: Migration Investment by Path

Understanding the full cost of migration helps UK organisations budget accurately and avoid the unpleasant surprises that derail projects. Migration costs fall into several categories: Microsoft 365 licensing, migration tooling, professional services (internal IT time or external consultants), training, and the often-overlooked cost of lost productivity during the transition.

Licensing Costs

Microsoft 365 licensing is the ongoing cost that will persist long after migration is complete. For most UK SMEs, Microsoft 365 Business Premium (approximately £18.70 per user per month) provides the best value, bundling Exchange Online, Office applications, Teams, SharePoint, OneDrive, Intune, and Microsoft Defender. Larger organisations may opt for Microsoft 365 E3 (approximately £30.40 per user per month) or E5 (approximately £49.30 per user per month) for advanced compliance, analytics, and security features.

If you are migrating from Google Workspace, factor in the cost of running both platforms simultaneously during the coexistence period. You will be paying for both Google Workspace and Microsoft 365 licences for the duration of the migration — typically 1–3 months. Ensure your Google Workspace renewal date aligns with your migration timeline to avoid paying for a full additional year of Google licences.

Project Costs by Migration Type

The total project cost varies significantly depending on the migration path, organisation size, and complexity. Below are typical ranges for UK organisations based on our experience at Cloudswitched.

These figures include professional services (planning, execution, and post-migration support), third-party migration tooling where applicable, and a reasonable allowance for user training. They do not include ongoing Microsoft 365 licensing costs, which are a separate operational expenditure.

Common Migration Pitfalls and How to Avoid Them

After managing hundreds of migrations for UK organisations, we have identified the pitfalls that recur most frequently. Avoiding these mistakes can save your organisation weeks of troubleshooting and thousands of pounds in remediation costs.

Pitfall 1: Inadequate Discovery

The most expensive migration mistakes happen before the migration even begins. Failing to discover all mailboxes, public folders, distribution lists, and third-party integrations means your migration plan is built on incomplete information. The result: unexpected failures during migration, applications that stop working because their SMTP relay was not reconfigured, and users who discover post-migration that their shared mailbox data is missing.

Pitfall 2: Ignoring DNS TTL Values

Before changing your MX records, reduce the TTL (Time to Live) value to 300 seconds (5 minutes), at least 48 hours before the planned cutover. If your MX records have a TTL of 86400 (24 hours) — which is common for UK DNS providers — and something goes wrong during cutover, you will have to wait up to 24 hours for DNS caches to expire before a rollback takes effect. With a 300-second TTL, you can roll back in minutes.

Pitfall 3: Underestimating Public Folder Complexity

Public folders are the bane of many Exchange migrations. Organisations that have used Exchange for a decade or more often have thousands of public folders with complex permission structures, large individual folders (some exceeding 25 GB), and nested hierarchies that do not map cleanly to Microsoft 365's public folder model or SharePoint alternatives. Budget additional time and testing for public folder migration — it frequently takes longer than mailbox migration.

Pitfall 4: Neglecting Mobile Device Reconfiguration

Users who access email on mobile devices may need to remove and re-add their email account after migration, particularly if they use the native iOS Mail or Android Mail app rather than the Outlook mobile app. If you do not communicate this requirement clearly, your helpdesk will be overwhelmed with "my phone email stopped working" calls on Monday morning.

Pitfall 5: Skipping Post-Migration Validation

Migration is not complete when the last mailbox moves. You must validate that every mailbox has the correct data, every shared mailbox is accessible with proper permissions, every distribution list resolves correctly, every transport rule and DLP policy is functioning, and every third-party integration is working. Build a comprehensive post-migration validation checklist and work through it systematically.

Exchange Hybrid Migration UK: Specific Considerations

UK organisations face several region-specific considerations when planning an Exchange hybrid migration UK deployment. These are not merely theoretical concerns — they directly affect migration success and timeline.

UK Data Centre Selection

When provisioning your Microsoft 365 tenant, ensure that your data residency is set to the United Kingdom. Microsoft operates data centres in London and Durham, and UK-based tenants will have their Exchange Online mailbox data stored in these facilities. This is essential for compliance with UK GDPR and for organisations in regulated sectors where data sovereignty is a contractual or regulatory requirement.

If your Microsoft 365 tenant was originally provisioned with an EU or US data location (which can happen if the tenant was created before Microsoft's UK data centres were available, or if the admin who created the tenant selected the wrong region), you may need to request a data move through Microsoft's Move Program. This process can take several months and should be initiated well before migration begins.

Network Considerations for UK Offices

UK internet infrastructure varies significantly by location. London offices typically have access to high-speed fibre connections (1 Gbps+), but regional offices — particularly in rural areas of Scotland, Wales, and Northern Ireland — may rely on slower connections. Migration throughput is directly affected by the bandwidth available at your on-premise Exchange server's location.

For hybrid migrations where the on-premise server is in a location with limited bandwidth, consider scheduling the bulk of data synchronisation for overnight and weekend hours. If the bandwidth constraint is severe, some organisations temporarily provision a higher-bandwidth connection (such as a dedicated Ethernet circuit) for the duration of the migration, then decommission it once migration is complete.

Time Zone and Working Hours

The UK operates on GMT (or BST during summer months), which presents a relatively narrow window for after-hours migration. Unlike organisations spread across US time zones (where a migration starting at midnight Eastern time is only 9 PM Pacific), a midnight start in the UK means midnight for virtually all users. Plan migration batches to begin on Friday evenings after 8 PM and aim to have them complete by Sunday afternoon, giving you time for verification and troubleshooting before Monday morning.

For UK organisations with offices in other time zones (EU satellite offices, offshore teams in India, or US-based colleagues), coordinate your migration schedule to minimise disruption across all locations. It is rarely possible to find a window that is convenient for everyone, so prioritise the location with the most users and communicate clearly with others about expected disruption.

Advanced Migration Scenarios

Beyond the standard migration paths, several advanced scenarios arise frequently in UK organisations. These require additional planning and specialised expertise.

Multi-Source Consolidation

Some UK organisations need to consolidate multiple email platforms into a single Microsoft 365 tenant simultaneously. This is common during mergers and acquisitions, where one company runs on-premise Exchange and the acquired company uses Google Workspace. The migration plan must account for two different source platforms, potentially different Active Directory forests (or no AD at all for the Google Workspace company), and the need to merge two sets of users into a single directory.

Multi-source consolidations require careful sequencing. We typically recommend migrating the Exchange environment first (using hybrid migration, which provides the smoothest experience), then migrating the Google Workspace environment once the Exchange migration is stable. Running both migrations simultaneously is technically possible but dramatically increases complexity and risk.

Tenant-to-Tenant Migration

Tenant-to-tenant migration — moving mailboxes from one Microsoft 365 tenant to another — arises during corporate restructuring, divestitures, or when an organisation outgrows a tenant originally provisioned by a reseller. Microsoft introduced cross-tenant mailbox migration as a native feature, but it has limitations: it requires both tenants to be in the same Microsoft cloud (both in Commercial, or both in GCC), and it does not migrate Teams data, SharePoint content, or OneDrive files.

For comprehensive tenant-to-tenant migrations in the UK, third-party tools like BitTitan or Quest are typically required. These tools can migrate email, OneDrive, SharePoint, and Teams data between tenants, and they provide the detailed reporting that UK compliance requirements demand.

IMAP Migration from Legacy Systems

Some UK organisations are not migrating from Exchange or Google Workspace at all — they are migrating from older IMAP-based email systems. Hosted email services from UK providers like 123 Reg, Fasthosts, or Heart Internet, as well as legacy Linux-based email servers running Dovecot or Zimbra, can all be migrated to Microsoft 365 using IMAP migration.

IMAP migration is the most limited method: it migrates email messages only (no contacts, calendars, or tasks), and it only migrates inbox and folder contents (no rules, signatures, or auto-replies). However, for small organisations with simple email needs, it provides a low-cost path to Microsoft 365 without the complexity of hybrid or cross-platform migration.

Choosing the Right Migration Path: Decision Framework

With so many options available, how do you choose the right migration path for your UK organisation? The decision depends on several factors: your current platform, organisation size, tolerance for downtime, compliance requirements, budget, and internal IT capability. Here is a decision framework to guide your choice.

If You Run On-Premise Exchange with Fewer Than 150 Mailboxes

A cutover migration is your simplest option. It eliminates the complexity of hybrid configuration, requires no ongoing coexistence management, and can be completed in a single weekend. The only scenario where we would advise against cutover for a sub-150 user organisation is if you have complex public folder structures, extensive third-party integrations, or a zero-downtime requirement — in which case, hybrid migration (even for a small organisation) provides a safer path.

If You Run On-Premise Exchange with 150–5,000 Mailboxes

Hybrid migration is the clear choice. The initial investment in configuring hybrid is repaid many times over in migration flexibility, user experience, and reduced risk. The Exchange hybrid migration UK model allows you to migrate at your own pace, move users back to on-premise if issues arise, and maintain seamless communication between migrated and non-migrated users throughout the project.

If You Run Google Workspace

Use Microsoft's native migration tools for organisations up to 500 users, augmented by BitTitan MigrationWiz for larger environments or those requiring faster throughput. Plan for a rapid cutover rather than extended coexistence, invest heavily in user training, and budget additional time for Google Drive to OneDrive migration and document format conversion validation.

If You Have a Complex Multi-Platform Environment

Engage a specialist migration partner. Multi-source consolidations, tenant-to-tenant moves, and hybrid-to-cloud migrations with extensive compliance requirements are not DIY projects. The cost of professional services is a fraction of the cost of a failed migration — in both direct remediation costs and lost productivity.

Post-Migration Optimisation

Migration is not the end of the project — it is the beginning of your Microsoft 365 journey. Once all mailboxes are in the cloud and the old environment has been decommissioned, there are several optimisation steps that deliver immediate value.

Security Hardening

With all users now on Microsoft 365, implement a comprehensive security baseline. At minimum, this should include: security defaults or conditional access policies requiring MFA, blocking of legacy authentication protocols, anti-phishing policies in Microsoft Defender for Office 365, Safe Attachments and Safe Links policies for protection against malicious content, and a Unified Audit Log retention policy aligned with your compliance requirements.

Teams and Collaboration Adoption

Many organisations migrate email and then leave Teams, SharePoint, and OneDrive largely untouched. This is a missed opportunity. Microsoft Teams can replace internal email for most team communication, SharePoint can consolidate departmental file shares, and OneDrive can eliminate local file storage on user devices. A structured adoption programme — starting with a pilot team and expanding department by department — drives real productivity gains.

Ongoing Monitoring and Governance

Establish ongoing governance for your Microsoft 365 environment. This includes regular access reviews (who has access to what?), licence optimisation (are you paying for licences that are not being used?), mailbox size monitoring, and compliance monitoring through Microsoft Purview. UK organisations in regulated sectors should also establish a regular eDiscovery testing cadence to ensure they can respond to regulatory requests efficiently.

Why UK Organisations Choose Cloudswitched for Migration

At Cloudswitched, we have managed hundreds of Exchange migration to 365 and Google Workspace to Microsoft 365 projects for UK organisations across every sector. Our London-based team understands the specific challenges that UK businesses face — from GDPR compliance and FCA regulatory requirements to the practical realities of migrating across UK office locations with varying network capabilities.

We take a partnership approach. We do not simply run a migration tool and hand you the keys — we plan with you, execute alongside you, and support you through the transition. Every migration includes a comprehensive discovery phase, a documented migration plan with rollback procedures, a dedicated project manager, 24/7 support during the cutover weekend, and a two-week hypercare period for post-migration issue resolution.

Whether you are migrating 50 mailboxes from on-premise Exchange via a straightforward cutover, executing a complex hybrid migration for 2,000 users across multiple UK locations, or navigating a cross-platform move from Google Workspace, we have the experience and tooling to deliver a smooth, successful migration.

Frequently Asked Questions

How long does an Exchange to Microsoft 365 migration take?

For a cutover migration with fewer than 150 users, the actual migration can be completed in 1–3 days. For hybrid migrations with 250–1,000 users, the full project typically runs 6–10 weeks including planning, pilot, batch migration, and post-migration support. The data transfer itself runs in the background, with the user-facing cutover taking just minutes per mailbox.

Will users lose any email during the migration?

No. With properly planned migrations — whether cutover, hybrid, or cross-platform — no email is lost. Hybrid migrations use continuous synchronisation, so data is copied to Exchange Online whilst users continue working on the on-premise server. The final sync captures any messages received between the last sync and the cutover. For Google Workspace migrations, the same incremental sync approach is used.

Can we migrate from Google Workspace to Microsoft 365 without downtime?

Effectively yes, though there will be a brief period (typically 1–4 hours) during the DNS MX record cutover where some users may experience delayed message delivery. With proper planning — reducing DNS TTL values in advance, scheduling the cutover for Saturday morning, and running pre-migration data sync — the user-visible impact is minimal.

Do we need to keep our on-premise Exchange server after migration?

For cutover migrations, the on-premise server can be decommissioned once you have confirmed all data has migrated successfully and maintained a backup for a reasonable retention period (we recommend 90 days). For hybrid migrations, you need to maintain at least one on-premise Exchange server for directory management purposes if you use Entra Connect — though Microsoft is working to remove this requirement in future releases.

What happens to our existing email signatures?

Email signatures stored in Outlook are client-side settings and migrate with the user's Outlook profile. However, server-side signatures applied via Exchange transport rules must be recreated in Exchange Online. If you use a third-party signature management solution (such as Exclaimer or CodeTwo), check compatibility with Exchange Online and update the configuration as part of your migration plan.

Is the migration GDPR compliant?

Yes, provided your Microsoft 365 tenant is configured for UK data residency. Both Microsoft and Google are compliant with UK GDPR as data processors, and the migration process does not change the lawful basis for processing personal data contained in email. However, you should document the migration in your ROPA, update your privacy notices if necessary, and ensure your data processing agreements are current with both providers during the coexistence period.