The decision to change office suite rarely happens in a vacuum. In companies that come to us with such a project, the Google → Microsoft direction usually has one of several concrete reasons: a new owner standardizes the holding group on M365, a key client requires Exchange and Teams, device management needs are growing, or Google Workspace simply stops covering real use cases.

Less often, the migration starts with a price comparison. Both suites are cost-comparable, and the differences only become visible after a deeper dive: integration with Active Directory, laptop management tools (Intune), working with offline documents, day-to-day administration.

This article is not a comparison of both platforms. There are hundreds of those online. It describes what the migration itself looks like, where the pitfalls are, and what you need to decide before you start.

What is actually being migrated

Migrating from Google Workspace to Microsoft 365 is, in practice, a set of separate processes, each with its own plan:

• User identities - accounts become Entra ID accounts (formerly Azure AD). If the company has on-premises Active Directory, a decision about synchronization through Entra Connect comes into play.

• Email - Gmail mailboxes migrate to Exchange Online together with folders, labels, and attachments.

• Files - Google Drive moves to OneDrive (personal) and SharePoint (team drives). Google Docs are converted to Microsoft formats.

• Calendars and contacts - migrated in parallel with the mailboxes.

• Mobile devices and computers - moved over to Intune, independently of the data migration.

Each of these elements has its own pace, its own Google-side API limitations, and its own risks.

An approximate service mapping looks like this:

When not to migrate

Migrating from Google Workspace to Microsoft 365 is not always a good idea. In the inquiries that reached us, we have several times recommended that the client not do it, or that the project be postponed. Situations that should make you stop:

• The company has just gone through a major organizational change - a merger, a new ERP rollout, an office relocation. An office-suite migration consumes a significant share of the team's attention for several weeks. Adding it on top of an already tired organization ends in delays and frustration.

• Key processes are built on Google integrations - Apps Script drives the sales workflow, Google Sites is the internal intranet, Forms collects data from customers. The cost of recreating this on the Microsoft side can exceed the savings from migration.

• Most employees strongly prefer Google Workspace - without management support and good communication, even a technically successful migration ends with a fragmented return to Google. Shadow IT, private Gmail accounts used for work, files going back to Drive 'because it's more convenient'.

• The license cost would be significantly higher - for companies using Google Workspace Business Starter ($6 per user per month), moving to Microsoft 365 Business Standard means roughly double the monthly cost for a comparable scope.

I am also intentionally leaving out migration between Microsoft 365 tenants here (for example, in a merger of two companies already using M365) - that is a completely different operation, with its own challenges and tools.

Decisions to make before starting the migration

One-stage migration or phased migration

In a one-stage migration (the so-called cut-over), all users are switched to the new environment in one day. It is simpler to execute, but requires more planning and works best mainly for smaller organizations. In a phased migration, groups are moved - departments, locations - with a coexistence period for both systems. For companies above 30-40 people, a one-stage migration is a bad idea.

What happens to the domain during migration

The primary domain (firma.en) can at any given time be attached to only one mail system. During the transition period, a transit subdomain is used (for example, m365.firma.en) so that the migrating users can work in the new environment before the MX records are finally switched.

Document format

Google Docs, Sheets, and Slides files convert to Word, Excel, and PowerPoint - but the conversion is never 100 percent. Formatting, custom functions, and Apps Script scripts can break. Simple documents come through without problems. Complex proposal templates or spreadsheets with formulas - review them and fix them manually.

Two Google Workspace elements require a separate decision. Google Drawings are converted to .jpg files during the migration to OneDrive and lose editability - if the company uses them for diagrams or organizational charts, they will need to be recreated in Visio or PowerPoint. Google Forms do not migrate at all, because they have no equivalent in the Microsoft ecosystem. Existing forms should be recreated in Microsoft Forms (for simple cases) or Power Apps (for more advanced ones).

Version history and comments

Standard migration tools do not transfer document version history or comments. The file creation date changes to the migration date. For companies that rely on version history for audit or legal purposes, this is important information. The solution: archive the originals in a separate location before migration.

File permissions

Sharing in Google Drive works differently than in SharePoint. In Drive, the sharing model is per file or per folder, often created ad hoc by users ('share the link with anyone who has the link') and spreading for years without control. SharePoint, by default, inherits permissions from the site or library, and exceptions are configured deliberately. After migration, you need to verify who has access to what - especially if Drive had organic chaos with years of 'share it with whoever'. In my opinion, this is the best moment to clean things up: a new SharePoint with clean permissions is easier to manage than mechanically copied Drive clutter.

