Migrating From Google Workspace to Microsoft 365: A UK Business Step-by-Step Guide

A Google Workspace to Microsoft 365 migration is not an email change. It is a change of identity provider, file platform, meeting platform, compliance tooling and device management model, all of which happen to be bundled behind the same sign-in box. Organisations that treat it as “moving the mail” are the ones that end up with a working inbox on Monday and a fortnight of unpicking calendar invitations, scan-to-email failures on the office printer and a shared drive nobody can find.

This guide walks the full path a UK business actually has to take: auditing what is in the Workspace tenant before anyone touches a migration tool, choosing between a staged and a full cutover on the basis of mailbox count and risk appetite rather than preference, moving mail, contacts and calendars with the native Microsoft tooling or a third-party alternative, dealing with Google Drive separately because it does not come along for the ride, re-pointing DNS and MX records without losing a day of inbound mail, and the post-migration checklist that catches the items most teams discover three weeks late. It covers realistic 2026 UK costs, the throughput numbers that determine how long the data movement really takes, and the specific things that do not survive the move at all. The scope here is M365 migration UK work for organisations between roughly ten and five hundred users, which is where the majority of these projects sit.

What a migration between the two platforms actually involves

Google Workspace and Microsoft 365 are both suites, but they are assembled differently, and the differences decide how much work the move is. In Workspace, Gmail is the centre of gravity: labels rather than folders, search rather than filing, Drive as a flat pool of files whose organisation is largely a matter of sharing links, and Google itself as the identity provider for whatever else the organisation has connected. In Microsoft 365, Exchange Online is a mailbox service with a folder hierarchy, SharePoint Online and OneDrive are structured document libraries with inherited permissions, Entra ID is a full directory that other systems bind to, and Teams sits across all of it. Data moves from one to the other, but the shapes are not the same, and every migration involves deciding what to do where the shapes do not line up.

The practical consequence is that a migration project has four largely independent workstreams, and they have very different difficulty profiles. Mail, calendar and contacts move well — Microsoft publishes a native Google Workspace migration path in the Exchange admin centre, and the fidelity is good. Files move with more friction, through Migration Manager in the SharePoint admin centre or a third-party tool, and the friction is about permissions, Google-native file formats and link rot rather than the bytes themselves. Identity and access is a manual re-implementation: anything that used Google as its sign-in provider needs re-pointing at Entra ID, and nothing automates that. Collaboration history — Google Chat, Spaces, Sites, Forms, Apps Script — has no supported migration path at all and is either exported, rebuilt or abandoned deliberately.

Most of the failure in these projects lands in the third and fourth workstreams, because the first two have vendor tooling and dashboards and the last two only have an inventory that somebody has to build by hand. A business with 60 mailboxes and a tidy Drive can be fully migrated in three weeks. The same business with a Google-authenticated CRM, four multifunction printers relaying through Google’s SMTP service, a decade of Apps Script automations and a Vault legal hold takes three months, and almost none of that additional time is spent moving email.

Before any of it starts, one decision made during tenant creation is worth flagging because it cannot be reversed: the country you select when you sign up for the Microsoft 365 tenant sets the data residency for core customer data, and Microsoft does not allow that to be changed afterwards. A UK organisation that wants its mailbox and SharePoint data held in UK datacentres selects United Kingdom at sign-up. Getting this wrong means a full tenant rebuild later, which is the single most expensive mistake available at this stage and takes about ten seconds to avoid.

The numbers that shape a UK migration in 2026

Four figures do more to determine the shape of a migration plan than anything else: how much mail there is, how fast it can be ingested, how long the licensing overlap runs and how much of the project is data movement versus everything else. Getting rough values for these before the project starts is what separates a plan from a hope.

The mailbox ceiling matters because Google Workspace pools storage across the organisation and Microsoft 365 does not. A Workspace Business Standard tenant gives 2 TB pooled across all users, which in practice means one person can be sitting on 300 GB of Gmail while forty colleagues use eight gigabytes each, and nobody has ever had to notice. Exchange Online allocates per mailbox: 50 GB on Business Basic, Business Standard, Business Premium and E1, and 100 GB on E3 and E5. Run a storage report on the Google side before you size licences, because the answer determines whether one or two people need a higher tier, an auto-expanding archive, or a conversation about deleting fifteen years of newsletters.

The ingestion figure is the one most plans get wrong. Migration throughput is not governed by your internet connection — the data moves between Google’s cloud and Microsoft’s, not through your office — but by throttling at both ends. Google’s Gmail API applies per-user and per-project quota limits, and Exchange Online applies its own ingestion throttling that tightens when a tenant pushes hard. Between half a gigabyte and two gigabytes per mailbox per hour is the honest planning range, with parallelism across mailboxes the main lever. Forty mailboxes averaging 15 GB is 600 GB, and with twenty running concurrently that is realistically two to four days of elapsed time, not an evening. Plan the first sync to start at least a week before cutover.

