Moving From Google Workspace to Microsoft 365

A Google Workspace to Microsoft 365 migration is the process of moving an organisation’s mail, calendars, contacts and files out of Google’s tenancy into a Microsoft 365 tenant, then repointing the domain’s mail flow and identity to Microsoft. Microsoft supplies free first-party tooling that handles the bulk of the copying. The difficulty is not the copying. It is the handful of things Google does that Microsoft has no equivalent for, and the two weeks afterwards when users discover them one at a time.

This post is about mechanics only. If you are still deciding, read which platform suits your business first and come back.

Microsoft’s own tools do most of the copying, and they are free

There are two separate tools and they do not talk to each other.

Mail, calendars, contacts, mail rules and tasks move with the automated batch migration tool in the Exchange admin center. Per Microsoft Learn, it “can transfer your organization’s mail, rules, calendars, and contacts from Google Workspace to Microsoft 365”, and Microsoft recommends the automated method because it completes several of the required Google admin console steps for you.

Files move with Migration Manager, reached from the Microsoft 365 admin center under Setup, then Migration and imports. Microsoft’s own FAQ is blunt about the alternatives: “Currently, Migration Manager is the tool to use for migrating Google content.” For tenants with fewer than 300 licences at the time the project is created, Microsoft enables a cut-down version called Migration Manager Lite, which skips the scan, destination-mapping and identity-mapping steps. On anything beyond a handful of users, that is the wrong tool. You want the scan report and you definitely want identity mapping.

Third-party migration tools still have a place, mostly for tenant-to-tenant work, Google Sites, or when you need reporting Microsoft does not produce. For a standard 10 to 200 seat move, the native tooling is adequate.

What migrates cleanly

• Mail content and folder structure, including Gmail labels rendered as Exchange folders.
• Calendar events on users’ primary calendars.
• Contacts, up to three email addresses per contact.
• Mailbox delegates, Send As, and mail rules.
• Google Tasks, if you pass -MigrateTasks when you create the batch. Task lists become task folders. Note that incremental sync is not supported for tasks that have already migrated.
• Rooms and resources, if you enable the Admin SDK API and add the resource calendar read-only scope to domain-wide delegation. Google resources map to Exchange resource mailboxes and Google buildings map to distribution groups.
• Drive files and folders, including version history, and shared drive permissions if you map identities properly first.
• Google Docs, Sheets and Slides, converted on the way through.

What does not migrate, and what users will complain about

This is the section to read to your leadership team before you commit to a date.

Gmail labels are not folders. Google’s own help documentation states plainly that “labels are different from folders” and that you can apply several labels to one email. Exchange has folders, and a message sits in exactly one. Anything labelled three ways has to become three copies or one copy in one folder. Neither answer is what the user had. Microsoft’s guidance is to use the -ExcludeFolder parameter when starting batches from Exchange Online PowerShell to strip out labels that apply to large numbers of messages, which reduces both duplication and mailbox size. Decide this per label, with the business, before you migrate. Do not discover it afterwards.

Google Docs stop being Google Docs. During migration the Google Export API converts .gdoc to .docx, .gsheet to .xlsx and .gslide to .pptx. The originals in Drive are untouched. What does not survive the conversion is everything that was never a document feature to begin with: suggestion mode history, Apps Script attached to a Sheet, IMPORTRANGE and other cross-document live links, and add-ons. Any spreadsheet that is really a small application needs to be rebuilt, not migrated. Find those first. There are always two or three and they are always load-bearing.

Shared calendars and calendar delegation. Microsoft’s documentation is explicit that shared calendars and event colours are not migrated, and that room bookings are not migrated. More significantly, as of June 2024 the option to migrate permissions and delegates for calendars is turned off worldwide. Mailbox permissions and delegates still migrate. Calendar permissions do not. Every executive assistant who manages a principal’s diary will need that relationship rebuilt by hand on day one.

Vacation and auto-reply settings are not migrated. Trivial until you cut over the week someone is on leave.

