How do we migrate from Google Workspace to Microsoft 365?

What does a Google Workspace to Microsoft 365 migration include?

The project is wider than moving Gmail into Outlook. Employees may rely on Drive files, shared drives, Google-native documents, calendars, contacts, Forms, scripts and links embedded in other systems. The business needs to decide where each workload belongs and how it will operate after the move. Without that decision, a technically successful email migration can leave important work disconnected or difficult to find.

Begin with a business inventory and a clear statement of scope. Name the users, departments and workloads included, along with anything that will remain in Google temporarily. Record dependencies such as a customer portal using a Google login or a spreadsheet feeding a monthly report. NetMonkeys’ cloud migration services provide a relevant route to discussing the transition as a coordinated project rather than a collection of file-copying tasks.

Why should we decide the destination structure before copying files?

A personal Drive folder and a team’s shared working area do not necessarily belong in the same destination. Information owned by the business should have a durable owner and appropriate team access. Personal working files may suit OneDrive, while shared operational documents may suit a SharePoint site or Teams-connected library. The right structure depends on collaboration and information ownership, not simply the folder’s current location.

Map source locations to named destinations and have information owners review the design. Avoid copying an untidy estate unchanged and expecting search to solve every problem. Equally, do not turn the migration into an unlimited content-reorganisation programme. Agree which cleanup is essential before the move and which improvements can follow. A controlled first scope is easier to validate and explain to employees.

What information should we collect during discovery?

Record user counts, mailbox sizes, file volumes, shared resources and any unusual requirements. Include external collaborators, delegated mail access, shared calendars and business-critical spreadsheets. Find out who owns each shared drive and whether that owner can approve its destination and permissions. Identify dormant content separately from content that may be retained for a valid business purpose. Deletion and migration are different decisions.

Ask departments to demonstrate important workflows. A simple example is a sales team that captures leads in Forms, writes them into a Sheet and sends notifications through a script. The documents may be easy to copy while the process needs redesign. Discovery should reveal that dependency before the old service is retired. Keep a record of assumptions and unresolved questions, each with an owner and a deadline for resolution.

How should we prepare the Microsoft 365 tenant?

Prepare identities, domains, licences and the intended access controls before migrating production data. Confirm that administrators have the access they need and that ordinary users receive suitable role-based entitlements. Test representative sign-ins, mailbox access and collaboration from the actual devices people use. A destination that exists but has not been operationally tested is not ready for a business cutover.

Agree the support and ownership model at the same time. Who handles a blocked sign-in, a missing file or a phone that still connects to Gmail? Which changes need internal approval? NetMonkeys’ Microsoft 365 support services can be considered alongside the migration so that the environment has a clear service owner after the project team finishes. Implementation and ongoing operation should fit together.

How does the email migration work at a high level?

Choose a supported migration method based on the current environment and the requirements. Microsoft provides a Google Workspace mailbox migration route that can move mail, calendars and contacts in batches, with preparation required on both sides. The exact configuration should follow the current official procedure and a tested plan. An organisation should not rely on a generic set of old screenshots for a live mail migration.

Use Microsoft’s Google Workspace migration guidance to verify the chosen route and its limitations. That guidance identifies particular items requiring attention, including shared calendars and room bookings, and recommends checking migrated rules before enabling them. Put any unsupported or separately handled items into an exception register. The business should know what is being moved, what is excluded and how exceptions will be addressed.

How should Google Drive and shared drives be handled?

Treat file migration as its own workstream with an inventory, destination map and permission design. Assess the chosen tool against file types, versions, ownership, sharing and any conversion requirements. A tool saying that a file copied successfully does not prove that employees can use it correctly in its new location. Representative testing should include the documents and collaboration patterns departments actually depend on.

For shared content, decide whether a SharePoint structure will make ownership and access clearer. Define sites and libraries around durable business needs, with named owners and manageable membership. Avoid creating a single enormous library simply because the source contained one large shared area. Equally, avoid excessive fragmentation that forces employees to search many disconnected locations for one process. The structure should support everyday work and be understandable to its owners.

What happens to Google Docs, Sheets and Slides?

Identify which native Google files need conversion and which may need a different treatment. Test documents containing complex formatting, formulas, charts, comments or linked content. A converted workbook may look familiar while a calculation or connection behaves differently. Have the process owner validate the output rather than relying only on the migration tool’s success count. Preserve the agreed source evidence until acceptance is complete.

Make conversion decisions early enough to resolve difficult examples. Some files may be better rebuilt, archived or temporarily retained in a controlled source location. Communicate the approach so employees know which copy is authoritative. Avoid allowing two active versions to diverge unnoticed. Where the new workflow changes how a department works, include a short practical guide and a support contact rather than expecting users to discover the differences during a deadline.

How can we avoid migrating inappropriate permissions?

Inventory who can access sensitive and shared information before designing destination access. Broad source sharing should be reviewed by the information owner rather than automatically reproduced. External collaborators, public links and former staff access deserve particular attention. At the same time, avoid removing valid collaboration access simply because nobody recorded the business reason in an old folder description.

Define access through manageable groups and named owners where suitable. Test with representative user accounts, including someone who should be denied access. An administrator’s successful access tells you little about an ordinary employee’s experience. Keep an exception list for permissions that cannot be translated directly and obtain a decision from the relevant owner. The objective is an appropriate destination design with evidence of how it behaves.

Should we migrate everyone at once or in batches?

The right approach depends on dependencies, scale and the organisation’s ability to support the transition. A single cutover can simplify the final state but concentrates disruption. Batches can spread the work while introducing a period in which two environments must coexist. Teams that collaborate constantly may need to move together. A purely alphabetical user list can split processes in unhelpful ways.

