Google Cloud projects do not have to stay in the organization they were created under. A project can be moved to a different organization, to a different folder within the same organization, or from no organization at all into an existing one. This operation comes up on the Associate Cloud Engineer exam in scenarios involving mergers, acquisitions, restructuring, and the common case of a team that started with a personal account and needs to bring their project under corporate governance.
When you migrate a project between organizations, the resources within the project stay intact. Virtual machines keep running. Databases remain accessible. APIs stay enabled. Billing history is preserved. What changes is the organizational context: the project now inherits the policies, folders, and IAM structure of the new parent organization.
This organizational policy inheritance is the most important consequence of a migration. If the destination organization has strict org policies, those constraints will immediately apply to the migrated project. A policy that prevents the creation of external IP addresses, for example, will apply to the project the moment it lands in the new organization even if the project has existing resources with external IPs. Those existing resources are not automatically removed, but new ones would be blocked.
Project migration is executed through the resourcemanager.projects.move API method. When you use the Cloud Console or gcloud to move a project, those tools call this API method under the hood. You do not need to interact with the API directly, but knowing that this is the underlying mechanism helps when the exam presents questions about what permissions are needed.
The gcloud command for moving a project to a different organization or folder:
gcloud projects move PROJECT_ID --organization=ORGANIZATION_ID
# or to move to a specific folder:
gcloud projects move PROJECT_ID --folder=FOLDER_IDTwo permission grants are required for a project migration, and they are on different resources. The account performing the migration needs resourcemanager.projects.update on the project being moved. It also needs resourcemanager.projects.move on the destination parent, whether that is an organization or a folder.
In practice, this means the migrating account needs at minimum a role like Project Mover on the project and a role like Folder Admin or Organization Admin at the destination. If these permissions are split across different people, the migration requires coordination between the project owner and the destination organization administrator.
The exam tests this by presenting migration scenarios and asking which roles or permissions are needed. The two-resource requirement is the key detail: one permission on the source project, one on the destination parent.
While the project's resources survive the move, some configurations need attention after migration. The billing account association does not automatically update. If the source organization was paying for the project through a corporate billing account, the project may need to be associated with the destination organization's billing account after the move. A project that becomes disconnected from a billing account will have its services suspended.
IAM policies on the project itself are preserved. Roles granted directly to the project before migration remain granted after migration. What changes is the inherited policies from the new organizational hierarchy. If the new organization grants additional roles at the organization level, those roles become available to users in the migrated project. If the new organization has more restrictive org policies, those constraints take effect immediately.
The Associate Cloud Engineer exam presents project migration in a few recurring scenario types. A startup is acquired and needs to move its GCP projects under the acquiring company's organization. A team has been working in a personal GCP account and needs to bring the project under a corporate Cloud Identity account. A division of a company is spun off and its projects need to move to a new organization.
For each scenario, the exam tests whether you know that the migration is possible without destroying resources, what permissions are needed, and what side effects to watch for, particularly around org policy inheritance and billing account reassignment.
For more on how the resource hierarchy and project management topics appear on the exam, my Associate Cloud Engineer course covers migration scenarios alongside the broader organizational policy and hierarchy content.
When a project is moved to a new organization, it does not land at the organization level by default unless you specify no folder. You can move a project directly into a folder within the destination organization, which means the project immediately inherits that folder's IAM policies and org policies. This is useful when the migrated project belongs to a specific team or department and the destination organization uses folders to separate team environments.
Planning the destination folder structure in advance is important because changing a project's position in the hierarchy after migration requires additional operations and additional permissions. Organizations that migrate projects as part of an acquisition or restructuring typically map out the target hierarchy before performing any migrations.
After a project is moved, a validation check helps confirm the migration succeeded and that the project is behaving as expected under the new hierarchy. The key things to verify: that the billing account is correctly associated, that org policies from the new parent are not blocking any existing resources, and that IAM policies at the project level were preserved. Running gcloud projects describe PROJECT_ID shows the project's current parent and confirms the move completed successfully.
In practice, teams often run a dry-run style review before the actual migration by temporarily applying the destination org's policies to a test project and observing what would be blocked. This approach surfaces conflicts before they affect the real project's resources.