The overlap figure is a cost line people try to delete and should not. Keeping Google Workspace live for two or three months after cutover costs a few hundred pounds and buys the ability to go back for the message somebody swears was never migrated, to run a Vault export that was forgotten, and to keep every Google Docs link ever pasted into an email or a contract working while the organisation reindexes itself. Cancelling on cutover day saves about £600 on a 60-user tenant and creates a category of problem that has no fix.

The final figure is the planning one. In a well-run project the mail migration is a background task that a tool performs while the team does the work that actually consumes the calendar: the application inventory, the DNS change, the identity re-pointing, the printer and line-of-business SMTP rework, the device reconfiguration and the user communications. Budget accordingly, and see our IT roadmap and technology strategy guide for how a platform move of this size sits alongside the rest of a year’s plan.

Where the project time actually goes

The chart below reflects how effort distributes across a typical 60-to-150-user migration delivered over eight to twelve weeks. It is drawn from the shape of these projects rather than from any single one, and the proportions shift with the estate — a document-heavy organisation pushes the Drive bar up, a Google-authenticated software estate pushes identity up — but the ranking is remarkably stable.

Two things stand out. The first is that the DNS cutover — the step everybody is nervous about — is the smallest bar on the chart. It is genuinely low-effort when the preparation is done, and genuinely catastrophic when it is not, which is a different property from being hard. The second is that discovery is the largest, and it is the one most often compressed because it produces no visible progress. Every hour not spent on the audit reappears later as an unplanned incident, usually during the week when the team has the least slack.

Note also that “Drive to SharePoint” sits second. Organisations consistently under-scope this because file migration tools report high success rates, and they are telling the truth: the files copy. What the success rate does not measure is whether the permission model came across in a form anybody understands, whether the two hundred Google Docs links embedded in old emails and contracts still resolve, and whether the team can find anything in the new structure. That is a change-management problem wearing a technical costume.

What the migration costs — licensing, tooling and delivery

There are three cost lines in a platform move and they behave differently. Licensing is a permanent change to the monthly run rate. Migration tooling is a one-off, usually priced per mailbox. Delivery is the labour, whether that is internal time that does not appear on an invoice or an external fixed price that does. The table below gives the shape for a 60-user UK business at the time of writing; list prices move, so confirm current figures against the Microsoft and Google price lists before committing them to a business case.

The licensing comparison usually surprises people in both directions. Microsoft 365 Business Standard and Google Workspace Business Standard sit within a pound or so of each other, so the headline per-seat cost is close to a wash and should not be the reason for the move. Business Premium is where the economics change: at roughly eighteen pounds it bundles device management, conditional access, advanced threat protection and data-loss prevention that a Workspace organisation would typically buy as Workspace Enterprise plus separate tooling. For an organisation that needs Intune and conditional access anyway — which, post Cyber Essentials v3.2 and its successors, is most of them — Business Premium is frequently cheaper in aggregate than the Google equivalent plus the bolt-ons, even though it looks more expensive per line.

The tooling line is genuinely optional. Microsoft’s native Google Workspace migration in the Exchange admin centre handles mail, calendar and contacts at no additional cost, and Migration Manager in the SharePoint admin centre handles Google Drive and shared drives the same way. Third-party platforms — BitTitan MigrationWiz, Quest On Demand Migration, CloudM Migrate, AvePoint and others — earn their fee when you need finer control: scheduling by department, delta syncs on a defined cadence, mapping Gmail labels to a specific folder structure, migrating Google Chat history, or reporting granular enough to hand to an auditor. Below roughly fifty mailboxes with a simple Drive, the native path is usually sufficient. Above two hundred, or with any meaningful complexity, the tooling pays for itself in the reporting alone.

The one cost line that never appears in the business case and always materialises is rework on the long tail: the printer that cannot scan to email any more, the accounts package that sent invoices through Google’s SMTP relay, the booking system that used Google sign-in, the monthly report that a Google Apps Script generated at 6am on the first of the month. Allow ten to fifteen per cent of the delivery budget as contingency for these, because they are discovered rather than planned.

Cutover method — staged coexistence versus a full switch

There are two viable ways to move, and the decision is driven by mailbox count, tolerance for a weekend of disruption and how much complexity the organisation can absorb in its mail routing. Both are legitimate. The mistake is drifting into one without deciding.

For the overwhelming majority of UK businesses in the ten-to-two-hundred-user band, the full cutover is the better choice, and it is marked as the recommended option above for a specific reason: coexistence between Google Workspace and Microsoft 365 is harder than it looks and the difficulty is invisible until you are in it. During a staged migration the domain is shared between two mail platforms, which means one of them must be authoritative for the domain and route unrecognised addresses to the other. Free/busy lookups do not work across the boundary without additional configuration, so for the whole coexistence window, half the organisation cannot see the other half’s calendar availability. Distribution lists and shared mailboxes have to exist in one place and be reachable from the other. Internal mail crosses the public internet and picks up the anti-spam behaviour of both platforms on the way.