Licenses

Microsoft 365 Business is divided into three basic plans for companies up to 300 users: Basic (web and mobile apps only, without desktop Word and Excel), Standard (full desktop apps), and Premium (plus Intune for device management, Defender, advanced phishing protection, Azure Information Protection). For larger organizations, Enterprise plans are available (E3, E5) with additional compliance and analytics features. The decision of who gets which plan affects not only the budget, but also what will be available after migration. In practice, most companies need a mix: Premium for departments working with sensitive data and management, Standard for the rest, sometimes Basic for production or warehouse staff who only use email. Plan this before migration - changing the plan during the project generates extra administrative work.

What will not migrate - a list of elements requiring a separate plan

Standard migration tools will not move several elements of the Google Workspace ecosystem. Each of them requires a separate decision - recreate it in Microsoft 365, archive it on the source side, or abandon it:

• Google Forms - no equivalent on the migration side, manual recreation in Microsoft Forms or Power Apps

• Google Apps Script - no migration, rewrite to Power Automate or Office Scripts

• Google Drawings - converted to .jpg, lose editability, reconstruction in Visio or PowerPoint

• Document version history - not migrated, originals are archived separately

• Comments in documents - not migrated

• File metadata - creation dates change to the migration date, Gmail labels may not map 1:1 to Outlook folders

• Permissions for external sharing - links like 'anyone with the link' do not carry over, we recreate them manually for important shares

Migration methods - which tool to use for the project

The tool choice depends on the scale and complexity of the migration. In practice, the market breaks down into three categories:

• Native Microsoft Migration Manager - a free tool in the M365 admin center. It handles simple mail and file migrations for smaller teams, but does not support more advanced permission mapping or incremental migrations.

• Enterprise-class solutions - Quest On Demand Migration and AvePoint FLY are professional tools used in projects where organizational structure mapping, preservation of advanced permissions, phased migration with delta synchronization, and migration of Google Sites to SharePoint are required. In this class, you are buying not so much a tool as the ability to repeat the migration incrementally until the final cutover.

• Manual per-user migration - each employee moves their own data: mail by configuring both accounts in Outlook or Thunderbird and dragging folders between IMAP mailboxes, files by downloading from Google Drive locally and uploading to OneDrive, calendars by exporting .ics, contacts by exporting CSV. This method has no license costs, but it has a real time cost for employees - hours each person spends moving data instead of doing their actual work. It is also slow, requires involvement from every user, and does not preserve metadata (Gmail labels, file permissions, exact dates) or shared resources. For larger mailboxes, Google-side IMAP limits also come into play.

A quick comparison:

Regardless of the chosen method, before the actual migration make a full account archive via Google Takeout - as a safeguard of the original data in case of problems during migration or disputes over what was there before. This is not a migration method, but a good supporting practice.

For most SMB companies, Quest or AvePoint are sensible choices - their licensing cost over the whole project is small compared to the risk of a failed free migration. The manual method only makes sense in micro-businesses, where each user already directly manages their own data.

Migration stages step by step

The general project skeleton is similar regardless of the tool chosen:

1. Inventory - number of users, mailbox sizes, amount of data in Drive, list of apps in use (Meet, Groups, shared calendars), integrations with external systems using Google SSO.

2. Preparing the M365 tenant - domain verification, initial Entra ID configuration, password policies, MFA, DLP basics.

3. Pilot migration - one or several pilot mailboxes. It reveals most problems before they affect the entire team.

4. User communication - schedule, instructions, what will change in day-to-day work. In IT plans, this item often lands at the bottom of the list, but in reality it determines whether the migration is perceived as a success.

5. Actual migration - emails, files, and calendars moved with the selected tool (see the section above).

6. MX cutover - the moment when new mail starts arriving in Exchange Online. Old messages finish syncing in the background.

7. Stabilization period - 2-4 weeks during which users report small issues (missing shares, signature problems, phone configuration).

In one of our projects - a migration from Dropbox to SharePoint and OneDrive for an international organization employing several dozen people, with offices in several European countries - we split the whole thing into five stages, each starting on Friday morning. The choice of Friday was no accident: the weekend gave us a buffer in case something went wrong. After each stage, access to Dropbox in the given area was cut off only after approval from a group of about 20 migration owners - people from the individual departments who knew their folders' contents best. All communication materials - instructions, announcements, tutorials - were prepared in parallel in Polish and English. A separate final stage was the transfer of employees' personal resources from Dropbox to their individual OneDrive accounts - on request from those who wanted it.

