How to plan Domain Migration for Google Workspace without affecting workloads in Google Cloud

Whenever there is a merger of two or more acquired companies, there is a significant amount of planning required to draw the roadmap to sync the domains, platforms and practices between the organisations.

If the two Companies are already using Google workspace and Google Cloud Platform then the domain migration could ease up. This post highlights some key points on the expected issues and their resolution.

With the Businesses moving rapidly towards growth, Acquisitions have become very common these days.

Syncing the acquired entity with its own rules/processes and platform tends to be the most tedious and nerve wrecking activity for the Parent entity.

The cherry on the cake for any Acquirer would be to realize that the Aquiree already uses similar platforms(Google Workspace, Google Cloud etc.) and tools.

While this becomes easy for both to proceed with the digital merger, there are still few hiccups that can be witnessed.

In this post, I would like to outline some key points that can expedite the Google Workspace domain migration journey with minimal impact on applications and infrastructure hosted on Google Cloud.

Few reasons why a Customer plans for Domain Migration:

1. Customer has acquired a new Company and wants to collaborate more efficiently
2. Customer wants to rebrand itself with a new name or entity
3. Customer wants to split one of its divisions into a standalone entity with a new domain name

In this post we will cover the most common scenario (Point 1) and how to complete the domain transfer/migration efficiently and with minimal disruption to Business.

Types of Domain Transfer when the Acquirer and Acquiree leverage both Google Workspace and Google Cloud:

1. Complete domain transfer-

Here the Google Workspace and Google Cloud Projects of the child entity are merged completely into the parent entity.

Benefits- The workspace users/Google Cloud projects/Internal Applications etc. all come under one roof/org.

Cons- While Google Workspace domain transfer is common in both the scenarios, it takes huge efforts to migrate Google Cloud projects from one entity to another, there are a lot of checkpoints, updation of configurations required in this case. Also there is very limited value addition in migrating Google Cloud projects from one domain to other domain as compared to the efforts and cost involved for such use cases.

2. Partial domain transfer-

Here only Google Workspace of the child entity is merged into parent entity’s Google Workspace. There is no migration of Google Cloud org/projects from child to parent.

Benefits- Google PSO offers seamless Google Workspace domain transfer services to the Customers. Customers can seamlessly collaborate on all Google Workspace products, applications and services with the newly acquired entity without having to migrate/disrupt their Google Cloud side of things. There are minimal efforts and no extraordinary costs involved on the Google Cloud side of things.

Cons- If there are third party services involved on the Google Cloud side then there will be a one time re authentication setup required for these services during the cutover activities and this needs to be preplanned with the TAM’s of respective products(example VPN settings, teleport etc.).

How to successfully complete domain transfer without migrating Google Cloud projects to the new domain?

In any of the domain transfer scenarios all the internal users are transferred to the new domain. Think what will happen when your Google Cloud projects hosting your internal applications stay in the old domain but the users have been transferred to another domain?

Yes you guessed it right, these users will become external users to the old domain. This will basically lock them from accessing their own internal applications until and unless some solution is put in place. Ex. The internal applications OAuth consent screen which is setup as internal will think that the users trying to authenticate are externals and will deny access to them.

Imagine if you are heavily using OAuth Consent Screen and previously you were using it as an internal screen, now you may think of changing the consent screen as external, as the only viable solution to let your users access it from a new domain. This solution opens a security vulnerability where your applications will be accessible by anyone having a valid gmail account over the internet, even if you say that there is a VPN in place as a second layer of defence but that still does not justify compromising the first layer of security.

In order to overcome this issue there is a solution in place which is still not GA. Within this solution below activities are to be done:

1. Customers should create an internal ticket for Google from the bug portal for ‘App Security Team’ and mention the details of their Google Workspace Customer ID of the Old and New domains along with the details of the old and new domain name.

Ex- Parent Google Workspace Customer ID — 254XXXX

Child Google Workspace Customer ID — 261XXXX

Parent Domain- xyzcompany.com

Child Domain — 123company.com

In this ticket they should ask Google to whitelist the child domain under the parent domain.

2. Once Google confirms that they have completed the whitelisting. procedure under the hood, then go to the parent domain’s Google Workspace admin console with admin/owner privileges -> Access and data control-> API controls-> check the flag ‘Trust internal, domain-owned apps’

Once this is done, the parent domain will start considering all of its child’s applications as its own and all the users from the parent domain will be able to access the internal applications just like they used to do previously(before the domain transfer).

The Benefits:

1. Customers can seamlessly perform a domain transfer with the 1 fits for all method as they keep acquiring new companies. They can request for white listing as many child domains as they want in future.
2. There is no security vulnerability opened on the OAuth consent screen front since the screen remains as is(internal) in this use case.
3. This setup is simple and can be pre-provisioned(whitelisting can be done in advance before the D-day).
4. Customers get to see the best of Google products and services when it comes to interoperability and collaboration.