Every one of those is solvable. None is solvable for free, and the effort is spent building a temporary state that is then dismantled. A sixty-person business that runs a staged migration typically spends more total engineering hours on the coexistence configuration than a full cutover would have taken end to end, and carries a degraded calendar experience for a month in exchange.

The threshold moves when the mailbox count rises, because the failure mode of a full cutover is that the entire organisation hits the service desk at once on Monday morning. Above roughly a hundred and fifty users, or where the business runs shifts and has no genuinely quiet window, the staged approach earns its complexity. Multi-site organisations with distinct departments — a head office and three branches, say — can also take a middle path: a full cutover per site over consecutive weekends, which keeps each individual cutover simple while limiting how many people are affected at once. That works well when the sites do not share many internal meetings, and badly when they do.

The pre-migration audit — scoring what is actually in the tenant

Discovery is the largest workstream and the one with the least tooling. The Google Admin console will tell you about users, storage and devices; it will not tell you which third-party applications authenticate through Google, which Apps Script projects run on a schedule, or which departmental process depends on a Google Form feeding a Sheet. That has to be assembled from admin reports, OAuth token lists and conversations with the people who do the work. The grids below cover what to enumerate and where the risk typically concentrates.

Three of those rows deserve specific attention because they account for most post-migration incidents. Gmail filters do not migrate. Not with the native tool, not with most third-party tools. If someone in finance has forty filters routing supplier mail into labelled buckets, those rules cease to exist the moment they start using Outlook, and the first they will know about it is an inbox that suddenly receives everything. The fix is unglamorous: export each user’s filter list from Gmail settings as XML during discovery, and either rebuild the important ones as Outlook rules or give users a printed list of what they had so they can rebuild their own. Doing this for the ten heaviest filter users covers most of the pain.

Google Vault holds are the compliance trap. A hold in Vault preserves data inside the Google tenant; it does not travel, and it does not exist in Microsoft 365. If the organisation is under any legal or regulatory obligation to preserve mail — live litigation, a regulatory investigation, a sector-specific retention requirement — that preservation must be re-established in Microsoft Purview before the Google tenant is decommissioned, and any data under hold that is not being migrated must be exported and retained separately. This is a point to involve whoever owns compliance rather than treating it as an IT decision. The ICO’s accountability expectations mean the organisation, not the platform, carries the obligation.

The SMTP relay row is the one that produces a Monday-morning ticket queue. Multifunction printers configured to scan to email, backup systems that send job reports, accounting packages that email invoices, alerting from a network monitoring platform — anything that was pointed at Google’s SMTP relay or authenticated as a Workspace user to send mail stops working when the mailbox moves. Walk the estate and list every device and application that sends email without a human pressing send. Our guide to proactive network monitoring for UK businesses covers the alerting side of the same inventory problem.

The migration timeline — what an eight-week project looks like

The sequence below is a full cutover for an organisation of around sixty to a hundred users with a moderate Drive estate. Staged migrations stretch weeks five through seven into a longer coexistence window but the preparation is identical. The ordering matters more than the durations: several of these steps have hard dependencies on the one before, and compressing the audit is what breaks the later weeks.

The step most often skipped is week six. It produces no technical artefact and it is the difference between a hypercare week of orientation questions and one of genuine incidents. A single side of A4 telling each person what their new sign-in is, where their files now live, what will not come across and who to contact removes a substantial fraction of the Monday queue. Send it twice: once a week before, once on the Friday.

The DNS cutover — changing MX records without losing mail

This is the step with the shortest duration and the highest consequence, and it is entirely mechanical if the preparation is done. The principle to hold on to is that mail is not lost when MX records change — sending servers retry for hours or days when delivery fails, and the real risk is not loss but silent misdelivery into a mailbox nobody is watching. The failure that actually hurts is mail arriving successfully in the old Google mailbox for three days after cutover because a record was left pointing at Google, while everybody assumes it is quiet because Friday was quiet.

At least forty-eight hours before the cutover, reduce the time-to-live on every record you intend to change to 300 seconds. TTL is a cache instruction to the rest of the internet, and lowering it on the day is useless because the old, long TTL is already cached everywhere. Do this in week five, verify it has propagated, and the actual change then takes effect in minutes rather than hours.

The records that change on the night, in order:

1. MX — replace the five Google MX entries with the single Microsoft record, <tenant>-com.mail.protection.outlook.com, at priority 0. Remove the Google records rather than leaving them at a higher priority; a lingering low-priority Google MX will happily accept mail whenever Microsoft’s endpoint is momentarily busy.
2. SPF — amend the existing TXT record to v=spf1 include:spf.protection.outlook.com -all, plus any legitimate third-party senders such as a marketing platform or an invoicing system. Remove include:_spf.google.com only once nothing is still sending through Google. There must be exactly one SPF record on the domain; two is a permanent fail, and it is a surprisingly common outcome of a migration.
3. DKIM — publish the two CNAME records, selector1._domainkey and selector2._domainkey, pointing at the tenant-specific targets given in the Microsoft Defender portal, then enable signing for the domain. Signing cannot be enabled until the CNAMEs resolve, so publish them a day early.
4. Autodiscover — add a CNAME for autodiscover pointing to autodiscover.outlook.com. Without it, Outlook profile creation becomes a manual exercise repeated on every device, which is a quiet way to add two hundred support minutes to the first week.
5. DMARC — publish or amend _dmarc as a TXT record. Start at p=none with a reporting address so you can see what is sending on your behalf, and tighten to quarantine and then reject over the following weeks once the reports are clean. Moving straight to reject during a platform migration is how legitimate invoicing mail ends up silently discarded.
6. Device enrolment — if Intune is in scope, add the enterpriseregistration and enterpriseenrollment CNAMEs pointing to Microsoft’s endpoints. Not urgent for mail flow, easy to forget until the first device enrolment fails.