Not everything went smoothly. The first two stages were more difficult than we expected - we underestimated the time the migration owners needed to verify the transferred data. Several times, the final approval came on Sunday evening, one hour before the planned start of the next stage. From the third stage onward, we extended the verification window by an additional 24 hours - and the rest of the project went smoothly. The whole thing moved the schedule by a few weeks compared with the 'everything in one weekend' version, but reduced the number of serious post-migration incidents practically to zero.

How long does a Google Workspace to Microsoft 365 migration take

Approximate time frames for the projects we have run:

• 20-30 users - 1-2 weeks from tenant preparation to project closeout, with standard data volumes (several hundred GB in Drive total)

• 50-80 users - 2-4 weeks, with the migration split into 2-3 stages

• 100+ users - 4-8 weeks, with phased migration split by departments or locations

The actual duration depends on the amount of data (terabytes in Drive significantly extend the process because of Google API limits), the selected tool (Migration Manager is slower than Quest or AvePoint), the complexity of external integrations (SSO, industry applications), and the client's availability to verify each stage. When planning the budget, assume the upper bound - extra time can be used to configure Microsoft 365 policies, while too little time creates stress and rushed decisions.

Pitfalls that come up regularly

This section is a distillation of several years of projects. The list is not complete - I am omitting pitfalls specific to particular migration tools or particular versions of Google Workspace here. I am leaving in what came up most often across different projects.

API limits on the Google side

Google imposes limits on how quickly data can be pulled from Workspace through the API. This applies both to the number of requests per second and to the daily transfer limit per account. With larger datasets, migration is not a matter of 'drag everything over with one click' - it is a process spread over days, sometimes weeks. Enterprise tools (Quest, AvePoint) handle this better than native ones - they have built-in retry, throttling, and migration resumption from the point of interruption, so even when a Google limit is hit, the process eventually finishes. When planning the schedule, assume that the initial migration of 100+ mailboxes with several years of history will take at least 3-5 days, plus additional days for delta migrations that synchronize the changes from the transition period.

Attachment size

Gmail accepts attachments up to 25 MB by default, Exchange Online up to 35 MB (the admin can raise this to 150 MB). In most cases this is not a problem, but with unusual Gmail limit configurations, individual messages with large files may fail to migrate. Migration tools report such errors - monitor the logs and move the missing emails manually.

Shared mailboxes and aliases

An account like 'office@' or 'secretariat@', used by several people, is recreated as a shared mailbox in Exchange. This is not difficult, but it is easy to miss during inventory. It is, in fact, missed routinely. In Microsoft 365, shared mailboxes up to 50 GB do not require a separate license - you only need to assign permissions to specific users. This is a major advantage over Google Workspace, where the equivalent account consumes a full license. Email aliases (additional addresses pointing to the same mailbox) are moved manually - migration tools move the mailboxes themselves, but skip alias configuration and forwarding rules.

Calendar and mailbox delegation

In Google Workspace, an assistant often has direct access to a manager's calendar and mailbox through native Google delegation. In Microsoft 365, this works differently - calendar permissions are configured through roles (Reviewer, Editor, Delegate), and mailbox access through Full Access with the Automapping option. After migration, check whether all such relationships have been recreated - standard migration tools do not do this.

Duplicate file names

Google Drive identifies files by an internal ID, so one folder can contain five files named contract.docx. SharePoint requires unique names within a folder - the migrator appends suffixes such as (1), (2). The result: after migration, files appear with odd endings, and users do not know which one is the correct one. Review Drive before migration and clean up duplicates on the source side - you will save yourself from explaining it to employees.

The 100,000-item limit in a SharePoint library

SharePoint has a hard limit for a single document library - 5,000 items per view and 100,000 items in the entire library without performance degradation. Large project folders from Google Drive (project archives, old marketing assets, document scans) can exceed this limit. The solution: instead of moving everything into one library, create several separate libraries within one SharePoint site. This needs to be anticipated during planning - migration tools will not do it automatically.

Storage limit in the tenant

SharePoint/OneDrive storage in Microsoft 365 is calculated globally per tenant, with a base of 1 TB plus 10 GB for each paid license. In larger migrations (several TB), it happens that this pool runs out halfway through the process. Buying additional storage packs is immediate, but it is better to estimate the need earlier than to react in rescue mode.

