Business collaboration migrations

Microsoft 365 to Google Workspace migration.

We plan the transition of email and collaboration services to Google Workspace. We assess Exchange Online, OneDrive and SharePoint, define where the data will be held in the destination environment, and coordinate testing and the change of service with your organisation.

Request a migration assessment Explore the service scope
Professionals reviewing documents and a tablet during a project meeting

The migration starts with an understanding of how your organisation uses Microsoft 365. We review users, domains, mailboxes, files, permissions and connected applications. From that inventory, we propose which information to move, which elements need to be rebuilt in Google Workspace and which should remain temporarily in the source environment. The work may cover email alone or a broader transition; the services included are specified before implementation begins.

Each set of data needs its own migration method and its own checks. User numbers, data volumes, licensing, permissions and the functions currently in use determine the scope of the work and the tools appropriate to the environment.

  • Email and foldersWe review mailboxes, historical messages and folder structures to prepare their transfer to Gmail. Folders may be represented as labels in the destination. Excluded items, messages subject to restrictions and import incidents are identified in the migration plan and recorded in the relevant reports.
  • Calendars and contactsWe assess personal, shared and resource calendars, recurring events and contacts. We check what the selected migration method supports and which mappings are required for the environment. Existing Teams meetings are not automatically converted into Google Meet meetings as part of the migration.
  • OneDrive and SharePointWe create an inventory of libraries, folders, owners and access permissions. We define which information should be held in My Drive or in Google Drive shared drives. SharePoint sites, lists, pages, workflows and integrations require their own assessment: transferring files does not recreate a SharePoint portal in the destination platform.
  • Shared mailboxes and groupsWe assess how messages are received, distributed and answered by the teams using them. We agree the destination operating model and validate it with those responsible. Distribution lists, groups, aliases and delegation settings are reviewed separately, without assuming that the two platforms offer an exact functional equivalent.
  • Identity, domain and DNSWe prepare the destination users and groups, coordinate domain verification and plan the change in mail flow. We review MX, SPF, DKIM and DMARC records, applications that send messages and sign-in requirements. Administrative permissions are defined according to the tasks that need to be performed.
  • Access and user adoptionWe organise checks of Gmail, Calendar and Drive with a representative group of users. Where included in the project, we review devices, email clients and access to documents. Training, assistance during the transition and subsequent support are defined as specific pieces of work within the agreed scope.

Changing platforms also changes the way people work. We review the use of Outlook, delegation, meetings, shared links and integrations before agreeing the destination design. Not every permission, setting or item has a direct equivalent in Google Workspace. Exceptions are documented and tested with the users affected so that the differences are understood before the transition.

The strategy may concentrate the change into one window or divide it across groups of users. The choice depends on domains, dependencies and the operation of the business. If coexistence between the platforms is required, it is explicitly designed and quoted, including mail flow, calendars and administration during that period.

  1. Inventory and design

    We identify users, workloads, volumes and dependencies. We define responsibilities, the destination for the data, the tools, exclusions, change windows and acceptance criteria. The proposal records the conditions that need to be in place before work can begin.

  2. Preparation and pilot testing

    We configure the destination elements included in the scope and check the access required for migration. We run a pilot with representative users and data, review errors and adjust mappings before extending the transfer to the rest of the agreed environment.

  3. Transfer and transition

    We carry out the planned migration passes and coordinate the change of domain and user access. Subsequent passes are applied where supported by the relevant tool and dataset. We communicate any actions that users need to carry out themselves as part of the transition.

  4. Validation and handover

    We compare migration reports with functional checks, review exceptions and record acceptance. We document the configuration and any outstanding tasks. The withdrawal of temporary permissions and the closure of the source environment are coordinated within the scope agreed for the project.

  • Migration planThe scope inventory, mappings, project phases, responsibilities, change windows and criteria used to validate the migration result.
  • Results and exceptionsExecution reports, significant incidents, items that were not transferred and the checks agreed with the people responsible for the environment.
  • Handover documentationThe configuration included in the project, changes to DNS and access, recommendations and tasks that will need to be taken over by your IT team.

Licences, tool usage, coexistence, third-party applications and support after migration are detailed in the proposal. An email migration does not automatically include Teams, Power Platform or the rebuilding of SharePoint sites. The source environment is retained for the agreed period; deleting it requires a specific decision from the customer once the relevant requirements have been reviewed.

Yes, using methods that support those types of data and after reviewing their configuration. Google provides import options for Exchange Online, with differences between the available methods. The pilot confirms which items can be transferred, the mappings required and the exceptions that apply to the particular environment.

We assess the files and their organisation to define the destination in Google Drive. The structure, ownership, permissions and functional differences need to be validated. SharePoint pages, lists, automations and applications are treated as additional components that require their own scope and assessment.

The timescale depends on data volume, the number of objects, platform restrictions and the change windows available. We estimate it after the inventory and pilot stages. We distinguish preparation and transfer time from the window in which users actually move to the new service.

The domain can be retained when the project includes its verification and the change in mail flow. We review aliases, groups, sending applications and DNS records to coordinate the transition. Keeping an email address does not mean that every Exchange feature will have an identical equivalent in the destination.

Existing meeting links are not automatically transformed into Meet links. We need to review any continued use of Teams, which events should be recreated and the instructions required for organisers and attendees. The treatment of these meetings is agreed before the change takes place.

Yes. The service is delivered remotely and coordinated with your administrators and technical contacts. We agree the access required, points of contact, customer tasks and validation arrangements. We can work on a specific project and define ongoing administration or support separately where required.

Discuss your project with Kloudeal.

Tell us about the current environment, the workloads involved and your target date. We will review the information to define the scope more precisely and agree the next steps for assessing the migration.