Immediately after the change, send a test message from an external address — a personal account on an unrelated provider — and confirm it lands in the new mailbox. Then reply and check the headers on the receiving end for an SPF pass and a DKIM signature. Two tests, five minutes, and they catch the overwhelming majority of what goes wrong. Repeat the inbound test on Saturday morning and again Sunday evening, because a record that was cached somewhere can surface a problem hours later.

Data fidelity — what survives the move and what does not

Migration tooling reports success in terms of items transferred, which is an honest measure of the wrong thing. What matters to the person using the system is whether the thing they relied on still behaves the way it did. The figures below express typical fidelity — how much of each category arrives in a usable state — rather than transfer success rates, and they are the numbers worth setting expectations against.

Take the label-to-folder row first, because it produces more confusion than any other. Gmail labels are tags: a message can carry five of them at once and lives in one place. Outlook folders are locations: a message is in exactly one. Migration tools resolve the mismatch by either duplicating the message into every corresponding folder, which inflates the mailbox and confuses everyone, or filing it under one label and applying the rest as Outlook categories, which is the better behaviour and is what the native Microsoft tool does reasonably well. Tell users this in advance. “Your labels become folders and categories, and a message that had three labels now sits in one folder with three categories on it” is a sentence that prevents a dozen tickets.

Recurring events with exceptions are the calendar problem. A weekly team meeting where three individual occurrences were moved, one was cancelled and one had a different attendee list is stored differently by the two platforms, and the reconstruction is imperfect. The pragmatic approach is to accept it: migrate the calendar, then ask meeting organisers to check anything recurring in the four weeks after cutover. Trying to achieve perfect recurring-event fidelity is a poor use of project time.

The Meet links row is the one users notice within an hour. Every calendar invitation created in Google carries a Google Meet joining link, and those links survive the migration as text but depend on a Google account to work properly. After cutover, standing meetings need their conferencing re-created as Teams meetings. The cleanest approach is to have organisers delete and re-issue their recurring meetings in the week after cutover rather than attempting to patch links individually — it is ten minutes per organiser and it fixes the problem permanently.

The final row is the honest one. Gmail filters, signatures and Google Chat history do not migrate at all. Chat history can be exported through Google Takeout or Vault and retained as an archive for compliance, but there is no supported path into Teams. Decide explicitly whether that history matters, export it if it does, and tell the organisation that Chat conversations are not coming with them. Discovering this by accident in week seven is considerably worse than being told in week one.

The half-finished migration — why file content lags behind mail

There is a recognisable pattern in platform moves that do not land cleanly. Mail cuts over on schedule, everybody gets Outlook working within a fortnight, and the file migration quietly stalls. Six months later the organisation is running Microsoft 365 for communication and still logging into Google Drive for documents, paying for both, with a security model that spans two tenants and an access review that nobody can complete. It is the most common way one of these projects ends up as a permanent half-state.

The cause is structural rather than technical. Mail has a hard forcing function: the MX record changes and there is no going back, so the work happens. Files have no equivalent. Google Drive keeps working perfectly well after the mail cutover, everyone knows where their documents are, and there is no day on which anything breaks. Without a forcing event, the file migration competes with everyday work and loses, every week, indefinitely.

The fix is to manufacture the forcing function. Set a date on which Google Drive becomes read-only — which is a single policy change in the Google Admin console, not a deletion — and communicate it from week one as a fixed part of the project rather than a later decision. Read-only is the right setting because it removes the ability to create divergence while preserving every existing link and every file for reference. Run it for a month, then a further month with access restricted to a handful of administrators, then decommission.

The second half of the fix is accepting that the file migration is not a copy operation. Google Drive is organised around ownership and link-sharing; SharePoint is organised around sites and libraries with inherited permissions. A one-to-one copy produces a SharePoint estate that mirrors Google’s sprawl and satisfies nobody. The migration is the one realistic opportunity to impose a structure, and taking it costs perhaps two days of workshops with department leads to agree what the sites and libraries should be. Skipping that step is what produces the second most common outcome: a successful file migration that everybody hates.

Google Drive to SharePoint and OneDrive — the specifics

