When two become one: Integrating Google Cloud Organizations after a merger or acquisition

Congratulations! Your company just acquired or merged with another organization, beginning an important new chapter in its history. But like with many business deals, the devil is in the details — particularly when it comes to integrating the two companies’ cloud domains and organizations. In this blog post, we look at how to approach mergers and acquisitions (M&A) from the perspective of Google Cloud. These are the best practices that your Google Cloud Technical Account Managers follow — or that Google recommend you follow if you plan to perform the integration yourself.

Although there are various M&A scenarios, here are the two most common ones we will focus on:

Depending on your situation, your approach to integrating the two companies will vary substantially. 

When both companies have a Google Cloud presence

In the first scenario, let’s assume company A is acquiring company B. Prior to the M&A, both companies have their own Google Cloud Organizations — the top level structures in the Google Cloud resource hierarchy — and have one or more billing accounts associated with them. There are also various Folders and Projects below each Google Cloud Organization. In this scenario, here are the key questions to ask: 

  1. How do you plan to integrate/consolidate two distinct Google Cloud Organizations?
  2. How do you plan to organize the billing structure?
  3. How do you handle Projects under the two Organizations?
  4. What is the identity management strategy for the two Organizations?

For each of these key questions, go ahead and formulate a detailed plan of action. If you have access to the Technical Account Manager service through Google Cloud Premium Support, you can reach out to them to further develop this plan.

Understanding Google Cloud Organizations

From an organizational integration standpoint, when each entity in an M&A has its own Google Cloud Organization, you have various options: no integration, partial, or full.

No integration – When company B operates as an independent entity from company A, no migration is required. One cave at is if company A has negotiated better pricing terms/discounts and support packages with Google Cloud. In that case, you can sign an affiliate addendum by working with your Google Cloud account team to help unlock the same benefits for company B.

Partial integration – Some projects move over to company A from company B and others stay with Company B. There can be some shared access between the two companies and each of the organizations can continue to use their existing identity providers. This can be a self-serve or a paid services engagement with Google Cloud depending on the complexity of the two companies and how many project migrations need to take place between them.

Full integration – Company B is fully incorporated into company A. This means you go through a full billing, Google Workspace identity and project migration from company B into company A. This can be a complex process and Google highly recommend engaging your Google Cloud account teams to scope out a paid services engagement to go through this transition.

Planning your project migration

No matter what you want your end state to look like, project migration requires careful planning. Again, if you have an assigned Technical Account Manager, please reach out to them to ensure that you have a conversation around best practices before starting this migration.

If you’re taking a self-service approach, at a high level, Google recommend leveraging the Resource Manager API to manage your project migrations. Do keep in mind that there are several prerequisites and required permissions documented here that need to be assigned before going down this path.

In addition, please be sure to read the billing and identity management considerations below to ensure that you are covering all of the bases associated with such a migration, as your choices can fundamentally alter your Google Cloud footprint.

Billing considerations

When deciding how to structure your Organizations and billing accounts, Google’s recommendation is to always limit the number of Organization nodes and use the Folder structure to manage departments/teams within it. Creating additional Organization nodes is only advised in cases where you require a level of isolation for certain Projects from central administration for a specific business reason, for example, if the company being acquired already has their own Organization node and there is a business justification to let it operate as a standalone entity.

Warning: If you have multiple Organization nodes, be aware that you will not have central visibility across all your organizational resources, and that policy management across different Organization nodes can be cumbersome. You will also have to manage multiple Workspace accounts and manage identities across them, which can be difficult, especially when operating at scale. 

From a billing account management perspective, our recommendation is to create one central billing account that lives within the Organization node with tags and labels incorporated for additional granularity. However, there are a few business cases which warrant the creation of additional billing accounts such as:

Keep in mind that committed-use and spend-based discounts and promotional credits cannot be shared across billing accounts and are provisioned on a per-billing-account basis. As such, more billing accounts can make it harder to leverage these discounts and credits.

Identity management

As you might expect, merging two entities has identity management implications. Cloud Identity is the solution leveraged by Google Cloud to help you manage your user and group identities. Even if the acquired company only uses the productivity products that are part of Google Workspace, the identities would still be managed by Cloud Identity.

Google Workspace considerations

To move large amounts of content into a Google Workspace domain, Google recommend one of three options, depending on your end goal and data complexity:

When only one company is on Google Cloud

Now, let’s consider the scenario where only company A has a presence on Google Cloud but company B does not. The approach you take to integrate the two organizations largely depends on your desired end state — full, partial or no integration. 

If the plan is to eventually integrate company B into company A, your approach here will have a lot of similarities with the ‘full integration’ option mentioned above — just at a later point in time.

You may also run into a scenario where company B has a presence on an alternative cloud platform and you need to migrate resources into or out of Google Cloud. Again, similar to the partial integration option called out above, a paid engagement or a self-service exercise would be a good fit depending on the complexity of the desired end state. 

Here to help

A merger or acquisition is an exciting milestone for any company, but one that needs to be managed carefully. Once you carefully review these considerations, develop a plan of action for your organization. You can also engage Google’s Professional Services for a paid engagement or Google’s Technical Account Management Service for a self-managed process to achieve the desired results. 

If you are going through or considering going through M&A at your organization and have a different scenario than what we have discussed, please feel free to reach out to your account teams for guidance or contact Google at https://cloud.google.com/contact.

Related posts

Break down data silos with the new cross-cloud transfer feature of BigQuery Omni

by Kartika Triyanti
2 years ago

Migrate databases to Google Cloud VMware Engine (GCVE)

by Kartika Triyanti
2 years ago

Building a scalable MLOps system with Vertex AI AutoML and Pipeline

by Kartika Triyanti
2 years ago