Google Sites and Google Maps cannot be exported, so Migration Manager does not move them. Google Drawings come across as PNG files. Google Forms migrate, but only if you designate a Forms destination on the task. Shortcut files are skipped entirely.

Orphaned files. Microsoft does not scan unorganised or orphaned files in Google, so they are neither migrated nor reported. If a departed employee’s content ended up unparented, it does not appear in any report. It just is not there afterwards.

External sharing links break. Migration Manager does not recreate external sharing links and does not share content with external collaborators, deliberately. If your clients or suppliers have bookmarked a Google Drive link, every one of those links dies at cutover and has to be reissued from SharePoint.

Google Groups do two jobs at once. In most Workspace tenancies a group is simultaneously a mailing list, a Drive permission holder, and sometimes a calendar. Microsoft splits those across distribution lists, Microsoft 365 groups, security groups and shared mailboxes. Before you migrate files, work out for each group which job it is really doing, then recreate the file-permission side as a Microsoft 365 group with matching membership and map it in Migration Manager’s identity mapping. Microsoft’s FAQ makes this a prerequisite for shared drive permissions to land correctly, not an optimisation.

Anything authenticated with Google SSO. This is the one that catches people. Where Google Workspace is acting as the SAML or OIDC identity provider for third-party SaaS, or staff have been signing in to a tool with “Sign in with Google”, that trust relationship does not migrate. Each application has to be reconfigured against Microsoft Entra ID, which means touching each vendor, and some of them will want a plan upgrade to support SAML. Separately, check API controls and domain-wide delegation in the Google admin console for service accounts that read Workspace data on behalf of users. Those integrations are invisible to end users right up to the moment they stop working. Inventory both lists before you set a date.

Identity and domain handling decides your sequencing

Microsoft 365 identity runs on Microsoft Entra ID, Microsoft’s cloud-based identity and access management service. Your users need to exist there before anything can be delivered to them.

The mail migration requires a specific and slightly counter-intuitive DNS arrangement. Microsoft’s prerequisites call for two routing subdomains: one added in Google Workspace pointing at Microsoft 365 (for example o365.yourdomain.com.au), and one added in Microsoft 365 pointing back at Google (for example gsuite.yourdomain.com.au). Both must verify and go Active. Microsoft warns that using the built-in tenantname.onmicrosoft.com domain for routing instead of a subdomain of your primary domain “occasionally causes issues that Microsoft is not able to assist with”.

Every user is provisioned in Microsoft 365 as a mail user first, with an ExternalEmailAddress pointing at their Google routing address, before being converted to a mailbox by the migration itself. Get the primary addresses matching across both platforms. Where they do not match, the user needs a proxy address at the primary domain.

Microsoft also recommends disabling messaging records management and archive policies during the migration, because retention and archiving actions during a copy make messages look missing during verification when nothing has actually been lost.

Two cutover approaches, and the one most businesses should pick

Staged coexistence. The dual-subdomain routing above exists so mail keeps flowing to both platforms while batches run. You migrate in groups, the MX record moves once, and the remaining Google users receive their mail via forwarding until their batch completes. This is the approach the Microsoft tooling is built around and it is the right default for anything above about 20 users. The trade-off is a period of split-brain where free/busy lookups across the boundary do not work properly and internal replies occasionally take an odd path.

Single cutover. Everything migrates over a weekend, MX moves once, Google goes read-only Monday morning. Cleaner conceptually, and fine for small tenancies with modest mailboxes. The risk is entirely on throughput: contact and calendar throughput is capped by your Google tenant’s service account quota, and individual messages are limited by default to 35 MB (configurable up to 150 MB). If a large mailbox does not finish, you have no fallback because the MX has already moved.

Pick coexistence unless the tenancy is genuinely small. The extra fortnight of dual routing costs less than a failed weekend.

Realistic sequencing

