This checklist will help you to move projects between organizations. The
checklist below contains a list of the major tasks involved in moving a
project between organizations, brief instructions for each step, and a link
to more information.
Click on a checklist item to see more information and click the box when you complete a task.
You should consider how your migration will impact the services running inside
the project. Changes in the resource hierarchy caused by a project move can lead
to changes in inherited policies, such as organization policies and
Identity and Access Management policies.
Create a plan to make sure that any potential impacts are mitigated during your
project move. To help inform your plan, use the
Move Analysis API to get a detailed breakdown of blockers for
the project move.
Because of the nature of moving a project from one organization to another,
there are a lot of potential interactions between the services in use at the
project and organization level. As part of your migration plan, you should
consider these cases if you depend on the services involved for the operation
of your project.
To perform a project move from one organization to another, you must set
the constraints/resourcemanager.allowedExportDestinations constraint, which
defines the organizations to which the project can be moved.
On the destination side, you must set the
constraints/resourcemanager.allowedImportSources constraint that defines the
organizations from which projects can be imported.
If either of these constraints are not properly set, the migration will fail
with a FAILED_PRECONDITION error.
Once you have finished the above steps, you can use the Resource Manager API to
move a project resource. You can use the gcloud beta projects movegcloud command-line tool command, or the projects.update() REST API method to
perform the move.