Migrating from Microsoft 365 to Google Workspace: a guide

How to decide whether Google Workspace suits your business

The decision to migrate from Microsoft 365 to Google Workspace should consider how everyday work will function afterwards. A business that mainly uses email, shared documents and meetings has a different project from one relying on Excel macros, Entra ID application sign-ins and SharePoint-based processes. Before comparing licences, identify these dependencies and assign a destination and an owner to each one.

Consider a purchasing department that receives requests in a shared mailbox, organises conversations into folders and records orders in a spreadsheet with macros. Copying messages to Gmail addresses one part of the requirement. The project must also establish who handles the departmental address, how work is distributed and whether the spreadsheet can remain in use. This illustrative example helps test complete processes during the pilot without assuming that a feature has an identical equivalent.

The review should produce a decision for each process: retain, adapt or replace it. If an application will still require Microsoft services, include its licensing and administration in future costs. This avoids presenting a subscription reduction as a saving when it later requires duplicate tools or additional manual work. Cases without a proven solution should be resolved before setting the change date.

What the email and calendar pilot must demonstrate

Validation needs repeatable cases at source and destination. A user should find an old email, open its attachments, locate an archived conversation and understand how their information is organised in Gmail. Exchange folders and Gmail labels use different models; explaining this through examples from the department is more useful than providing a list of copied quantities.

For calendars, test a meeting organised by the user, one received from an external party and a recurring series with exceptions. Check times, attendees, resource access and the ability to respond to changes. If the import method does not preserve a feature, record that limitation alongside the agreed alternative. The pilot record should distinguish missing data from an accepted change in behaviour.

Approve the change in email reception once the destination is ready and internal and external sending and receiving tests succeed. During transition, also review applications that send notifications using the corporate domain. A website or invoicing system still using the old configuration may fail even when users are working normally in Gmail.

1. Defining what a move to Google Workspace actually means

The first project document should describe the work the business needs to maintain, rather than simply list applications. “We use Outlook” is insufficient. Establish whether a person only checks their own email, manages three departmental accounts, books rooms, uses delegated calendars or consults PST files stored on their computer.

Interview the owners of critical processes and observe representative workstations. An inventory from administrative portals identifies objects and volumes, but may not explain their use. An apparently inactive account may still receive invoices or provide the identity used to authenticate a scanning device.

Separating email, documents and identity reveals workstreams that can run on different dates. For example, an organisation may move email to Gmail while temporarily retaining desktop Office. It could also retain some Entra ID-authenticated applications while reorganising documents in Drive. These decisions need defined owners and costs so that transition does not become an uncontrolled permanent coexistence arrangement.

A supposed equivalence between suites should not be the sole justification for change. A product catalogue helps compare features, but business processes provide the useful decision criteria. If users depend on SharePoint-linked automation or specific Outlook add-ins, assess replacements before approving the schedule.

A well-written scope distinguishes included information, configuration to rebuild and services to retain. It also identifies explicit exclusions: unrecorded local histories, third-party applications, advanced training or process redesign. Exclusions should be understandable to the service purchaser rather than hidden behind technical terminology.

2. Inventory: users, mailboxes and dependencies that change the project

The user inventory should connect the source identity, primary address, aliases, destination, account status and validation owner. Similar display names do not establish that two accounts belong to the same person. Mergers, renamed users and former employee accounts require explicit decisions. For email, measure item counts as well as size. A mailbox with many small messages can behave differently from one with a few large attachments. Recording both values supports a representative pilot and exposes estimates based only on gigabytes.

Inventory online archive mailboxes, PST files and device-only data separately. Do not assume that a tool reading the primary mailbox also covers every historical repository. The technical proposal should identify the method and verification procedure for each repository.

Every inventory entry needs an associated decision or task. Accumulating spreadsheets without resolving exceptions does not reduce uncertainty. If an account owner is unknown, leave an open action with a responsible person rather than automatically copying the account. Also record permissions needed to access the source. Technical authorisation should last for a period consistent with the project. The team needs to know who approves access, where secrets are held and who removes authorisations at completion. Without the necessary people available, a schedule can fail before the first copy starts.

