Google Workspace migrations
We plan the transfer of email and collaboration between two Google Workspace environments. The service supports business consolidations, acquisitions or separations, with a defined scope, testing and coordination of the change, taking account of the users, information and access arrangements involved in the transition.
Discuss the project Explore the service scope
Starting point
Two businesses can use Google Workspace while maintaining different structures, domains and sharing arrangements. Bringing them into one organisation requires decisions about where each user will be located, who will own the information and how teams will access their documents. Those decisions need to be made alongside the transfer plan and the configuration of the destination.
We begin by distinguishing an actual migration between organisations from a domain change or internal reorganisation. We define the relationship between source and destination identities, the workloads included and the conditions the destination must meet. This avoids pricing only for mailboxes when the work also affects documents, ownership, permissions and the way people collaborate across the organisation.
The service can cover full consolidation, transfer of a group of users or separation of a business unit. Data, applications and permissions that must remain in the source are identified before execution starts, so that the migration scope and the responsibilities for retained information are clear to the teams involved.
Data and collaboration
An inventory of mailboxes, volumes, labels and addresses. We review which items the selected method supports and check a sample of messages and attachments in the destination, using the validation criteria agreed for the project.
Identification of the personal and shared calendars, resources and contacts included. Meetings, delegation and special settings need specific checks, with their treatment and validation defined according to the source configuration and the migration method selected.
Review of ownership, volumes, structure, file types and permissions. Documents owned by third parties require an approach agreed with their owners, so that the project distinguishes content the organisation controls from information that depends on another party’s action.
An inventory of drives, members and roles. We define the destination and identity mappings before transferring content and checking access, taking account of how the drives are used and who needs to work with them after the move.
Preparation of users, groups, aliases and the domain where these form part of the project. We coordinate the service change with those responsible for DNS and administration of the organisations, agreeing the sequence and dependencies before the cutover window.
A separate review of integrations, authentication, automation and other Google products. Their transfer or adaptation is included only where described in the proposal, with the required work and any exclusions stated explicitly rather than assumed from the migration of Gmail or Drive.
Compatibility
The method depends on the contracted editions, workloads, volumes, authorisations and restrictions of each organisation. Native and specialist tools provide different coverage. We select the combination after analysis and test it through a pilot, comparing the result with the requirements and validation criteria agreed for the project before wider execution.
Google’s documentation distinguishes supported data from settings that are not retained. For example, Google Workspace Migrate does not transfer every meeting link or every version of native documents. Copying a file should also not be assumed to repair links in other documents or emails that still point to the original. These dependencies need to be reviewed before the change.
These differences become a list of decisions: what migrates, what is recreated, what is excluded and what users will need to review. Access requirements, retention and information that must be preserved are agreed before transfer, so that the proposed work and any remaining responsibilities are understood by the organisation and its users.
Execution
We record the organisations, domains, users, mailboxes, drives and volumes. We define account mappings and identify the people responsible for validating email, documents and access in the destination, giving the project a clear basis for preparation and checking the transfer result.
We check licences, permissions and destination configuration. We run a pilot using a representative sample and compare the result with the agreed criteria, identifying exceptions and any changes needed to the method or preparation before proceeding with the wider transfer.
We organise the planned transfers and change window. We coordinate the included domain and email tasks and the actions that depend on the client’s team, so that the sequence and allocation of responsibilities are clear before services change to the destination.
We review logs, exceptions and data samples. We check access with the responsible team and hand over the results, outstanding issues and operational recommendations, establishing what has been validated and which tasks still need attention after the transfer and service change.
Project outcomes
Scope, mappings, execution sequence, change windows and project responsibilities, recorded so that the work and its dependencies can be followed by the teams involved.
Pilot results, agreed checks and a record of the exceptions identified, providing a basis for assessing the transfer and deciding which remaining items require further action.
Documentation of the work carried out and outstanding tasks needed to administer the destination environment, with the relevant operational information passed to the responsible team.
The quotation identifies technical work, tools, licences and subsequent services. Ongoing administration and extended coexistence need their own scope. Closure of the source environment is decided after validation and a review of retention requirements, so that completion of the transfer is distinguished from the decision to stop using or retain the original services and information.
Frequently asked questions
No. A domain change may be handled within the existing organisation. Migration between organisations requires a review of accounts, data and access in a separate destination. We assess the objective before proposing the method, establishing whether the requirement is a domain change, internal reorganisation or an actual transfer between independently administered environments.
These workloads can form part of the project. Coverage is confirmed according to the method, editions, permissions and tests. Shared drives, third-party files and special settings are inventoried separately, so that supported transfer is distinguished from items needing additional work, owner action or specific validation in the destination.
This should not be assumed. Changes to identities and ownership can affect permissions and links. We agree which items will be recreated, which require action by owners and which exceptions need to be communicated to users. The review establishes what can be validated through the migration process and what needs separate attention afterwards.
Transfer of the domain and addresses is assessed together with the source and destination configuration. Dependencies and the change sequence are documented before the go-live window, so that the domain move, account preparation and mail flow requirements are coordinated with the information transfer and the point at which users begin using the new organisation.
These items need a specific review. They are not automatically included when Gmail or Drive is migrated. The proposal identifies the covered components, intended treatment and exclusions, so that the project scope distinguishes each additional product or integration from the email and file workloads included in the transfer.
We consider users, data volumes and file counts, shared drives, domains, permissions, tools and the target date. The initial inventory and a representative sample help define the effort and licences needed, taking account of the transfer method, preparation and validation required for the organisations and workloads involved.
Related services
Tell us the users, organisations involved, shared drives and intended date. We will define the scope using that information, identifying the preparation, dependencies and validation needed for the proposed transfer between environments.