1. Audit and inventory. Super admins, third-party OAuth grants, domain-wide delegation, SSO applications, forwarding rules, shared drives with no manager, Google Groups and what each one actually does. We cover this in detail in audit the Google tenancy before you touch anything.
2. Take an independent backup of the Google data before you change anything. Migration tools copy rather than move, but a rollback point that does not depend on either vendor is cheap insurance. See a proper backup of the Google data.
3. Build the Microsoft 365 tenant. Licensing, Entra ID, groups, SharePoint site structure, security baseline.
4. Provision mail users and verify both routing subdomains.
5. Migrate rooms and resources first. Microsoft recommends starting resource onboarding before regular mailbox onboarding and finishing it after all mailboxes are done.
6. Run a pilot batch. Include at least one executive assistant, one heavy label user and one person with a spreadsheet that does something clever.
7. Scan Drive, map identities, pre-create the Microsoft 365 groups that will hold shared drive permissions.
8. Migrate files ahead of mail. File migration is slower and tolerates delta syncs. Mail cutover is the hard deadline.
9. Move mail in batches, then move MX.
10. Delta sync files, rebuild calendar permissions, reissue external links, repoint SSO applications.
11. Leave Google Workspace running, read-only, for at least one billing cycle. Do not cancel the subscription on cutover day.

For the Microsoft-side build, our general Microsoft 365 migration guide covers the tenant configuration that applies regardless of where you came from.

The parts that always cause grief

Delta syncs punish tidiness. Migration Manager treats a renamed file or folder as a brand new object, so reorganising Drive between passes duplicates everything below the renamed folder. Freeze the source structure for the duration.

Data volume never matches the admin console. Google only started counting the size of its own proprietary file types on 2 May 2022, so anything created or modified before that date returns a scanned size of one byte. Your scan report will understate the job.

Path length and file names bite late. Destination URLs over 400 characters fail, drives with a forward slash in the name are unsupported, and duplicate file names in the same folder get renamed with (1), (2) suffixes.

And the cultural one, which no tool solves: Google’s sharing model is permissive by default and SharePoint’s is not. Users who were used to sending a link to anyone will find themselves blocked, and will describe this as the migration breaking things. Decide your external sharing policy before cutover, communicate it as a deliberate change, and staff the help desk properly for the first fortnight.

If you are keeping some Google services rather than leaving entirely, running both platforms side by side is a supportable position, but it needs to be a decision rather than a leftover.

Worth saying plainly, because this post points one direction: we are a Microsoft partner, and we also administer Google Workspace tenancies as daily work. We do not treat a move to Microsoft 365 as automatically correct, and a fair share of the businesses that ask us about this migration are better off staying where they are. If yours is one of them we will tell you, which is the only reason the rest of this advice is worth reading.

Book a scoping session before you commit to a cutover date. We will run the inventory, produce the list of things that will not migrate, and give you a sequenced plan you can put in front of your board. Call 1300 028 324 or get in touch at https://techassist.au/contact/.

A SharePoint intranet is a set of SharePoint Online sites — built on the licence you already pay for in Microsoft 365 — that gives staff one place for news, policies, documents and people. Build it around how people actually work and they use it daily. Build it as a digital filing cabinet and it dies.

Most Melbourne businesses already own SharePoint and don’t realise it. If you have Microsoft 365 Business Standard or Business Premium, the intranet platform is sitting there, unused, while staff email each other PDFs and hunt through a network drive nobody has tidied since 2019. The technology is rarely the problem. The decisions you make before you build it are.

What a modern SharePoint Online intranet actually is

Forget the old picture of a clunky 2010-era SharePoint server. The modern version runs entirely in the cloud, looks like a clean website, works on a phone, and is made of three building blocks: communication sites, team sites and hub sites. You assemble those into an intranet rather than installing a single “intranet product”.

The point of the thing is to answer the questions staff ask all day: where’s the current leave policy, who do I call in accounts, what’s the new client onboarding process, has anything changed this week. When those answers live in one searchable place that people trust, you stop losing hours to “do you know where the…” messages.

