When one becomes two: Resource hierarchy strategies for divested organization

Whether it’s to pursue a new business strategy or to seek increased focus and independence, companies divest parts of their assets and form separate business entities all the time. These divested entities can be completely independent of the parent organization or still maintain some level of association. But whatever form they take, the presence of cloud resources can make the divestiture process a bit complicated.

Last year, we wrote about how to go about integrating two companies after a merger or acquisition.   Likewise, from a technology perspective, divestitures need to be handled with extreme diligence to ensure a smooth separation and maintain business continuity. Read on to learn the best practices for managing divestitures from the standpoint of the Google Cloud resource hierarchy. 

From RemainCo to NewCo

Let us assume RemainCo is an entity with extensive presence on Google Cloud that would like  to create a spin-off organization called NewCo to go after a new market segment. NewCo will be completely independent in its operations, yet operate as a subsidiary of RemainCo. 

RemainCo has all its Google Cloud resources under one organization node that include multiple projects, folders and billing accounts. NewCo will also have a Google Cloud footprint, but  because it’s a new entity, will have no links to RemainCo.

To do this effectively, there are multiple areas within Google Cloud that you need to pay attention to when crafting a plan of action for the divestiture. Let's take a look at some of those key topics:

1. Identify the Google Cloud assets to be divested

Start by creating a list of assets that will be impacted by the divestiture by reviewing all the folders and projects under RemainCo’s Google Cloud Org Node. Be sure to review any potential business and application/workload dependencies carefully and isolate the assets into its own folder/project hierarchy for better control of all assets being divested. 

You also want to be mindful of internal project and resource dependencies like usage of VPC peering and Shared VPCs, Interconnects, Custom IAM roles, VPC service controls, etc., within RemainCo, as they will need special attention — and possibly a  redesign! — to ensure business continuity after the divestiture. We recommend enlisting the help of your Google Cloud account team and Google Cloud Consulting team to ease the process. 

2. Cloud Identity/Domain/Workspace considerations

Once you’ve taken an inventory of your assets, it’s time to create a new domain for NewCo and a Google Cloud Org Node mapped to that domain. Then, it’s time to think about managing identities and access to the divested resources. 

Review the IAM permissions on all the assets being divested under RemainCo to understand the usage patterns and identify all the key users and service accounts within RemainCo that may be impacted. 

If as part of the divestiture RemainCo is also transitioning users into NewCo, you’ll need to create new cloud identities for those users under NewCo’s new domain. If the users are not being transitioned, then NewCo will have to provision their own identities and IAM permissions to manage these new assets. Review the identity provider setup for both entities and craft a plan around managing/creating identities post divestiture.

Also review any Google Workspace licenses that may need to move and leverage either Google Workspace Migrate or the export tool. 

3. Creating updated/desired org structures for RemainCo and NewCo

Now it’s time to create updated org structures with the new org node for RemainCo and NewCo. Note that, in the previous step, you first moved all assets to be divested under a new folder in RemainCo. You can choose to carry over the same folder structure and place it under NewCo’s Org Node, or you can make the necessary modifications during the project migration process a little later. At this point, you just have the org node for NewCo with the required folders under the org node.

4. Billing considerations

To make sure each entity is billed appropriately, review the billing needs for the updated org structure. Because each project needs to be tied to a billing account to consume Google Cloud services, make sure that your billing structure meets the needs of both entities. You can choose to create a new billing account under NewCo and enable all the divested assets from RemainCo to be funded by this new billing account, or you can migrate one of the existing billing accounts under RemainCo to NewCo.

Ideally, you should aim to have one billing account under each organization node to reduce billing complexity and improve governance. You should consider creating additional billing accounts only if there is a specific business need, such as:

• You need to split charges for legal or accounting purposes
• Invoices are paid in multiple currencies
• You need to segregate usage to draw down on a Google Cloud promotional credit
• Subsidiaries need their own invoice

Another key item to consider is the impact of any resource-based or spend-based committed use discounts that RemainCo’s billing account may have benefited from. Since CUDs cannot be canceled, please review options to reduce the cost impact of fewer resources utilizing the CUD. To reduce adverse billing impacts, you can look at optimizing machine types in other projects to match the resource-based CUD type you may have. Read more about CUDs here. 

Any Google Cloud promotional credits that were allocated are typically at the level of the billing account and won’t automatically move to the new billing account. If you need to share these credits, please work with your account team to facilitate the transition. Please note that these may be governed by contractual clauses and will need to be signed off by legal teams before any changes can be made.

Also, any Google Cloud support packages that were associated with RemainCo won’t automatically extend to NewCo. NewCo will need to sign up for its own Google Cloud support package. Read more about the available support packages here. 

Once you have the final billing structure, we can map the projects accordingly and continue operations.

Note: Separating billing accounts and associated projects early in the process helps ensure a cleaner separation. Also, migrating a project to a new org will not automatically remap the project’s billing account. You can make any required changes following the instructions listed here. 

5. Google Cloud contract/commit considerations

In cases that RemainCo has a commit contract with Google Cloud that remains active, you need to review the impact of the divestiture on RemainCo’s ability to meet its contractual spend obligations. Ideally, the divested resources are left untouched and funded by the same billing account, and are using consumption to spend down the existing commit contract until the commitment term is complete. If this is not an option, and the divested assets are moved to a completely different entity, please note that there may be contractual clauses that govern these changes that need to be discussed with legal teams. Please work with your Google Cloud account team to discuss available options.

6. Marketplace services contract considerations

In cases where the assets being divested leveraged services via the Google Cloud Marketplace, identify the Marketplace dependencies within the Google Cloud implementation before updating these services or performing any project migrations. Failure to do this may cause business impact if not done in the correct sequence. 

Please note that Marketplace services are not typically tied to projects, but to billing accounts. If you move a project from one billing account to another, the Marketplace services won't be migrated. Your options here are:

• Work with your Marketplace vendor to stop the service on RemainCo’s billing account and start the same on NewCo’s billing account;
• Work with the vendor to move the contractual terms you may have had on RemainCo’s billing account to the new billing account under NewCo; 
• Sign a new Marketplace service contract for a billing account under NewCo and maintain existing contracts under RemainCo.

Do not migrate the projects until you have made sure all the Marketplace services required for business continuity are up and running on the new billing account. Also, be mindful when turning off Marketplace services on RemainCo’s billing account, as other non-divested projects may still be using this service. We recommend a comprehensive review of the usage of these services before making any changes.

Also note that there may be legal clauses involved with stopping/moving services — especially when under a contract with the marketplace vendor. Please work with the vendor and your Google Cloud account teams closely to review the best course of action.

7. Migration planning

After carefully reviewing the previously listed topics, it’s time to formulate a migration plan to migrate the assets/projects over to NewCo from RemainCo. You can use the resource manager API to perform the migrations yourself, or work with Google to scope out a paid engagement and migration plan. 

Here to help

A divestiture can be a lengthy and technically challenging process for any organization, and we recommend that you enlist expert help to plan and execute this process. You can engage Google Cloud Consulting for a paid engagement or Google’s Technical Account Management Service for a self-managed process to achieve the desired results. Feel free to reach out to your account teams for guidance or contact us at https://cloud.google.com/contact.