3. Current tools: avoiding a plan based on retired methods

Google currently distinguishes default and advanced import methods for Exchange Online. The default method uses shared Google API quota. The advanced method uses an application configured in Microsoft and dedicated quota, and supports batch organisation. The general import documentation provides the current route for each data type.

Employee numbers alone should not determine selection. Historical archives, calendar characteristics, shared objects and environment scanning requirements also matter. The advanced Exchange Online method documents its own requirements, which should be reviewed before preparation is priced.

A particularly relevant product change is Google’s announcement that Google Workspace Migrate for Exchange Online becomes unavailable from October 2026. For SharePoint Online and OneDrive, the previous product no longer receives updates or fixes. An older guide proposing installation as the first option therefore needs technical review. The official Google Workspace Migrate notice links to the current alternatives.

Third-party tools may be appropriate where they meet requirements that the selected method leaves unresolved or support more controlled operation. Evaluation should request a compatibility matrix, licensing conditions, permission details and a pilot. A sales demonstration using a small mailbox without delegations is insufficient.

Compare verifiable scope, security, observability and total cost. An apparently free solution may require additional reconstruction work. A licensed option may reduce tasks, but that benefit must be demonstrated using the objects actually present. No single tool is the best choice for every business.

4. What is copied and what needs its own design

The official matrix of data imported from Exchange Online distinguishes capabilities by method. For example, the advanced method covers online archive mailboxes for active users and calendar permissions that the default method does not. Teams meetings retain their links but are not automatically converted into Meet meetings. Restrictions apply to certain objects and messages.

Translate those differences into business tests. If someone manages an executive’s calendar, a useful check is to open it, create an authorised appointment, edit an existing one and confirm expected visibility. Seeing a calendar with the same name does not demonstrate working delegation. Explain folder-to-label conversion to users beforehand. Searching, moving a message and viewing a conversation may feel different even when content is available. Support teams need examples to distinguish a behaviour change from a migration incident.

Do not present another tool’s limits as universal. Procedures based on Outlook, PST, IMAP or the current import service can have different capabilities and restrictions. Attribute each limitation to its method. This avoids excluding data another approach could handle or promising a transfer the selected method does not support.

For each exception, decide between reconstruction, temporary retention, controlled export or process replacement. Record where the information will reside and who can consult it. A documented exclusion without an accepted alternative may be technically transparent yet still leave the business unable to access necessary data.

5. Shared mailboxes, groups and departmental email

An Exchange shared mailbox and a Google group do not necessarily provide the same experience. Before selecting the destination, observe how the department works: whether several users read the complete history, need to reply with a common address, assign conversations or only receive message copies.

A delegated Gmail account may suit a process requiring a common inbox. A group configured as a collaborative inbox may suit conversation assignment and resolution. Google documents the functions of a Groups collaborative inbox, but users who will work with the solution should validate the choice.

The decision also affects licensing, administration, search and training. Do not automatically turn every departmental mailbox into a full account or a group. Define required behaviour first, then validate cost and import compatibility. In a hypothetical example, five people handle a purchasing address. Two need the complete history, while three only receive selected messages. Copying content without redesigning access could unnecessarily widen visibility. Document who administers, reads and replies from the shared address.

Distribution lists also need an inventory. Review members, owners, permitted senders, external reception, moderation and alternative addresses. A test from an internal account does not establish that an external supplier can contact the group. Include that test in the pilot where the process relies on third parties.

6. Identity, authentication and connected applications

Changing email providers does not automatically move business identity. An organisation may still need Entra ID for applications, devices or Azure resources while Gmail becomes its messaging service. Separate email decisions from the retirement of Microsoft identities and licences. Inventory SSO applications, directory-dependent services and Microsoft Graph automation. Also review HR integrations, provisioning, offboarding and groups. A manually created Google account may work in the pilot yet remain outside normal employee onboarding procedures.

