雲端採用架構中的雲端移轉Cloud migration in the Cloud Adoption Framework

任何企業級規模的雲端採用方案,都會包含不保證在建立新商業邏輯方面進行大量投資的工作負載。Any enterprise-scale cloud adoption plan, will include workloads that do not warrant significant investments in the creation of new business logic. 這些工作負載可以透過任意數目的方法移至雲端;原形移轉、原形最佳化或現代化。Those workloads could be moved to the cloud through any number of approaches: lift and shift; lift and optimize; or modernize. 這些方法各自都是一種移轉。Each of these approaches is considered a migration. 下列練習將協助建立反覆流程,來評估、移轉、最佳化、保護及管理這些工作負載。The following exercises will help establish the iterative processes to assess, migrate, optimize, secure, and manage those workloads.

為了對此階段的雲端採用生命週期做好準備,建議您執行下列作業:To prepare you for this phase of the cloud adoption lifecycle, we recommend the following:

     


遷移您的第一個工作負載:使用 Azure 移轉指南,熟悉 Azure 原生工具和移轉方法。Migrate your first workload: Use the Azure migration guide to become familiar with the Azure native tools and approach to migration.


移轉案例:使用額外的移轉工具和方法來處理其他的移轉案例。Migration scenarios: Use additional migration tools and approaches to act on other migration scenarios.


最佳做法:透過應用程式一致的最佳作法,解決一般的移轉需求。Best practices: Address common migration needs through the application of consistent best practices.


流程改善:移轉是大量使用流程的活動。Process improvements: Migration is a process heavy activity. 當移轉工作擴展時,請使用這些流程改善,來評估和完善移轉的各個層面。As migration efforts scale, use these process improvements to evaluate and mature various aspects of migration.

遷移方法和上述步驟會根據下列假設而建置:The Migrate methodology and the steps above build on the following assumptions:

  • 控管移轉短期衝刺的方法會納入移轉波浪或發行中,這可以使用方案、就緒和採用方法來定義。The methodology governing migration sprints fits within migration waves or releases, which are defined using the Plan, Ready, and Adopt methodologies. 在每個移轉短期衝刺內,會將一批工作負載移轉至雲端。Within each migration sprint, a batch of workloads is migrated to the cloud.
  • 在移轉工作負載之前,至少已識別、設定及部署一個登陸區域,以符合近期雲端採用方案的需求。Before migrating workloads, at least one landing zone has been identified, configured, and deployed to meet the needs of the near-term cloud adoption plan.
  • 移轉通常會與「隨即轉移」或「重新裝載」的條款相關聯。Migration is commonly associated with the terms lift and shift or rehost. 這種方法和上述步驟,是根據不應使用純粹的重新裝載方法來移轉資料中心 (和少數的工作負載) 所建立。This methodology and the above steps are built on the belief that no datacenter and few workloads should be migrated using a pure rehost approach. 雖然許多工作負載都可以重新裝載,但客戶更常選擇將每個工作負載內的特定資產現代化。While many workloads can be rehosted, customers more often choose to modernize specific assets within each workload. 在此反復執行流程中,速度和現代化之間的平衡為常見的討論點。During this iterative process, the balance between speed and modernization is a common discussion point.

移轉工作Migration effort

遷移工作負載所需的動作通常分成三種類型的工作 (或階段):評估工作負載、部署工作負載和發行版本工作負載。The actions required to migrate workloads generally falls into three efforts (or phases) for each workload: assess workloads, deploy workloads, and release workloads. 這一節的「雲端採用架構」內容會教導讀者如何讓將工作負載移轉至生產環境所需的每個階段發揮最大效用。This section of the Cloud Adoption Framework teaches readers how to maximize the return from each phase required to migrate a workload to production.

在兩個星期的標準反覆項目中,經驗豐富的移轉小組可對 2-5 中/低複雜度的工作負載完成此程序。In a standard two-week long iteration, an experienced migration team can complete this process for 2-5 workloads of low-medium complexity. 更複雜的工作負載 (例如 SAP) 可能需要數個兩周的反覆項目,才能對單一工作負載全數完成三個移轉工作階段。More complex workloads, such as SAP, may take several two-week iterations to complete all three phases of migration effort for a single workload. 體驗和複雜度對時間軸和移轉速度會有很大的影響。Experience and complexity both have a significant impact on timelines and migration velocity.

雲端採用架構移轉工作

