GCP Organization Migration: Understanding and Methodology for a Successful Migration

Need to migrate all GCP projects with associated workloads from an GCP organization to another GCP organization?

This article will give you concepts to understand and methodology to succeed your migration.

What is a GCP Organization migration?

Moving your workloads from a GCP organization ( IAM objets , projects , folder , policies , federation) to another primary domain.

In theory, GCP Organization migration don’t have to impact your business workloads and end users … But we have to check several things for migrating 😜

Good to know about GCP organization migration:

Moving folders between organization nodes is not supported. Only the migration of GCP projects between organization nodes is allowed.

IAM permissions will not be transferred with the project during migration. Only policies and service accounts directly associated with the resource are moved. This may result in unexpected behavior after the migration is completed.

Only Customer-managed encryption keys on the project are transferred

Only the owner keys on the GCP project are transferred

As you may notice, migration can have impacts on IAM (Identity and Access Management) and encryption keys. It’s important to conduct an impact study and prepare for the migration beforehand, before making the switch.

The GCP organization migration must follow several steps:

1. Discovery: Analyse blockers with assessment

2. Prepare: Create a GCP foundation to the target domain,

3. Prepare:Migrate IAM members,

4. Plan: Plan your workload migrations

5. Migrate: Perform the migration

GCP Migration Methodology

→ First step is to analyse assets and identify blockers from source GCP domain to the target domains. Apply corrections if needed.

→ Secondly , we prepare the target GCP domain with IAM members , folders , projects , org policies with a GCP foundation.

→ Finally, we execute IAM permission & org policies prerequisites before performing the migration.

1. Discovery: Analyse blockers with assessment

Select or create a project as your API consumer project, enable Cloud Asset API

gcloud services enable cloudasset.googleapis.com

and grant the following permissions to your user to perform the analysis:

gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/iam.securityReviewer
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/cloudasset.viewer
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/orgpolicy.policyViewer
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/compute.orgSecurityResourceAdmin
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/resourcemanager.tagViewer

Perform the analysis with Cloud Asset Inventory and Move Analysis API to identify a list of warnings and blockers applicable to this project migration.

gcloud asset analyze-move --project=PROJECT_ID \ (--destination-folder=FOLDER_ID \   | --destination-organization=ORGANIZATION_ID)

Cloud Asset Inventory and Move Analysis can be exported in BQ for further analysis.

Analyse all blockers and fix them.

2. Prepare: Create a GCP foundation to the target domain

Build a GCP foundation with the target domain, folders , organization policies and configure IAM federation with your corporate identity store.

Create IAM Group with custom roles, assign users to target groups

3. Prepare: Migrate IAM members

Migrate IAM members from the source domain to the target cloud identity domain. Migration can be executed in multiple steps.

Step 1: create a secondary domain to your target cloud identity and merge your users to one cloud identity.

Step2: configure IAM federation with the source corporate identity store.

Step 3: when all your users are migrated . Delete your secondary domain and the IAM federation with the source corporate identity store . This step can be executed several months after migrating your GCP workloads.

4. Plan: Plan your workload migrations

Set the following IAM permissions

gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/resourcemanager.projectIamAdmin
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/resourcemanager.projectMover
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/billing.user

and configure Organization policies to allow the constraints on the source and target organization:

Source organization: constraints/resourcemanager.allowedExportDestinations
Target organization: constraints/resourcemanager.allowedImportSources

If Needed , change billing account ID to change billing destination for projects

gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/billing.user
gcloud projects add-iam-policy-binding $GOOGLE_CLOUD_PROJECT --member user:myuser@mydomain.com --role=roles/billing.projectManager

5. Migrate: Perform the migration

gcloud beta projects move PROJECT_ID \ --organization ORGANIZATION_ID

I hope you enjoyed reading this. See you next time 👋