Prepare multifactor authentication before the general change. Define permitted methods, account recovery, emergency access and support for users who lose a device. Transition is a poor moment to discover that support cannot assist without password sharing. Identity tests should include corporate computers, mobile devices and typical remote scenarios. If federation is used, check what happens when the identity provider is unavailable. Administrators need an approved and understandable recovery procedure for the architecture.

Microsoft provides criteria for planning application and authentication migrations. In this project, they reinforce the need for application-specific testing and owners. Retain the previous identity environment until its dependencies are understood and resolved.

7. Domain and DNS: receiving email is only part of the change

Verify the domain in Google Workspace and prepare recipients before changing public delivery. Google explains the current procedure in its guide to configuring MX records. Obtain values from the applicable configuration and documentation rather than copying records indiscriminately from an old project. DNS changes do not reach every sender simultaneously. Some messages may still arrive at the previous service during transition. Maintain a known route for residual email and check it before retiring the source. Lowering TTL beforehand may help, but does not remove every cache or make the window instantaneous.

Alongside receiving messages, maintain application delivery. An ERP, website, printer or alerting system may send using the corporate domain. These senders need a compatible method and correct authorisation. SPF should represent actual senders, as explained in the official SPF guide.

DKIM needs configuration and a signing test. Publishing a key alone is insufficient: confirm that new-service messages are signed and recipients can verify them. The DKIM documentation describes generation, publication and activation. Review DMARC during the change to avoid disrupting legitimate senders. Google’s recommended gradual implementation uses report observation and stronger policy enforcement as flows are validated. If a strict policy already exists, justify any adjustment with tests and a review date. Migration should not become an indefinite reduction in protection.

8. Destination preparation and a representative pilot

Prepare the destination before copying data: accounts, licences, groups, enabled services, security policies and administrative responsibilities. The default method guide specifies that accounts must already exist and are not automatically created by import. This distinguishes provisioning from content import. Select different behaviours for the pilot. A user with many folders, another with delegations, a room, a departmental mailbox and a mobile worker provide more information than five identical accounts. Match sample size to risk and diversity rather than an arbitrary number.

Give each participant specific tasks and a results channel. “Check your email” is too broad. Request known searches, attachment opening, external message replies, meeting changes and access to the usual shared resource. The pilot also tests the technical team’s operation. Check reporting, error identification, resolution effort and post-change support. If diagnosis requires manually examining every account, include that effort in planning the general batch.

Do not approve the pilot while unresolved problems affect a critical process. A minor exclusion may be accepted with an alternative, but loss of departmental email access or unresolved authentication requires correction and repetition of the relevant test. The pilot reduces uncertainty before expanding impact.

9. Premigration, change window and delta

Premigration transfers history while users continue working at the source. It reduces outstanding data in the final window, but does not replace testing or guarantee complete synchronisation of every change. The team must understand how its tool handles updates and retries.

A delta copies new or updated content according to the selected method’s rules. Google describes this behaviour in the Exchange Online delta guide. It should not be presented as universal mirroring or an automatic way to return the destination to the source state. The change window needs a sequence and decision points. Check copy status, confirm destination readiness, change mail flow, then validate sending, receiving and access. Assign an owner and evidence to every step. A call with many participants is not a substitute for an ordered change procedure.

User communications should state the start time, the service to use and the support contact. Explain where to find historical information, how to access calendars and what to do if a message is missing. Send brief instructions before the window to avoid relying on the email service being changed.

Rollback needs separate consideration. Returning MX records to the source does not automatically take messages already received in Google back to Exchange or undo calendar changes. State when rollback remains viable, how destination-created information is retained and who authorises the decision. Without reconciliation, rollback can leave two incompatible operational versions.

10. Validating data and operation with meaningful comparisons