File migration deserves its own treatment because the native tooling handles it separately from mail and the failure modes are entirely different. Migration Manager, in the SharePoint admin centre, connects to Google Drive and shared drives with an administrator’s consent and moves content into OneDrive and SharePoint document libraries. It is capable, free with the licence, and has a set of edges worth knowing before you start rather than after.

Google-native files convert. Docs, Sheets and Slides are not files in the ordinary sense — they are database records rendered by Google’s editors, and they have no meaningful existence outside it. During migration they are exported to their Office equivalents: Docs to .docx, Sheets to .xlsx, Slides to .pptx. The document body converts reliably. What does not survive is the version history, most comments and suggestions, and any in-document automation. A Sheet with complex formulas will usually convert, but one that leans on Google-specific functions such as IMPORTRANGE, GOOGLEFINANCE or QUERY will not, and a Sheet driven by Apps Script certainly will not. Identify the business-critical spreadsheets in discovery and plan to rebuild them.

Some Google formats do not convert at all. Google Forms, Sites, Drawings, Jamboard content, My Maps and Apps Script projects have no Microsoft equivalent that a migration tool can produce. Forms that feed operational processes need rebuilding as Microsoft Forms or a Power Apps form; Sites need rebuilding as SharePoint pages; Apps Script automations need rebuilding as Power Automate flows or replaced with something else. None of this is difficult in isolation. All of it is invisible until you look for it.

File names and paths have rules. SharePoint rejects a handful of characters that Google Drive allows, has a URL length limit of 400 characters for the full path, and objects to names ending in a full stop or containing leading or trailing spaces. On a Drive estate accumulated over a decade this produces a list of exceptions on every run. Good tooling reports them; the remediation is renaming, which is faster if you flatten deep folder structures at the same time rather than preserving a nine-level hierarchy that existed because nobody ever tidied it.

Permissions do not map cleanly. This is the 70% row in the fidelity chart. Google’s model is per-file and per-folder with link-based sharing and an owner; SharePoint’s is per-site and per-library with inheritance. Tools do their best, and the result is usually functional but not identical, with the biggest divergences on files shared by link to people outside the organisation and files owned by users who have left. Audit external sharing before the migration, because a migration that faithfully reproduces an over-permissive Google estate has simply relocated a security problem. That review sits naturally alongside the access-control work in a Cyber Essentials Plus technical audit.

Links break, and this is the long tail. Every Google Docs URL pasted into an email, a contract, a project plan or a supplier’s system continues to point at Google. Migration does not rewrite them, and there is no tool that can rewrite the ones that live outside your estate. Keeping the Google tenant in read-only mode for a defined period keeps those links resolving while the organisation naturally replaces the ones that matter. Accept that some will eventually rot, and prioritise fixing links in documents that are still active rather than attempting a comprehensive sweep.

One bandwidth note: the migration itself is cloud-to-cloud and does not touch the office connection, but the aftermath does. When users first sign into OneDrive and Outlook, clients download local caches — OST files and synced OneDrive content — and sixty people doing that on the same Monday morning is a substantial and entirely predictable spike. If the office runs on a connection with modest headroom, stage the first sign-ins across the week or pre-stage laptops. The planning approach in our bandwidth planning guide applies directly.

The post-migration checklist — the twelve things teams miss

Everything below is a real item that has ended up on a post-migration issue list. None of them is difficult. All of them are invisible until somebody tries to do the thing that no longer works, which is usually a week after the project was declared complete. Work through the list in the first fortnight after cutover.

1. Re-point every application that used Google as its sign-in provider. Go through the OAuth and SAML app list from discovery one by one and reconfigure each to use Entra ID, or to use local credentials where single sign-on is not available. Anything missed becomes a lockout the moment the Google tenant is disabled, and the lockout will be discovered by whoever needs that system most urgently.
2. Fix scan-to-email on every multifunction printer. Plan for Microsoft’s direction of travel here: client SMTP submission with basic credentials is being retired in Exchange Online, so configuring a device with a mailbox username and password is not a durable answer. Use direct send to the tenant’s own domain where the device supports it, or a dedicated connector with an authenticated IP, or a separate relay service. Decide the pattern once and apply it to every device.
3. Re-create shared and delegated mailbox access. Gmail delegation becomes Exchange Full Access and Send on Behalf permissions. It does not migrate. Anyone who managed a colleague’s inbox or a departmental address will find it gone on day one.
4. Rebuild room and resource calendars as room mailboxes. Then check the booking policies — whether the room auto-accepts, how far ahead it can be booked, and whether recurring bookings are permitted. Default behaviour differs from Google’s and the difference shows up as double-booked meeting rooms.
5. Re-issue recurring meetings with Teams conferencing. Ask each organiser to delete and re-create their standing meetings rather than editing them. Embedded Google Meet links do not become Teams links.
6. Restore filters and signatures for heavy users. Identify the twenty people with the most Gmail filters during discovery and give them their exported list. Set organisational signatures centrally if the business wants consistency — the migration is the natural moment.
7. Re-establish retention and legal hold in Microsoft Purview. Any Google Vault hold must have an equivalent before the Google tenant goes. Document what was preserved, where it now lives, and who signed it off.
8. Run a Google Takeout or Vault export of anything not migrating. Chat history, Sites, Forms responses, Apps Script source. Store the export somewhere governed, not on a laptop.
9. Tighten DMARC from monitoring to enforcement. Leave it at p=none for three to four weeks after cutover, read the aggregate reports, confirm every legitimate sender is passing, then move to quarantine and finally reject.
10. Review external sharing across the new SharePoint estate. Check what came across as anonymous or organisation-wide links and set a sharing policy that reflects what the business actually intends.
11. Reconfigure mobile devices and remove the old accounts. Users need Outlook mobile and, where Intune is in scope, enrolment. Removing the Google account from the device afterwards prevents the confusion of two mail apps showing different halves of the same inbox.
12. Reduce Google licences before cancelling, and diarise the cancellation. Drop to a handful of administrative seats after the read-only period, then cancel on a date that is in somebody’s calendar. Unmanaged overlap has a way of becoming a permanent line on the direct debit.

