如要開始規劃，請建立應用程式目錄。根據應用程式架構、業務考量因素和 IT 作業，將應用程式分類。這有助於根據業務重要性、複雜度和遷移至雲端的風險，決定應用程式的遷移優先順序。這些因素的組合和優先順序會因機構、業務需求，以及將這些需求對應至工作負載而異，包括目前的架構和未來的Google Cloud 架構。
[[["容易理解","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,["# Plan your migration waves\n\nThis document describes how to plan your migration waves.\n\nYou can group migration candidates into migration waves. Grouping can be done at\na high-level (category-based) or detailed-level (applications, locations,\ncomponents), based on the information you collect during the discovery\nand assessment phase.\n\nCreate an application catalog\n-----------------------------\n\nTo start your planning, create an\n[application catalog](/architecture/migration-to-gcp-assessing-and-discovering-your-workloads#example_of_an_app_catalog).\nOrganize your applications into categories based on application\narchitecture, business considerations, and IT operations. This helps\nprioritize them according to business criticality, complexity and risks\ninvolved in moving to the cloud.\nThe combination and prioritization of these factors vary across\norganizations, their business imperatives, and the mapping of these imperatives\nto workloads, both in their current architecture, and the future\nGoogle Cloud architecture.\n\nThe following list presents the three main categories and the factors that\nyou need to consider within each category.\n\n- **Application architecture**\n\n - Technical constraints\n - Number of dependencies\n - Number of tiers\n - Stateful vs stateless\n - Performance requirements\n - Geographic dependencies\n- **Business considerations**\n\n - Compliance requirements\n - Business criticality\n - Business change capability\n - Number of users\n - Type of users (internal, external)\n - TCO\n- **IT operations**\n\n - Operating environment\n - Service level agreement\n - Availability\n - Backup\n\nMap and prioritize\n------------------\n\nFrom the application catalog, map out applications based on the complexity and\ntarget migration approach.\nYour migration approach should be based on the business\noutcomes you expect, the migration effort, and the associated risk factors, both\nduring and after migration.\n\nThen, rank migration candidates in order of priority, based on business value\nand the effort required to migrate. To prepare for your migration, identify\napps with features that make them likely to be moved first. You can pick just\none, or include many apps in your first wave.\nThe apps in the first wave let your teams test the deployment in the cloud\nenvironment, while focusing on the migration instead of on the\ncomplexity of the apps.\n\nStarting with a standalone app lowers your initial risk because later you can\napply your team's new knowledge to applications that are more complex and\nhave many dependencies.\n\nApps in the first wave typically are not business critical and have fewer\nsystem and network-to-network dependencies.\nThey also require less refactoring, usually have less data\ngravity, don't have specific compliance challenges, and can afford a cutover\nwindow. For more details, see how to\n[choose the apps to migrate first](/architecture/migration-to-gcp-assessing-and-discovering-your-workloads#choosing_the_apps_to_migrate_first).\n\nGroup applications in waves\n---------------------------\n\nGroup applications into multiple waves with timelines associated with each\nwave, along with the time to revise plans based on the feedback from each wave.\n\n- **Wave 1** : High business value, low effort to implement.\n - *These applications are ideal candidates for early migrations or\n proof-of-concepts.*\n- **Wave 2** : High business value, high effort to implement.\n - *These applications may be prioritized next.*\n- **Wave 3** : Low business value, low effort to implement.\n - *These applications may be prioritized next.*\n- **Wave 4** : Low business value, high effort to implement.\n - *These applications should be prioritized last.*\n\nAfter you have defined your migration waves, you can organize them in a project\nplan.\n\nFollow the best practices\n-------------------------\n\nTo improve your migration plan, follow the\n[best practices to validate a migration plan](/architecture/migration-to-google-cloud-best-practices).\nFollowing the concepts in that document does not give any guarantees\nfor success.\nHowever, the document highlights some points that\nare often overlooked when planning migrations, such as:\n\n1. Ensuring that you have a rollback strategy for each step of the migration plan.\n2. Planning for gradual rollout and deployments, as discussed earlier in this document.\n3. Alerting all the development and operations teams that are responsible for the workloads to migrate.\n4. Removing proof-of-concept resources and experiments from the target production environment.\n5. Defining criteria to safely retire the source environment.\n6. Ensuring that you conduct a migration risk assessment for each migration wave and execute mitigations for the risks identified.\n\nWhat's next\n-----------\n\n- Learn how to [execute a migration](/migration-center/docs/migration-execution)."]]