Validation combines import reports and functional testing. Review successful, failed and skipped items and warnings per account. Transfer totals are useful when the denominator is explained: which content was in scope and what was deliberately excluded. Source and destination counts are not always directly comparable. Document duplicate, conversation, folder and label handling. When a difference appears, identify a verifiable cause and run targeted samples. Accepting every difference as normal is as inappropriate as requiring mathematical equality without understanding the models.

A useful sample includes old and recent content, internal and external messages, attachments and items affected by exceptions. Business owners contribute known cases that administrators cannot select from statistics alone. A particular invoice or important recurring meeting may expose problems missed by random sampling.

Record acceptance by service. Email may be validated while an application still needs adaptation. Separate these states to maintain a clear view of progress without declaring the entire project complete. The incident list should identify impact, workaround, owner and expected resolution date.

11. Costs, timescales and technical closure

The budget should include destination licences, possible Microsoft overlap, migration tools, preparation, testing, training and support. Distinguish recurring costs from project tasks. Per-user price comparisons alone can conceal applications or security controls that remain separately licensed. Duration depends on inventory, object diversity, team capacity, service limits and available windows. Estimate by phase and revise the forecast after the pilot. There is no guaranteed speed for every mailbox or duration based solely on user count.

In a hypothetical business of 120 employees, message transfer may finish before customer service email has been adapted. Resolve that process before the general change or plan a separate transition. Scheduling the date simply because copying is complete would put the timetable ahead of continuity.

At closure, retain the inventory, decisions, reports and support procedures. Remove temporary access, review authorised applications and confirm which previous services can be retired. Retirement should be an approved task after acceptance, rather than an automatic gesture to show completion. If documents are included, treat them as a separate workstream with structure, permissions and recovery criteria. Kloudeal provides business email migration and Google Workspace implementation. This distinction helps define a proposal suited to the requirement without treating every platform as interchangeable.

12. Checks before approving the change

The review confirms that every source account and address has an owner-reviewed destination; historical archives, files and local data have defined handling; the pilot includes relevant delegations, calendars and departmental email; authenticating and sending applications have been tested in the final design; domain sending and reception work with verified authentication; errors and exclusions have been explained and accepted with alternatives where appropriate; change, support and rollback procedures have clear responsibilities; and licence retirement and temporary access removal follow dependency validation.

Select the method from the scope and demonstrate results with a pilot. For straightforward email environments, the default method may suffice. Where historical archives, permissions or batch operation are involved, assess the advanced method and specialist alternatives. In either case, approve the change because people can work and critical processes function, with evidence of the agreed outcome rather than relying solely on a completed progress indicator.

Sources and updates

Official documentation consulted on 12 October 2026. Import capabilities evolve. Review product links before executing a migration and record the method and configuration validated in your pilot. This guide provides planning criteria; it does not certify a particular environment or guarantee transfer times.

Frequently asked questions

Does Exchange Online import also move SharePoint and Teams?

Importing email, contacts and calendars should not be interpreted as a complete Microsoft 365 migration. Documents, sites and collaboration processes need their own scope and method. Before the change, identify information destined for Drive and the Teams or SharePoint functions requiring adaptation, retention or replacement.

What happens to shared mailboxes when moving to Google Workspace?

First define how the department will use that address at the destination. Receiving messages, replying with a common identity and distributing tasks are different requirements. Select the solution according to those uses, then test with several employees. Copying historical messages does not establish that departmental email operation has been resolved.

Can existing email remain available while the change is prepared?

Import copies information and can prepare the destination before changing domain reception, depending on the method. Make clear where users work at each stage and which final update will be performed. Keeping both environments open without usage rules can create replies and new data in different places.

How do we know migration to Gmail is complete?

Completion is demonstrated through data and operational testing. Review import reports, explained incidents and a sample of messages, attachments, contacts and calendars. Users must also be able to send and receive email and complete normal processes. Approve closure with documented outstanding exceptions and their owners.