Projects in Organizations versus Billing Accounts

Moving a Billing account from one org to another is different from moving a project. You may even want to CHANGE the existing billing account on a project (or org). That is independent of the actual resources within the project.

Migrating Projects in GCP

Moving an entire project as a unit is possible (minus the IAM pieces  - those are inherited from the parent org).

The project resource is the base-level organizing entity in a Google Cloud organization.

Projects are created under organizations, and can be placed under folders or the organization resource itself, forming the resource hierarchy.

You may need to migrate projects between organizations due to acquisitions, regulatory requirements, and separation between business units, among other things.

What about IAM for users on the old project?

IAM policies that are DIRECTLY attached to the project will move with it. This includes ORG policies. This is all true if you are moving from one Folder to another WITHIN the SAME ORG. Policies that are inherited from parent folders, do not move with the project (and will have to be re-created on the target project).

If you are moving BETWEEN orgs (Migrating from one org to another), NONE of the IAM policies will carry over.

Resource Manager API

To move a project, you need the Project Mover IAM role (roles/resourceManager.projectMover) on both the source folder and the destination folder. If the resource is not in a folder, you need this role on the organization node.

You can use the Resource Manager API to move projects across organizations or to another place in the resource hierarchy of its current organization. The Resource Manager API also lets you roll back the migration, moving the project back to its original place in the resource hierarchy.

Before moving your project, you should consider creating a migration plan to determine the readiness of both your organization and the projects you want to move. In this migration plan, take inventory of each of the services that your project is running, and any other services that may be impacted by the move, or by the resource hierarchy in the destination for your project.

Also Read VM Isolation in GCP

Basically, a VM gets its private IP from the subnet it belongs to.

When you pull in an external project (a project in another org), the project may have it's own VMs and Services (BigQuery for example).  The Project also has it's own VPC (either default or custom or both), that may be hosting that VM. That ENTIRE VPC is moved over into the new parent org (as part of the Project Migration).

This means your VM is intact within the same VPC that it was in prior to the move.

Now, let us say you need to change this. Let us say you need to edit WHICH VPC (or subnet) this VM belongs to.

  1. Click the VM instance name to open the details page.
  2. Click Stop .
  3. If a confirmation dialog appears, click Stop.
  4. After the VM stops, click Edit .
  5. Under Network interfaces, click the interface you want to move.
  6. In the Network field of the interface, select the new network for the interface.
  7. In the Subnetwork field of the interface, select the new subnet for the interface.
  8. In the Internal IP address field, specify Automatic if you want the system to allocate an IP address from the subnet range or Custom if you want to specify an unused one yourself.

If you would rather use CLI commands

gcloud compute instances delete NAME --keep-disks all -- delete existing CE instance 

gcloud compute instances create -- Create new instance

How do I move a PaaS Service (BigQuery for example) from one Org to another?

Basically, a PaaS Service DOES NOT belong to a VPC (unless there is a private endpoint for the service). Since it does not belong to a VPC, all it belongs to is a containing project. Moving the Project moves the service along with it.

Moving BigQuery Datasets

Datasets are location specific. If you can retain the location of the original datasets, there is no migration required - and the project migration will simply place the project (along with all its BigQuery resources) under the new Org / Folder.

If Regions need to change , a BigQuery Data Transfer Service can be used.

  • When you set up a transfer, if the destination dataset does not exist, you will need to create it in BigQuery before configuring the transfer.
  • The location of the transfer configuration is automatically set to the same location that you specified for the destination dataset.
  • The BigQuery Data Transfer Service processes and stages data in the same location as the destination BigQuery dataset.

Can I delete the Default VPC?

Delete the default FW Rules and the Default VPC (after ensuring that there are no resources within --> Asset Manager )

Identity Migration

Most likely, the identities within your source org will need to be recreated within the target org. Unless these came from a centralized source like an AAD directory or a google group, these identities would need to be manually added.

Pre Migration - Inventory overview

Use Cloud Asset Inventory to create an overview of resources in use, including Identity and Access Management policies. You can use this overview to help outline your migration plan.

You can also use Cloud Asset Inventory to transfer this data into BigQuery. This will allow you to query the data using SQL, which is easier to read compared to interpreting JSON-formatted data. For information about exporting this data, see Exporting to BigQuery.

When you migrate your project, it will no longer inherit the policies from its current place in the resource hierarchy, and will be subject to the effective policy evaluation at its destination. We recommend making sure that the effective policies at the project's destination match as much as possible the policies that the project had in its source location.

Any policy that is applied directly to the project will still be attached after the migration is complete. Applying policies directly to the project is a good way to verify that the correct policies are applied from the moment the move is complete.

Identity and Access Management policies and organization policies are inherited through the resource hierarchy, and can block a service from functioning if not set properly. Determine the effective policy at the project's destination in your resource hierarchy to ensure the policy aligns with your governance objectives.

You should verify if your project has a customer-managed encrypted key or other Cloud Key Management Service enabled on it. Cryptographic keys are owned by the project, and a user with owner access to that project will therefore be able to manage and perform cryptographic operations on keys in Cloud KMS in that project.

For more information, see Separation of duties.

You can enable preview features on organizations, folders, or projects. If you have enabled an alpha or beta feature on the project to be moved, this feature should continue to function after the migration. If the preview feature is private and not allowlisted for the destination organization, you will not be able to make any configuration changes after the move is complete.

If you discover that something is not working on any of the projects you have migrated, you can move them back to their original location. In order to do that, you need to have the necessary IAM permissions and set the required organization policies so that you can run the project migration in reverse.

For a list of permissions required, see Assign permissions. For the organization policies you need to configure to allow a project migration, see Configure organization policies.

Policy inheritance can cause unintended effects when you are migrating a project, both in the source and destination organizations. You can mitigate this risk by creating specific folders to hold only projects for export and import, and ensuring that the same policies are inherited by the folders in both organizations. You can also set permissions on these folders that will be inherited to the projects moved within them, helping to accelerate the project migration process.

When planning a migration, consider setting up a dedicated source folder first. To do this, create a folder for each organization to which you plan to export projects. Then, set an organization policy on these folders, each with the constraints/resourcemanager.allowedExportDestinations constraint set to the single organization to which you want to export projects.