Group users around operational relationships and test how mail and file collaboration will work during the transition. Explain which service is authoritative at each stage and how employees contact colleagues who have not moved yet. Include directors, assistants, shared resources and specialist workflows in the planning. A batch should be a manageable business unit with a clear acceptance route, rather than just a convenient number of accounts for the migration tool.

What should a representative pilot prove?

Choose users and content that expose the awkward cases, not only the simplest mailboxes. Include delegated access, large or complex documents, mobile devices and external collaboration. Agree checks before the pilot begins, so that success is not redefined around whatever happened to work. Record any missing, skipped or transformed items and decide how they will be resolved before the main rollout.

The pilot should also test the employee experience. Can users sign in, find key files, send and receive mail, join meetings and complete the workflows their managers identified? Can support staff diagnose the problems without relying on one specialist? Use the findings to improve instructions, timing and resource estimates. A useful pilot reduces uncertainty and changes the plan where necessary; it is more than a demonstration that data can be copied.

How do we plan cutover and mail routing?

Create a written sequence with owners, prerequisites and verification steps. Include the domain and DNS work required for the chosen approach, mail routing checks, final synchronisation and the actions employees must take. Make sure the people able to perform each step are available during the agreed window. A plan depending on an absent domain administrator is not ready, even if all mailbox copies have finished.

Define a decision point for proceeding, pausing or invoking the agreed recovery approach. Recovery must reflect the selected migration method and the state of data, rather than a vague promise to reverse everything instantly. Keep communication channels available outside the service being changed. Employees need to know where to report problems if email is temporarily unavailable or their new account does not work as expected.

How should we verify that data has arrived correctly?

Combine migration-tool reports with business checks. Reconcile the agreed source inventory with completed, skipped and failed items, and investigate exceptions. Use representative samples to inspect mail dates, attachments, document usability and permissions. Counts are helpful, but differences may have valid explanations such as labels, duplicates or conversions. Document those explanations rather than assuming every difference is harmless or every mismatch means loss.

Ask information owners to sign off the parts they understand. Finance can validate critical workbooks; HR can validate confidential access; sales can check customer correspondence and shared resources. Keep evidence proportionate and avoid unnecessary copies of sensitive data. Completion should mean that agreed content and processes have been checked, with outstanding issues resolved or explicitly accepted. It should not mean only that the migration tool stopped running.

What training helps employees adapt quickly?

Teach tasks rather than presenting a tour of every Microsoft application. Show where team documents belong, how to share a link, how to find previous versions and how to report a permission issue. Explain the difference between personal working space and team-owned information. Use examples relevant to each department and make instructions easy to find after the live session has ended.

Provide additional help during the first normal business cycle after cutover. Some problems appear at month-end, during a customer meeting or when an infrequently used process runs. Keep a visible issue log and publish short answers to repeated questions. Training should support the destination design, so that employees do not recreate the old problems through local copies, attachments and improvised personal folders in the new environment.

When is it safe to retire Google Workspace?

Retirement should follow agreed acceptance, information-preservation and commercial checks. Confirm the status of mail, files, calendars, integrations and remaining exceptions. Check that departments are working in the intended destination and that required records have an approved home. A functioning Microsoft 365 tenant does not by itself establish that the old service no longer has a purpose.

Review renewal and overlap costs, but do not let an approaching invoice force an untested shutdown. Remove unnecessary migration permissions and temporary access when the relevant work is complete. Retain project records, destination ownership and the support handover. NetMonkeys can discuss a scoped Google Workspace to Microsoft 365 migration with clear workload boundaries, acceptance checks and support responsibilities, so that the transition ends with an environment the business can operate confidently.

How should we handle a difficult pilot result?

Suppose a pilot employee can read migrated email but cannot use a shared calendar in the way the team expects. Do not classify the whole pilot as successful because the mailbox transfer finished. Record the original task, the relevant calendar, the expected destination behaviour and the observed result. Ask whether the problem comes from a migration limitation, a permission difference, an account mapping or a change in how the applications work. Each explanation leads to a different remedy.

Use a decision log for differences that cannot be reproduced exactly. For example, a team may accept a different booking process if it preserves the business outcome and staff have tested it. That is an agreed process change, not a missing migration task to conceal. Name the person who accepts it, update training and include it in support instructions. If the difference prevents an essential task, pause the affected rollout group until a supported alternative has been demonstrated.

File testing needs similar care. Choose examples containing formulas, links, comments and shared editing, rather than checking only that a document opens. Where a conversion changes behaviour, retain an approved preservation route and document which version is authoritative. Avoid having staff independently edit both source and destination copies while the team investigates. An uncontrolled parallel version can create a business problem even when both files remain available.

Keep the pilot deliberately small enough to investigate every material exception. After a correction, repeat the original test and a related test that might also be affected. Maintain the evidence with the cutover record so later migration groups benefit from what was learned. The value of a pilot is that it changes the plan before a problem affects everyone.

What should the service desk receive before cutover?

Give support staff a concise record of the migration groups, planned change window, expected sign-in experience and known differences. Include the owner of mail routing, the owner of files and a contact route outside the changing email service. Explain how to distinguish a missing item from a different folder view, delayed synchronisation or a permission problem. Support staff should know which checks are safe to perform and which issues need escalation.

Prepare an exception register with a reference number, affected workload, business impact and next action. Do not collect passwords or unnecessary message content in tickets. After cutover, review recurring questions with the migration lead and improve guidance where the same confusion appears repeatedly. This closes the gap between transferring information and helping employees work reliably in the new environment.