Automations in Google Apps Script

There is no good path here. Each option costs something - either rewrite time or ongoing maintenance of two worlds. Scripts in Drive, spreadsheets, and forms will not migrate - Apps Script is a native platform for Google Workspace and has no direct equivalent in the Microsoft ecosystem. For each script there are four options: rewrite to Power Automate (a visual equivalent with more than 500 ready-made connectors, often sufficient for typical automations such as 'send an email when a new row appears'), rewrite to Office Scripts (TypeScript running in Excel, functionally closest to Apps Script), keep it in Google and maintain two worlds (for business-critical scripts whose rewrite is risky), or retire it (for scripts that were created ad hoc and nobody remembers why). As part of the migration, do an inventory - often it turns out that 80 percent of scripts can be switched off without regret.

SSO integrations with external applications

If the company uses Google as an identity provider for other systems (CRM, HR tools, Slack, project tools, accounting apps), each of these systems needs to be switched over separately to Entra ID. Most popular SaaS applications support both standards (SAML 2.0 and OIDC), so from a technical standpoint this is a replacement of one configuration. In practice, it has to be coordinated with the vendors of the individual systems, a cutover window has to be scheduled, and user sign-in has to be tested. For 5-10 SaaS applications, this is a few days of work spread over time. Inventory the integrations before migration - sudden loss of access to a key business system creates more noise than email issues.

Backup on both sides

The same model applies in Google Workspace and Microsoft 365 - the vendor is responsible for service availability, not for restoring your data after accidental deletion or a ransomware attack. Migration is a good moment to put this in place right away in the new environment.

What happens after migration

Migration ends - administration begins. Microsoft 365 offers many more tools than Google Workspace, but that also means more decisions to make: Intune policies, conditional access rules, Defender, sensitivity labels, retention policies. A company that has used a simple Workspace for years will not configure this in two afternoons.

In the projects we run, the migration itself is 30-40 percent of the work. The rest is organizing the Microsoft-side environment so that the company actually uses what it pays for. Otherwise, it is just 'Gmail, now called Outlook'.

Frequently asked questions

Do Google Forms migrate automatically?

No. Google Forms have no equivalent on the migration-tool side - none of them move them over. Active forms are recreated manually in Microsoft Forms (for simple surveys and requests) or in Power Apps (for forms with conditional logic and integrations). Beforehand, inventory which forms are actually in use - some turn out to be forgotten and can simply be switched off.

Can users work during the migration?

Yes. In a phased migration, each group of employees works normally in Google Workspace until the day their data is switched over. In a one-stage migration, the cutover happens over the weekend, so Monday starts already in Microsoft 365. The typical productivity loss is a few hours on the cutover day - configuring the mailbox in Outlook, getting familiar with the new interface.

Is downtime required for the company?

With a well-planned migration - no. Data migrates in the background before cutover, MX records (mail) are switched over on the weekend or outside business hours. Users notice the change only after they begin working in the new environment.

How much does a Google Workspace to Microsoft 365 migration cost?

The cost has three components. Microsoft 365 licenses - starting at around 25 PLN per user per month (Business Basic) up to several hundred PLN for Enterprise E5. The migration tool - Microsoft Migration Manager is free, Quest On Demand Migration and AvePoint FLY are project licenses ranging from several hundred to several thousand euros depending on scale. Execution work - from several dozen to several hundred work hours depending on the size of the organization. In the Helpwise IT model, the migration itself is included in the ongoing cooperation agreement.

Can you go back to Google Workspace after migration?

Technically yes, but in practice it is more difficult than migrating the other way and requires a second project of the same kind. Make sure before migration that this is the right direction, and archive the original Google Workspace data via Takeout and keep it for at least several months after the migration is complete.

Will Google document version history be preserved?

No - standard migration tools do not transfer version history or comments. The file creation date changes to the migration date. For companies that rely on version history for audit or legal purposes, the solution is to archive the original documents in a separate location before migration. In Microsoft 365, version history starts building again from the migration date onward.

We run Google Workspace → Microsoft 365 migrations as part of ongoing cooperation with companies in Warsaw and the surrounding area. The implementation itself is included in the agreement - you pay for licenses, not for our team's billable hours. If you are considering such a project at your company, get in touch - we will start with a conversation about whether migration actually makes sense.