Communication sites versus team sites

This is the first decision that trips people up, so get it straight early. The two site types do different jobs.

In plain terms: your intranet’s front door and its polished, company-wide pages are communication sites. The messy day-to-day work — drafts, working documents, a project’s files — happens in team sites, which are the same thing that gets created every time someone makes a new team in Microsoft Teams. Most organisations need a handful of communication sites and a growing number of team sites.

Hub sites tie it together

On their own, a dozen separate sites are just a dozen separate sites. A hub site is what makes them feel like one intranet. You designate a site as a hub, then associate other sites with it, and they inherit shared navigation, a consistent look, and rolled-up news and search across everything connected.

A practical structure for a mid-sized business: one hub as the company intranet home, with the HR, IT, Operations and Sales sites associated to it. Staff get one top navigation bar across the lot, news from any connected site surfaces on the home page, and search spans the whole hub. You can re-associate sites later, so the structure isn’t a one-way door — but planning it up front saves a painful reorganisation six months in.

The pieces staff care about

An intranet earns its keep through a few core features. None of them are exotic; the difference is whether they’re set up deliberately or thrown together.

• News — SharePoint News posts are how you communicate. A short post about a policy change or a new starter beats an all-staff email nobody reads, and it stays findable afterwards.
• Document libraries — where files live, with version history, check-out, and metadata so you can filter and sort rather than scroll. This is what replaces the network drive.
• Policies — a single authoritative home for the employee handbook, the leave policy, the WHS documents. One current version, not eleven copies in eleven inboxes.
• Staff directory — pulled from your Microsoft 365 user accounts, so people can find who does what and how to reach them.

Integration with Teams and Viva Connections

This is where SharePoint stops being a website you have to remember to visit. Every Microsoft Teams team is already backed by a SharePoint team site — the Files tab in any channel is a SharePoint document library. So your collaboration sites are reachable without leaving Teams, where most staff already spend their day.

Viva Connections takes it further: it surfaces your intranet home page, news and resources directly inside Teams as an app, on desktop and mobile. For frontline and on-the-go staff who never open a browser, that’s often the difference between an intranet they see and one they forget exists. If you’re already invested in the Microsoft stack, our Microsoft 365 support covers wiring these pieces together so the intranet meets staff where they work rather than asking them to come to it. For a fuller picture of what the platform includes, our rundown of what Microsoft 365 support covers is a useful companion read.

The decisions that make or break adoption

Information architecture is the unglamorous part everyone skips, and it’s the part that decides whether the intranet works. Information architecture means how you structure and name things so people find them without thinking.

The mistakes are predictable. Folder structures fifteen levels deep that mirror the old network drive. Navigation built around your org chart instead of around tasks — staff don’t think “I need the People & Culture division’s content”, they think “where’s the leave form”. Twenty different document libraries with no naming convention. Search left to fend for itself with no metadata to work with.

Get the architecture right and the platform does the rest. The questions worth arguing about before you build anything are: what are the ten things staff look for most, what should the top navigation be, what’s a hub and what’s associated to it, and how do you name and tag documents consistently. An hour of disagreement in a planning meeting saves a rebuild later.

Permissions and governance

The fastest way to ruin a SharePoint intranet is to let permissions sprawl. Out of the box it’s easy to share a file or site with one person, then another, until nobody can tell who can see what — and a staff directory or HR site with leaky permissions is a privacy problem, not just a tidiness one.

The disciplined approach is to manage access through Microsoft 365 Groups and security groups rather than one-off shares, keep company-wide content readable by everyone and editable by few, and set a clear policy on who can create new sites. Left unchecked, “anyone can spin up a team” produces hundreds of orphaned sites within a year. Governance also means deciding retention, external sharing rules, and a content owner for each site so pages don’t go stale. Conditional access policies sit underneath all of this, controlling who can reach the intranet, from which devices, and under what conditions — important when the same platform holds your policies and your client files. This kind of structure is part of broader cybersecurity hygiene, not an optional extra.