Migration readiness — scoring the organisation before you commit

Readiness is not about whether the migration is possible; it always is. It is about how much unmodelled work sits between the decision and a clean finish. The benchmark below is the score an organisation would want before committing to a cutover date, assessed across six areas: inventory completeness, identity surface, file estate tidiness, compliance position, connectivity headroom and organisational capacity to absorb change.

Seventy-two is not an arbitrary number; it reflects where the remaining unknowns are small enough to be handled inside a hypercare week rather than becoming a second project. An organisation scoring in the fifties can still migrate perfectly well, but should expect the timeline to extend and should not commit to a public cutover date until the inventory is complete. The gap is almost always in two places: the application and integration inventory, and the file estate.

Score each area honestly out of a hundred and take the lowest, not the average, because these areas do not compensate for one another. A pristine file estate does not help if fourteen applications authenticate through Google and nobody has the list. Specifically:

• Inventory completeness — can you produce, today, a list of every application that sends mail or authenticates through Google? If no, you are below sixty regardless of everything else.
• Identity surface — how many external systems treat Google as the identity provider, and does each have a documented alternative?
• File estate — is there an agreed target structure in SharePoint, or is the plan to copy Drive as-is?
• Compliance position — are Vault holds and retention obligations documented, with an owner outside IT?
• Connectivity headroom — can the office absorb sixty simultaneous first-sync clients without degrading?
• Change capacity — is there a quiet fortnight in the business calendar, and is there someone whose job during hypercare is this and nothing else?

The last one is the most frequently overlooked and the most predictive. A migration scheduled into the two weeks before a year end, a major client deadline or a peak trading period will be judged a failure regardless of how well it was executed, because there is no organisational tolerance for the ordinary friction of a platform change.

Common mistakes in a Workspace to Microsoft 365 move

These are the errors that recur across projects of every size, and they share a characteristic: each one is cheap to avoid in advance and expensive to fix afterwards.

• Selecting the wrong country when creating the tenant. Data residency is set at sign-up and cannot be changed. A UK organisation that ends up with data in another region either lives with it or rebuilds the tenant from scratch. Ten seconds of attention prevents a five-figure remediation.
• Changing MX records before the mailboxes are licensed and synced. Mail arrives at a tenant that has nowhere to put it, and senders receive bounces that look like the domain is broken. Licence first, sync first, cut over last.
• Cancelling Google Workspace on cutover day. It saves a few hundred pounds and removes the ability to retrieve anything, run a forgotten export, or keep an existing Docs link alive. Keep it read-only for two to three months.
• Leaving two SPF records on the domain. Adding a Microsoft SPF record alongside the Google one produces a permanent SPF failure rather than a merged policy, and the symptom is intermittent delivery problems to recipients with strict filtering. There must be exactly one.
• Treating Google Drive as a phase two. Without a read-only date, file migration never acquires urgency and the organisation settles into running both platforms indefinitely, paying twice and securing neither properly.
• Assuming filters, signatures and Chat come across. They do not, by any tool. Users who were not warned experience this as data loss and lose confidence in everything else the project says.
• Skipping the pilot. Five users through the full process a fortnight early surfaces the majority of configuration problems while there is still time and nobody is waiting. The pilot is the cheapest insurance in the plan.
• Ignoring the machines that send email. Printers, alerting systems, finance packages and booking platforms all send mail without a human involved, and all of them stop at cutover. They are invisible on any user-centred plan and they generate the loudest complaints.

A worked example — 74 users, professional services, Midlands

A chartered surveying practice with 74 staff across three offices had run Google Workspace Business Standard for eight years. The trigger for change was not dissatisfaction with Gmail but a client requirement: several public-sector frameworks they were bidding into asked for documented device management, enforced multi-factor authentication and data residency in the United Kingdom, and assembling that on the Google estate meant an upgrade plus two third-party products. Microsoft 365 Business Premium provided the same control set in one licence, and the practice already ran Windows laptops and desktop Office through a separate subscription, which was being paid for twice.