下列項目符號將概述此程序的各個階段 (如上圖所示):The following bullets provide an overview of the phases of this process (pictured above):

  • 評估工作負載: 評估工作負載以評估成本、現代化和部署工具。Assess workloads: Assess workloads to evaluate cost, modernization, and deployment tooling. 此程序主要會更深入檢視合理化選項,以驗證或挑戰在先前的探索和評估期間所做的假設。This process focuses on validating or challenging the assumptions made during earlier discovery and assessments by looking more closely at rationalization options. 此時也會仔細研究使用者模式和相依性,以確保工作負載在移轉後能夠達到技術成功。This is also when user patterns and dependencies are studied more closely to ensure workloads will achieve technical success after migration.
  • 部署工作負載: 評估工作負載之後,這些工作負載的現有功能會在雲端中進行複寫 (或改良)。Deploy workloads: After workloads are assessed, the existing functionality of those workloads is replicated (or improved) in the cloud. 此時可能需進行 隨即轉移,或 重新裝載 到雲端。This could involve a lift and shift or rehost to the cloud. 但此階段中更常見的情況是,許多支援這些工作負載的資產會現代化,以利用雲端的優勢。But more commonly during this phase, many of the assets supporting these workloads will be modernized to capitalize on the benefits of the cloud.
  • 發行工作負載: 功能複寫到雲端後,即可測試、最佳化、記載和發行工作負載,以用於進行中的作業。Release workloads: Once functionality is replicated to the cloud, workloads can be tested, optimized, documented, and released for ongoing operations. 此程序中的重要關鍵是,必須檢閱已移轉的工作負載,並將其遞交給控管、作業管理和安全性小組,以持續支援這些工作負載。Critical during this process, is the effort to review the migrated workloads and hand them off to governance, operations management, and security teams for ongoing support of those workloads.

注意

在移轉工作的一些早期反覆項目中,將範圍限制為單一工作負載是很常見的。In some early iterations of migration effort, it is common to limit scope to a single workload. 這種方法可盡可能保留技能,並且讓小組有更多時間進行實驗和學習。This approach maximizes skills retention and provides the team with more time to experiment and learn.

注意

建置移轉處理站時,有些小組可能會選擇將上述各個階段分散到多個小組和多個短期衝刺。When building a migration factory, some teams may choose to disperse each of the above phases across multiple teams and multiple sprints. 這種方法可以改善可重複性,並加速移轉工作。This approach can improve repeatability and accelerate migration efforts.

遷移波和反覆變更管理Migration waves and iterative change management

移轉反覆項目可藉由移轉資產和工作負載來提供技術價值。Migration iterations deliver technical value by migrating assets and workloads. 移轉波浪是最小的工作負載集合,可提供有形且可觀的商業價值。A migration wave is the smallest collection of workloads that deliver tangible and measurable business value. 每個反覆項目結束後均應產生報表,以概述完成的技術成果。Each iteration should result in a report outlining the technical efforts completed. 不過,商務變更和策略性規劃通常會在較高一點的層級發生。However, business change and strategic planning typically happen at a slightly higher level. 當雲端採用小組進行移轉工作時,雲端策略小組會著重於規劃後續的 1-2 個移轉波浪。As the cloud adoption team delivers on the migration effort, the cloud strategy team focuses on planning the next 1-2 migration waves. 雲端策略小組也會以學習計量的形式追蹤技術進展,以進一步了解實現商業價值的時程表。The cloud strategy team also tracks technical progress as a learning metric to better understand the timelines for realizing business value. 就這一點而言,移轉波可說是追蹤商務結果、人員和時程表的反覆變更管理方法。In that regard, migration waves are the iterative change management approach to tracking business outcomes, people, and timelines.

如上一節的圖形中所說明,雲端採用架構的方案方法就緒方法,以及策略方法 (就某種程度而言) 中的程序,均提供規劃和管理移轉波浪的指引。As outlined in the graphic in the prior section, processes within the Plan methodology, the Ready methodology, and to some extent the Strategy methodology of the Cloud Adoption Framework provide guidance on planning and managing the migration waves. 這些波浪的管理將對技術小組所要提供的移轉工作排定優先順序,並加以定義。The management of those waves will prioritize and define the migration effort to be delivered by the technical teams.

後續步驟Next steps

上述步驟和後續位於「遷移」方法中的指引,將有助於開發技能以利每個移轉短期衝刺內的流程。The steps outlined above, and subsequent guidance in the Migrate methodology, can help you develop skills to improve processes within each migration sprint. Azure 移轉指南是一系列簡短的文章,會概述第一次移轉波浪期間所需的常見工具和方法。The Azure migration guide is a brief series of articles that outlines the most common tools and approaches needed during your first migration wave.