Google Workspace to Microsoft 365 is the platform move UK businesses ask us about more than any other, and it is the one that most often goes sideways. A Microsoft 365 migration looks simple from the outside — copy the mail, copy the files, change the MX record, done by Monday. The projects that go badly almost never fail on the mailbox. They fail on shared drive permissions nobody mapped, on a third-party app nobody mentioned, and on a cutover that started late on a Friday with no way back.
This checklist is the working document we use on a Google Workspace to Microsoft 365 project, in the order the tasks actually happen. It covers discovery, method selection, licensing, the data itself, DNS and mail flow, the security baseline, and the thirty days after go-live. The Microsoft 365 security defaults are not the same as Google’s, and assuming they are is how a clean technical migration turns into a bad first month.
Work through it in order. Every section ends with something you can tick off, and nothing in it assumes you have a full-time systems engineer sitting in the building.
Table of contents
- What a Google Workspace to Microsoft 365 Migration Really Involves
- The Pre-Migration Discovery Checklist
- Choosing Your Migration Method
- Licensing and Tenant Setup Checklist
- The Data Migration Checklist, Service by Service
- DNS, Mail Flow and the Cutover Weekend
- The Google Workspace to Microsoft 365 Security Checklist
- Users, Training and Change Management
- Your Google Workspace to Microsoft 365 Cutover Timeline
- What a Google Workspace to Microsoft 365 Move Costs
- Common Mistakes That Derail the Move
- The Final Google Workspace to Microsoft 365 Checklist
What a Google Workspace to Microsoft 365 Migration Really Involves
The three jobs hiding inside one project
Every Google Workspace to Microsoft 365 move is three projects wearing one name. The first is a data move: mail, files, calendars and contacts have to land somewhere sensible. The second is an identity project: accounts, groups, passwords and multi-factor authentication all get rebuilt in a new directory. The third is a change project, because two hundred people are about to open a different application on Monday morning.
Teams that treat it as one job usually resource only the first. That is why so many migrations finish technically on time and still feel like a failure to everyone using them.
Why the mailbox is the easy part
Mail is the most rehearsed part of any Google Workspace to Microsoft 365 migration. The tooling is mature, the throughput is predictable, and a mailbox either arrives or it does not. Files are where the risk lives. Google Drive’s sharing model — link sharing, shared drives, per-file access — does not map cleanly onto SharePoint and OneDrive, and permissions are the thing users notice within about ninety seconds of logging in.
Who needs to be in the room
You need someone who can make decisions about money, someone who knows which systems send automated email, and someone who genuinely knows how the business works day to day. That last person is usually not in IT. Our managed IT services team runs these sessions as a single ninety-minute workshop, because getting the three of them talking early removes most of the surprises later.
Set the definition of done up front
Write down what “finished” means before you start. Ours is usually: every user signed in with MFA, every shared drive rehomed with its permissions intact, mail flowing for seven consecutive days without a support ticket, and the old tenant still available but read-only. A Google Workspace to Microsoft 365 project without that sentence written down tends to drift for months.
The Pre-Migration Discovery Checklist
Count your users, aliases and shared mailboxes
Start with an export of every account. You want active users, suspended users, aliases, delegated mailboxes and any address that receives mail but has no person behind it. Businesses routinely discover twenty percent more mail-enabled objects than they expected, and each one costs time on a Google Workspace to Microsoft 365 move. Suspended accounts holding data still need a home, usually a shared mailbox or an archive.
Measure your data before you promise a date
Pull the total size of Gmail, My Drive and every shared drive separately. Throughput on a Google Workspace to Microsoft 365 migration is governed by API limits, not your broadband, so the number that matters is total gigabytes and file count. A million small files takes far longer than the same volume in large ones, and knowing that in week one is what stops you promising a date you cannot hit.
Map every Google service in use
Beyond mail and Drive, look for Google Groups, Sites, Forms, Vault, Chat, shared calendars and resource calendars for rooms. Each one needs a decision: migrate, rebuild, or retire. Most businesses retire more than they expect once someone asks who actually uses it.
Find the integrations nobody mentions
This is the single most valuable hour of discovery. Search for anything that authenticates with Google or sends mail through it: scanners and copiers, the CRM, the accounts package, e-commerce order confirmations, booking systems, backup tools, single sign-on to other platforms. Every one of those is a task in your Google Workspace to Microsoft 365 plan, and every one you miss becomes a Monday morning outage.
Record the compliance position
Note any legal hold, retention rule or Vault matter before you move anything. If data is under hold in Google, it needs an equivalent in the new tenant before the old one is decommissioned. Getting this wrong is a genuine data protection problem, not an inconvenience.
Choosing Your Migration Method
Cutover migration
Everything moves in one pass and everyone changes over on the same day. It is fast, cheap and clean, and it works well up to roughly one hundred and fifty users with modest data. The trade-off is that there is one big weekend and no gradual proving period. For a small business a cutover Google Workspace to Microsoft 365 move is usually the right answer.
Staged or phased migration
Users move in batches, typically by department. It spreads risk and support load, and it lets you fix a process problem after group one instead of after everyone. The cost is coexistence: for a few weeks half your people are on each platform, and calendar free/busy lookups between them are imperfect. Plan for that rather than pretending it will not happen.
Third-party migration tooling
Paid tools handle the awkward parts — shared drive permissions, delta passes, Google Sites, large file counts — far better than native options. On any Google Workspace to Microsoft 365 project above about fifty users the licence cost is almost always cheaper than the consultancy hours it saves. Budget for it rather than treating it as an optional extra.
Coexistence and why it is rarely worth it
Long-term coexistence, where both platforms run side by side for months, sounds safe and is usually the most expensive option available. You pay twice for licensing, support two sets of problems, and users lose track of where things live. If you cannot complete the move inside a quarter, the answer is usually a smaller first phase, not a longer overlap.
Licensing and Tenant Setup Checklist
Pick the licence before you build the tenant
Decide between Business Basic, Business Standard, Business Premium and the enterprise tiers before anyone creates anything. Business Premium is the usual landing spot for a UK SME because it includes the device and identity controls that Basic and Standard leave out. Changing your mind after a Google Workspace to Microsoft 365 cutover means reworking policy, not just swapping a subscription.
Set the tenant name and vanity domain
The initial onmicrosoft.com tenant name cannot be changed later, so pick something you would be happy to see in a support ticket in five years. Add and verify your real domain immediately, and add every alias domain you found in discovery at the same time.
Configure identity first
Create accounts, groups and licence assignment rules before a single mailbox moves. If you plan to use on-premises directory synchronisation, get it running and stable first. Identity mistakes made early are painful to unpick once mail is live, and identity is the foundation everything else in the Google Workspace to Microsoft 365 checklist sits on.
Decide on group and naming standards
Microsoft 365 will happily create a group, a mailbox, a SharePoint site and a Teams team every time someone clicks a button. Agree a naming convention and who is allowed to create teams before go-live. Retrofitting this across four hundred sprawling sites is genuinely miserable work.
Set up billing and licence headroom
Buy a small buffer of licences. Migrations always surface an account somebody forgot, and discovering you are three licences short at eleven o’clock on cutover night is an avoidable problem.
The Data Migration Checklist, Service by Service
Gmail to Exchange Online
Mail migrates well, and it is usually the first thing people judge a Google Workspace to Microsoft 365 move on. Labels become folders, and because Gmail allows a message to carry several labels, a message with three labels can arrive as three copies in three folders. Tell users this before it happens. Run a full pass first, then one or more delta passes to catch mail that arrived while the first pass was running.
Google Drive to OneDrive
My Drive maps to OneDrive reasonably cleanly. The friction is in file types and names: Google Docs, Sheets and Slides convert to Office formats and some formatting shifts, and files with characters that Windows dislikes need renaming. Google shortcuts and orphaned files owned by departed staff need explicit handling.
Shared drives to SharePoint
This is the part of a Google Workspace to Microsoft 365 migration that consumes the most time and causes the most complaints. Each shared drive needs an owner, a destination site, and a permission model agreed in advance. Do not lift and shift a mess: use the move as the one legitimate chance you will get to consolidate twenty half-used shared drives into six that make sense.
Calendars and contacts
Personal calendars and contacts migrate with the mailbox. Resource calendars for meeting rooms and equipment usually have to be rebuilt as room mailboxes, and recurring meetings with external attendees are the classic breakage — check a handful manually after the move rather than assuming.
Google Groups, Sites and Vault
Groups become Microsoft 365 groups or distribution lists depending on how they are used. Google Sites do not migrate; they get rebuilt in SharePoint or retired, and most get retired. Vault content needs a deliberate decision: export it, or keep the old tenant alive long enough to satisfy your retention obligation.
Run a pilot with real people
Move ten users who represent the awkward cases — the heaviest mailbox, the person who lives in shared drives, someone who uses a scanner, and a director. Give them a week. The pilot is where your Google Workspace to Microsoft 365 runbook stops being theoretical.
DNS, Mail Flow and the Cutover Weekend
Lower your TTL a week early
Drop the time-to-live on your MX and related records to three hundred seconds at least a week before cutover. It costs nothing and it means a mistake propagates back out in five minutes rather than a day.
The cutover running order
Final delta pass, then MX change, then SPF, DKIM and DMARC, then re-point every device and application you catalogued in discovery. Do the mail routing change first and the application re-pointing immediately after, because that is the window where things quietly fail.
The first hour after MX changes
Send test mail in both directions, from an external address and to one. Check that the copier scans, that the CRM sends, and that order confirmations still arrive. Have someone watching the message trace in the admin centre for the first hour rather than waiting for a user to report it.
Keep Google Workspace alive for 30 days
Do not cancel the old subscription on go-live day. Leave it running, read-only if you can, for about thirty days. It is cheap insurance, it catches the one shared drive nobody mentioned, and it is the difference between a Google Workspace to Microsoft 365 move that feels controlled and one that feels like a gamble.
Update anything that stores an address
Mailing lists, DNS records for subdomains, third-party sending services and any hard-coded SMTP settings in line-of-business software all need checking. Our cloud migration team keeps this as a written list from discovery so nothing depends on somebody’s memory at midnight.
The Google Workspace to Microsoft 365 Security Checklist
Turn on multi-factor authentication before day one
MFA should be enforced on every account before the first mailbox lands, not added later. Migrations attract phishing: people expect unusual login prompts that week and are far more likely to approve one they should not. Enabling security defaults or a conditional access policy up front removes the entire category of problem.
Conditional access and legacy protocols
Block legacy authentication protocols such as POP, IMAP and basic authentication unless you have a specific documented need. These are the routes attackers use because they bypass MFA. Build conditional access rules for location and device compliance while the tenant is still quiet — a Google Workspace to Microsoft 365 cutover is far easier to police before four hundred people are working in it.
Sharing and external access defaults
Google and Microsoft make different assumptions about link sharing. Decide deliberately whether anonymous links are allowed, whether external sharing needs sign-in, and what expiry applies. A Google Workspace to Microsoft 365 migration silently changes who can reach your files if you accept every default without reading it. A short Microsoft 365 security review a fortnight after go-live is worth the hour.
Backup is still your job
Microsoft’s retention is not a backup. Recycle bins and retention policies protect against some deletion scenarios and none of the others, and the same was true in Google. Cybersecurity insurance policies increasingly ask the question directly, so decide on a third-party backup before you need it. The NCSC cloud security guidance is the clearest free reference for what good looks like here.
Write down who holds the keys
Record who has global administrator rights, enable a break-glass account, and store the credentials somewhere that does not depend on the tenant you just built.
Users, Training and Change Management
Tell people what changes on their screen
Most staff do not care which platform they are on. They care that the icon is different, the search box behaves differently and their bookmarks are wrong. A one-page note covering where mail is, where files are and how to sign in prevents more tickets than any formal course.
Train the loud minority first
Find the ten people who others ask for help and get them comfortable a fortnight early. They will absorb a large share of the questions in week one, and they will tell you what is genuinely confusing about your Google Workspace to Microsoft 365 rollout before it reaches everyone else.
Write three things down
Publish how to sign in, how to find a shared drive’s new home, and who to contact when something is missing. Three short answers, in one place people can reach without email. Formal change management is largely this, done consistently.
Staff the first week properly
Whatever support cover you think you need for week one, add half again. The tickets are not hard, but there are a lot of them at once, and slow answers in the first three days set the tone for how the whole Google Workspace to Microsoft 365 rollout is remembered.
Your Google Workspace to Microsoft 365 Cutover Timeline
Weeks one and two: discovery and design
Inventory, data sizing, integration mapping, licence decision and tenant design. Nothing moves. This is the fortnight that determines whether the rest of the Google Workspace to Microsoft 365 plan holds together.
Weeks three and four: build and pilot
Build the tenant, configure identity and security, connect the migration tool, then move the pilot group and leave them working for a full week. Fix what the pilot exposes before touching anyone else.
Weeks five and six: bulk migration
Run the main passes, usually overnight and by department. Communicate the schedule so people know which night they are moving and what they will see the next morning.
Week seven: cutover and hypercare
Final delta, MX change, application re-pointing, then a week of visible, well-staffed support. Seven to nine weeks is a realistic band for most SMEs; anything under four weeks is either a very small business or a promise someone will regret.
What a Google Workspace to Microsoft 365 Move Costs
Professional services
For a typical UK SME, expect roughly £2,000 to £5,000 for up to twenty-five users, £5,000 to £12,000 for twenty-five to a hundred, and £12,000 upward beyond that. The variables that move the number are shared drive complexity, integration count and how much consolidation you ask for along the way.
Licensing and tooling
Licences are the larger long-run figure. Business Premium sits around £18.10 per user per month, so a fifty-user business is committing roughly £10,860 a year — several times the project fee, every year. Migration tooling typically adds a few pounds per user as a one-off. Our cloud migration cost breakdown covers how these components stack up more generally.
The hidden extras
Overlap licensing for the thirty-day Google retention, third-party backup, any hardware that turns out to be too old, and the internal time nobody costs. Adding fifteen percent contingency to a Google Workspace to Microsoft 365 budget is realistic rather than pessimistic.
Common Mistakes That Derail the Move
Promising a date before discovery
The date should come out of the data sizing, not the board meeting. Committing publicly to a cutover weekend before you know your file count is the most common way a Google Workspace to Microsoft 365 migration becomes stressful.
Forgetting shared drive permissions
Copying files without rebuilding access produces a week of “I cannot open the folder” tickets. Agree the permission model per destination site during discovery, then verify a sample after the move.
Ignoring third-party applications
Scanners, CRMs and booking systems that send through Google will stop the moment mail flow changes. They are trivial to fix and easy to forget, which is exactly why they belong on a written list.
Cutting Google off too early
Cancelling the old subscription the week you finish saves a small amount of money and removes your only safety net. Thirty days of overlap is the cheapest insurance in the project.
Treating security as a later phase
The tenant is at its most exposed and least monitored in the fortnight after a move. Baseline first, then migrate. It is far easier than retrofitting policy onto four hundred active users.
The Final Google Workspace to Microsoft 365 Checklist
Before you start
Full account and alias export. Data sized by service. Every integration listed. Licence tier chosen. Migration method agreed. Tenant built with identity and MFA configured. Pilot group named. Rollback position written down.
During the migration
Full pass complete. Delta passes scheduled. Shared drives rehomed with owners and permissions verified. Calendars and room resources checked. TTL lowered. Cutover running order agreed with named owners for each step.
After go-live
Mail tested in both directions. Every application re-pointed. Sharing defaults reviewed. Backup in place. Old tenant retained read-only for thirty days. Support staffed and a single page of guidance published.
Work that list honestly and a Google Workspace to Microsoft 365 migration becomes an ordinary, well-run project rather than a memorable one. If you want a second pair of eyes on your plan — or someone to own the whole thing — our team runs these end to end for businesses across the UK, and the discovery workshop is where we would start. You can read more about how Microsoft 365 and Google Workspace compare as platforms before you commit either way.