Migrating off file servers and network drives

Most intranet projects are also a migration off an ageing file server or a mapped network drive, and that’s where the real effort lives. You don’t just copy files across — you decide what comes, what gets archived, and how it’s structured on the other side.

A law firm in Hawthorn we work with had a 600GB shared drive built up over a decade, with matter folders, duplicates, and files three people swore were the master copy. The temptation is to lift-and-shift the whole thing into SharePoint and call it done. That just moves the mess to a new address. We sorted what was still live, archived closed matters, agreed a folder and metadata structure that matched how the firm actually worked, then migrated in stages so nobody lost access mid-week. The migration tooling matters — SharePoint has document size and path-length limits the old drive didn’t — and so does timing it around the firm’s quieter periods.

If your file server is also your backup and disaster-recovery weak point, moving to SharePoint changes that equation too — though “it’s in the cloud” still isn’t a backup strategy, which is why our backup and recovery approach covers Microsoft 365 data as well.

Why “build it and they won’t come” happens

The most common SharePoint outcome in Australian SMEs is an intranet that was built with enthusiasm, launched with an email, and abandoned within two months. It happens for clear reasons: nobody owned the content so it went stale, the structure mirrored the org chart instead of staff tasks, the launch was a one-off announcement with no follow-through, and leadership didn’t use it themselves.

Driving adoption is mostly non-technical. Put the things people need daily — the leave form, the phone list, this week’s news — on the front page so there’s a reason to visit. Move a real workflow onto it, like leave requests or IT support requests, so people have to use it. Surface it in Teams via Viva Connections so they don’t have to remember a URL. Name content owners who keep their corner current. And get the leadership team posting news, because staff follow what management actually uses. An intranet that’s the easiest path to the answer wins; one that’s a chore loses.

Realistic effort

Setting up a basic intranet — a home site, a few hub-connected sites, news and document libraries — is days, not months, for someone who knows the platform. The work that takes time is the thinking: the information architecture, the permissions model, the migration off the old drive, and the change management to get people using it. A sensible mid-sized rollout runs over several weeks, with a planning phase, a build, a staged migration, and a launch backed by training rather than an email. Trying to compress all of that into a weekend is exactly how you end up with the abandoned version.

Frequently asked questions

Do we need extra licences to build a SharePoint intranet?

Usually no. SharePoint Online is included in Microsoft 365 Business Standard, Business Premium and most enterprise plans, and Viva Connections is included as well. If you already run Microsoft 365 for email and Teams, you almost certainly have everything you need to build the intranet on your existing licences.

What’s the difference between SharePoint and Teams?

They’re two views of the same data. Teams is where you chat and meet; SharePoint stores the files and pages behind it. Every Teams team has a SharePoint site underneath, and the Files tab in a channel is a SharePoint document library. An intranet adds the company-wide communication sites and hubs on top.

How do we stop the intranet becoming a mess of duplicate files?

Agree a structure and naming convention before you migrate, use metadata and search rather than deep folders, manage permissions through groups, and control who can create new sites. The discipline is in governance and information architecture, not in the platform itself.

Can staff access the intranet on their phones?

Yes. SharePoint sites are mobile-responsive, and Viva Connections puts your intranet home page, news and resources inside the Teams mobile app — which is how frontline and on-the-go staff actually reach it, since most never open a browser at work.

Getting it built properly

A SharePoint intranet is one of the best-value things you can do with Microsoft 365, because the licence is already paid for and the payoff — less time hunting for documents, one source of truth for policies, cleaner communication — compounds. The risk is doing it without the architecture, permissions and adoption work, and ending up with abandoned space. TechAssist is a Melbourne-based MSP, founded in 2014, with 13 Australian-employed engineers — no offshore helpdesk — and per-user fixed pricing, so a project like this is scoped properly rather than billed by the hour. If you’d like to turn the SharePoint you already own into something staff actually use, explore our cloud services or get in touch for a straight conversation about it.