Discovery ran for nine working days and produced the two findings that shaped the whole project. First, nineteen separate applications used Google as their sign-in provider, including the practice management system, the expenses platform and a client portal that had been configured by a consultant who had left in 2023. Second, the Drive estate held 3.4 TB across 61 shared drives, of which discovery established that eleven were in active use and the remainder were dormant project archives. Neither fact had been known before the audit, and both changed the plan: the identity re-pointing became a workstream with its own owner, and the file migration scope fell from 3.4 TB to roughly 900 GB of active content plus a bulk archive of everything else into a single retained library.

They chose a full cutover. Seventy-four mailboxes averaging 19 GB is around 1.4 TB of mail, which synced over nine days running twenty-five mailboxes concurrently, with a delta sync on the Friday evening. MX changed at 6pm, DKIM and autodiscover had been published the previous day, and the first external test message arrived four minutes later. The one genuine incident over the weekend was an outbound mail failure from the practice management system, which had been relaying through Google’s SMTP service under a service account nobody had documented — it was on the application inventory as an authentication dependency but not as a mail sender. It took ninety minutes to identify and re-point through a connector.

Hypercare ran for eight working days with two engineers on site rotating between offices. The ticket profile was unremarkable: mobile device setup, recurring meetings needing Teams links re-issued, and a sustained stream of questions about where documents had moved to. Gmail filters generated eleven tickets despite the pre-migration warning, all from people who had been told and had assumed it would not apply to them. Google Drive went read-only six weeks after cutover and the tenant was cancelled at week fourteen, after the Vault export had been completed and the retention policies in Purview had been signed off by the practice’s compliance partner.

The part I had not planned for was how much of the work had nothing to do with email. We spent two days on the mail and three weeks on everything that had quietly been using Google to log in. If we did it again I would start the application inventory a month before anything else and treat the mailbox move as the easy bit, because that is what it turned out to be.

The practice ended up paying slightly more per seat than before and removing a duplicate Office subscription that more than offset it. The framework requirements were met with the licence they already had, which was the point of the exercise. Worth noting what did not happen: nobody lost a message, and nobody had a day of downtime. That outcome came from the nine days of discovery, not from anything clever during the cutover.

At a glance — the migration summary

The key facts from this guide in one place, for pasting into a project brief or a board paper.

How Cloudswitched approaches a Microsoft 365 migration

Cloudswitched runs Google Workspace to Microsoft 365 migrations for UK businesses as a scoped project with the discovery phase priced and delivered first, so the organisation sees the full inventory — mailboxes, shared drives, identity dependencies, sending devices, compliance holds — before committing to a cutover date. The migration itself covers tenant build and baseline security configuration, mail, calendar and contact movement, Drive to SharePoint with an agreed target structure, DNS and mail-flow cutover, and a defined hypercare period. Where the estate needs it, we handle the identity re-pointing and the line-of-business mail integration alongside, because those are the workstreams that decide whether the project finishes or becomes permanent.

Frequently Asked Questions

How long does a Google Workspace to Microsoft 365 migration take?

For a business of fifty to a hundred users, eight to twelve weeks from start to decommission is realistic, of which the mail movement occupies a fraction. Discovery takes one to two weeks, tenant build and identity work two to three, the bulk mailbox sync runs in the background over several days to a fortnight depending on total volume, and the cutover itself is a single weekend. Hypercare is another one to two weeks, and the Google tenant is usually retired at around week twelve to fourteen. Projects that promise a two-week end-to-end migration are either very small, or they are deferring the file migration and the identity re-pointing to a phase two that frequently does not happen.

Will we lose any email during the migration?

A properly sequenced migration does not lose mail. The mailbox data is copied rather than moved, so the Google copy remains intact throughout, and a delta sync immediately before the DNS cutover captures anything that arrived during the bulk sync. Mail in transit at the moment MX records change is not lost either — sending mail servers retry delivery for hours or days when a destination is briefly unavailable. The real risk is not loss but misdelivery: messages continuing to arrive in the old Google mailbox because a record was left pointing there. Removing the Google MX entries entirely rather than demoting them, and testing inbound mail from an external address immediately after the change, addresses that.

Do Google Docs, Sheets and Slides convert to Office formats?

Yes, and the conversion is generally reliable for the document content itself. Docs become .docx, Sheets become .xlsx and Slides become .pptx. What does not survive is version history, most comments and suggestions, and any Google-specific functionality: spreadsheets using IMPORTRANGE, QUERY or GOOGLEFINANCE, and anything driven by Apps Script, will need rebuilding. Google Forms, Sites, Drawings and Apps Script projects have no conversion path at all and must be rebuilt in Microsoft equivalents or retired deliberately. Identify the business-critical spreadsheets during discovery so the rebuild is planned rather than discovered.

Should we do a staged migration or a full cutover?

