[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["# Create a migration plan\n\nFor a project migration, it is necessary to evaluate how the migration\nwill impact the services running inside the project. The\nResource Manager API treats the project resource and all services running underneath\nit as a single unit, meaning that no configuration changes will be applied\ninside the project.\n\nWhile the migration won't make direct configuration changes to the project,\nthe change in the resource hierarchy is likely to have an impact on the\nfunction of the project and its running services. Allow, deny, or organization\npolicies that are inherited rather than directly attached to the project won't\nmigrate with the project during migration. The organization policies and service\naccounts that are attached directly to the resource will be migrated. This may\ncause unintended behavior after the migration is complete.\n\nMigrating your project might also result in [organization policy\nviolations](/resource-manager/docs/organization-policy/overview#violations),\ndepending on the destination organization resource's organization policies.\n\nBefore migrating your project between organization resources, you should consider creating a migration plan to\ndetermine the readiness of both your organization resource and the projects you want to\nmigrate. In this migration plan, take inventory of each of the\nservices that your project is running, and any other services that may be\nimpacted by the migration, or by the resource hierarchy in the destination for your\nproject.\n\n### Inventory overview\n\nUse [Cloud Asset Inventory](/asset-inventory/docs/overview) to create an overview of\nresources in use, including allow policies. You can use this overview to help\noutline your migration plan.\n\nYou can also use Cloud Asset Inventory to transfer this data into\nBigQuery. This will allow you to query the data using SQL, which is\neasier to read compared to interpreting JSON-formatted data. For information\nabout exporting this data, see\n[Exporting to BigQuery](/asset-inventory/docs/exporting-to-bigquery).\n\nTo get a list of all allow and deny policies that affect access to a project,\nsee [View all allow and deny policies that apply to a resource](/iam/docs/troubleshoot-policies#applicable-policies).\n\n### Policy verification\n\nWhen you migrate your project, it will no longer inherit the policies from its\ncurrent place in the resource hierarchy, and will be subject to the effective\npolicy evaluation at its destination. We recommend making sure that the\neffective policies at the project's destination match as much as possible the\npolicies that the project had in its source location.\n\nAny policy that is applied directly to the project will still be attached after\nthe migration is complete. Applying policies directly to the project is a good\nway to verify that the correct policies are applied from the moment the migration is\ncomplete.\n\nAllow, deny, and organization policies are inherited through the resource\nhierarchy, and can block a service from functioning if not set properly.\nDetermine the effective policy at the project's destination in your resource\nhierarchy to ensure the policy aligns with your governance objectives.\n\n### Manage encrypted keys\n\nYou should verify if your project has a customer-managed encrypted key or other\nCloud Key Management Service enabled on it. Cryptographic keys are owned by the project, and a\nuser with `owner` access to that project will therefore be able to manage and\nperform cryptographic operations on keys in Cloud KMS in that\nproject.\n\nFor more information, see\n[Separation of duties](/kms/docs/separation-of-duties).\n\n### Preview features\n\nYou can enable preview features on organization resources, folders, or projects.\nIf you have enabled an alpha or beta feature on the project to be migrated, this\nfeature should continue to function after the migration. If the preview feature\nis private and not allowlisted for the destination organization resource, you\nwill not be able to make any configuration changes after the migration is complete.\n\n### Rollback plan\n\nIf you discover that something is not working on any of the projects you have\nmigrated, you can restore them to their original location. In order to do\nthat, you need to have the necessary IAM permissions and set the\nrequired organization policies so that you can run the project migration\nin reverse.\n\nFor a list of permissions required, see\n[Assign permissions](/resource-manager/docs/assign-iam-roles). For the organization policies you\nneed to configure to allow a project migration, see\n[Configure organization policies](/resource-manager/docs/configure-org-policy).\n\n### Dedicated import and export folders\n\nPolicy inheritance can cause unintended effects when you are migrating a\nproject, both in the source and destination organization resources. You can\nmitigate this risk by creating specific folders to hold only projects for export\nand import, and ensuring that the same policies are inherited by the folders in\nboth organization resources. You can also set permissions on these folders that\nwill be inherited to the projects moved within them, helping to accelerate the\nproject migration process.\n\nWhen planning a migration, consider setting up a dedicated source folder first.\nTo do this, create a folder for each destination organization resource to which you plan to\nexport projects. Then, set an organization policy on these folders, each with\nthe `constraints/resourcemanager.allowedExportDestinations` constraint set to\nthe single organization resource to which you want to export projects.\n| **Note:** To configure organization policies required for the project migration, you must have the `roles/orgPolicy.policyAdmin` role on the parent and the destination organization.\n\nFor example, you could set up `Export to Marketing Org` and\n`Export to Sales Org` folders, each with appropriate organization policy\nconstraints set.\n\nSimilarly, set up dedicated import folders in the destination organization\nresource, one for each organization resource from which you want to import\nprojects. To do this, create a folder for each source organization resource from which\nyou plan to import projects. Then, set an organization policy on these folders,\neach with the `constraints/resourcemanager.allowedImportSources` constraint set\nto the single organization resource from which you want to import projects.\n\nFor example, you could set up `Import from Marketing Org` and\n`Import from App Development Org` folders, each with appropriate organization\npolicy constraints set.\n\nOn each of the import and export folders, assign the person who will be moving\nthe projects the `roles/resourcemanager.projectMover` role. This role will be\ninherited by any projects that are contained within these folders, giving the\nuser the ability to perform the move operations on any project that is moved\ninto those folders.\n\nAfter you have completed your project migration, you should remove these\ndedicated folders.\n\nFor information about setting organization policies, see [Configure\norganization policies](/resource-manager/docs/configure-org-policy).\n\nWhat's next\n-----------\n\nTo assign Identity and Access Management roles and permissions for migrating projects between organizations, see [Assign Identity and Access Management roles and permissions](/resource-manager/docs/assign-iam-roles)."]]