Below roughly 150 mailboxes, a full cutover over a single weekend is usually the better option. Coexistence between Google Workspace and Microsoft 365 requires split-domain mail routing, breaks free/busy calendar lookups across the boundary, and needs distribution lists and shared mailboxes to be reachable from both platforms. That configuration takes real engineering effort and is then dismantled. Above 150 users, or where the organisation runs shifts and has no quiet window, staged becomes worth its complexity. Multi-site organisations can take a middle path of one full cutover per site across consecutive weekends.

What happens to our Gmail filters, labels and signatures?

Labels migrate, generally as a combination of Outlook folders and categories — a message carrying three labels typically lands in one folder with three categories applied. Filters and signatures do not migrate at all, with any tool. The practical approach is to export each user’s filter list from Gmail settings during discovery, prioritise the twenty or so people who rely on them most, and either rebuild the rules for them or hand them the list so they can. Signatures are usually a good opportunity to set consistent organisational signatures centrally in Exchange Online rather than reproducing whatever each person had.

How do we handle printers and applications that send email through Google?

Enumerate them during discovery — multifunction printers configured to scan to email, backup and monitoring systems sending job reports, finance packages emailing invoices, booking platforms sending confirmations. Each needs a new sending method in Microsoft 365. Client SMTP submission using a mailbox username and password is being retired in Exchange Online, so it is not a durable design. The options are direct send to your own domain, which suits most modern devices, an inbound connector authenticated by your public IP address, or a dedicated relay service. Pick one pattern and apply it across the estate rather than configuring each device differently.

Can we keep our existing email addresses and aliases?

Yes. The domain moves with you: you verify it in Microsoft 365 with a TXT record while it is still serving mail through Google, and only change the MX records at cutover. Aliases and send-as addresses are re-created in Exchange Online as proxy addresses on the relevant mailbox. Enumerate them during discovery, because aliases accumulate quietly over the years — old departmental addresses, addresses for former trading names, addresses created for a single supplier — and any that is missed will start bouncing at cutover with nobody knowing why.

Is Microsoft 365 more expensive than Google Workspace for a UK business?

At equivalent tiers the per-seat list prices are close enough that cost is rarely the deciding factor. Microsoft 365 Business Standard and Google Workspace Business Standard sit within about a pound of each other. The comparison changes at Business Premium, which bundles device management, conditional access, advanced threat protection and data governance that a Workspace organisation would usually buy as a higher Workspace tier plus separate products. For organisations that need those controls anyway — for a certification, a client requirement or an insurance condition — Business Premium is often cheaper in total. Confirm current list prices before building a business case, as both vendors adjust them.

What do we do about Google Vault holds and retention?

Vault holds preserve data inside the Google tenant and have no equivalent in Microsoft 365 that a migration tool can create. Before the Google tenant is decommissioned, any preservation obligation must be re-established in Microsoft Purview as a retention policy or litigation hold, and any data under hold that is not being migrated must be exported and retained separately in a governed location. This is a compliance decision rather than a technical one: involve whoever owns data protection, document what was preserved and where it now sits, and get the sign-off recorded. Under the UK GDPR accountability principle, the obligation rests with the organisation regardless of which platform holds the data.

How long should we keep Google Workspace running after cutover?

Sixty to ninety days is the sensible range. Keep it fully live for the first few weeks so anything missed can be retrieved, then switch Google Drive to read-only, which preserves every existing document link while preventing new divergence. Reduce to a handful of administrative seats after the read-only period and cancel on a diarised date. The cost of two or three months of overlap on a sixty-user tenant is a few hundred pounds, which is trivial against the alternative of discovering an unexported Vault hold or a business-critical spreadsheet after the tenant has gone.

Will our Google Meet links still work in migrated calendar invitations?

The link text survives the migration, but it continues to point at Google Meet and depends on Google account access to work as it did. In practice, standing meetings need their conferencing re-created. The cleanest approach is for each organiser to delete and re-issue their recurring meetings as Teams meetings in the week after cutover — about ten minutes per person, and it resolves the problem permanently rather than leaving a mixture of Meet and Teams links across the calendar for months. Include it explicitly in the user communications so organisers know it is their job.

Do we need a third-party migration tool, or is Microsoft’s enough?

Microsoft’s native tooling — the Google Workspace migration in the Exchange admin centre for mail, calendar and contacts, and Migration Manager in the SharePoint admin centre for Drive — is included with the licence and is sufficient for most organisations below about fifty to a hundred mailboxes with a straightforward file estate. Third-party platforms such as BitTitan MigrationWiz, Quest On Demand Migration or CloudM Migrate earn their per-mailbox fee when you need scheduling by department, repeated delta syncs, specific label-to-folder mapping, Google Chat history, or reporting detailed enough for an auditor. Above two hundred mailboxes the reporting alone usually justifies the cost.

Related reading

Other guides that cover the planning, security and connectivity work a platform migration touches.

• Building an IT roadmap and technology strategy for a UK business
• What a Cyber Essentials Plus technical audit actually checks
• Bandwidth planning for a growing UK business
• Proactive network monitoring for UK businesses
• Choosing a VoIP provider and hosted PBX in the UK