立即開始：加速移轉
企業和IT項目關係人的適當配合有助於克服移轉障礙，並加速移轉工作。 本文提供下列建議的步驟：
- 利害關係人一致
- 移轉規劃
- 部署著陸區
- 移轉前10個工作負載
本文也協助您實作適當的治理和管理程式。 使用本指南來簡化整體移轉工作所需的流程和材料。
如果您的移轉案例不典型，您可以使用 策略性移轉評定和整備工具 （SMART），取得組織移轉整備程度的個人化評估。 使用它來識別最符合您目前需求的指引。
開始
遷移工作負載所需的技術工作和程序相當簡單。 請務必有效率地完成移轉程式。 策略移轉整備程度對時間軸和整體移轉成功完成的影響更大。
若要加速採用，您必須採取步驟，在移轉期間支援雲端採用小組。 本指南概述這些反覆的工作，以協助客戶開始任何雲端移轉的正確路徑。 為了顯示支援步驟的重要性，移轉會列為本文中的步驟 10。 在實務上，雲端採用小組可能會與步驟 4 或 5 平行開始第一個試驗移轉。
步驟 1：讓項目關係人保持一致
若要避免常見的移轉封鎖程式，請建立清楚且簡潔的移轉商務策略。 項目關係人對動機和預期業務成果的一致性，可塑造雲端採用小組做出的決策。
- 動機：戰略一致性的第一個步驟是就推動移轉工作的動機達成一致。 從瞭解和分類企業和IT中各種項目關係人動機和共同主題開始。
- 業務成果：當動機一致時，就有可能達成所需的業務成果。 此資訊提供清楚的計量，可讓您用來測量整體轉換。
交付項目：
- 使用 策略和計劃範本 來記錄動機和所需的業務成果。
| 負責任小組 | 負責和支援小組 |
|---|---|
步驟 2：對齊合作夥伴支援
合作夥伴、Microsoft 服務或各種 Microsoft 計劃都能在整個移轉過程中支援您。
- 瞭解合作關係選項， 尋找適當的合作關係和支援層級。
交付專案：
- 在您與支援合作夥伴洽談之前，請先建立條款與條件或其他合約。
- 在 策略以及計畫樣本中識別已核准的合作夥伴。
| 責任團隊 | 負責和支援小組 |
|---|---|
步驟 3：收集數據和分析資產和工作負載
使用探索和評量來改善技術一致性，並建立執行策略的行動計劃。 在此步驟中，使用目前狀態環境的相關數據來驗證商務案例。 然後，執行量化分析和最高優先順序工作負載的深度定性評估。
- 清查現有的系統：使用程式設計數據驅動方法來瞭解目前的狀態。 探索並收集數據，以支援所有評估活動。
- 累加式合理化：簡化評估工作，專注於所有資產的質化分析，甚至可能支援商業案例。 然後，針對要移轉的前10個工作負載新增深度定性分析。
交付專案：
- 現有庫存的原始數據。
- 對現有庫存進行量化分析，以精簡業務理由。
- 前10個工作負載的質化分析。
- 記載於 策略和計劃範本中的商業理由。
| 負責團隊 | 負責和支援小組 |
|---|---|
步驟 4：建立商務案例
提出移轉的商業理據可能是項目關係人之間的反覆討論。 在建立商業方案的第一個階段中，評估來自潛在的雲端遷移的初步高階回報。 此步驟的目標是確保所有項目關係人都符合一個簡單的問題：根據可用的數據，雲端的整體採用是明智的商務決策嗎？
- 建置雲端移轉商務案例 是開發移轉商務案例的良好起點。 公式和工具的清晰性有助於商業理由。
交付專案：
- 使用 策略和計劃範本 來記錄業務理由。
| 負責團隊 | 負責和支援小組 |
|---|---|
步驟 5：建立移轉計劃
雲端採用計劃提供一種加速建立任務積壓清單的方法。 接著可以修改待辦專案，以反映探索結果、合理化、所需的技能和合作夥伴承包。
- 雲端採用方案：使用基本範本定義您的雲端採用方案。
- 工作負載對齊：在待辦項目中定義工作負載。
- 工作協調：對齊待辦項目中的資產和工作負載，以清楚界定優先工作負載的投入。
- 人員與時間對齊：建立反覆專案、速度（人員時間），以及移轉工作負載的發行。
交付專案：
- 部署待辦項目範本。
- 更新範本以反映要移轉的前10個工作負載。
- 更新人員和速度以估計發行時間。
- 時程表風險：
- 對 Azure DevOps 缺乏熟悉度可能會降低部署程式的速度。
- 每個工作負載的複雜性和可用數據也會影響時程。
| 負責小組 | 負責和支援小組 |
|---|---|
步驟 6：建置技能整備計劃
現有的員工可以在移轉工作中扮演實際操作角色，但可能需要額外的技能。 在此步驟中，尋找開發這些技能或使用合作夥伴新增至這些技能的方法。
交付項目：
- 將技能整備計劃新增至 策略和計劃樣本。
| 負責小組 | 負責和支援小組 |
|---|---|
步驟 7：部署和對齊登陸區域
所有移轉的資產都會部署到登陸區域。 登陸區域會從簡單開始，以支援較小的工作負載，然後調整以因應一段時間內更複雜的工作負載。
- 選擇登陸區域：根據採用模式尋找部署登陸區域的正確方法。 然後部署標準化的程式代碼基底。
- 擴展您的登陸區域：無論您的起點為何，評估已部署登陸區域的不足之處，並新增必要的元件以優化資源組織、安全性、治理、合規性和運營。
交付專案：
- 設置您的第一個部署區，供進行初始低風險移轉準備。
- 與雲端卓越中心或中央 IT 團隊共同開發重構計畫。
- 時程表風險：
- 前10個工作負載的治理、作業和安全性需求可能會降低此過程的速度。
- 重構第一個登陸區域和後續登陸區域需要較長的時間，但應該與移轉工作平行進行。
| 負責團隊 | 負責和支援小組 |
|---|---|
步驟 8：移轉前 10 個工作負載
移轉前10個工作負載所需的技術工作相當簡單。 這也是您在遷移更多資產時重複的反覆過程。 在此程式中，您會評估工作負載、部署工作負載，然後將工作負載發行至生產環境。
反覆移轉工作的 
雲端移轉工具可在一次傳遞或反覆專案中移轉數據中心內的所有虛擬機。 在每次迭代期間移轉較少數量的工作負載更為常見。 將移轉分成較小的增量需要更多規劃，但可降低技術風險和組織變更管理的影響。
透過每次反覆專案，雲端採用小組在移轉工作負載時會變得更好。 這些步驟可協助技術小組成熟其功能：
- 使用 Azure 移轉指南中所述的工具，以基礎設施即服務 (IaaS) 的純方法來移轉您的第一個工作負載，。
- 使用 移轉範例展開工具選項，以使用移轉和現代化。
- 使用 Azure 雲端移轉最佳做法中所述的更廣泛方法來開發您的技術策略，。
- 透過高效的遷移工廠方法來改善一致性、可靠性和效能，如 遷移流程改進所述。
交付專案：
持續改善採用小組移轉工作負載的能力。
| 負責任團隊 | 負責和支援小組 |
|---|---|
步驟 9：將生產工作負載交給雲端治理
治理 是任何移轉工作長期成功的一個關鍵因素。 遷移速度與業務影響都很重要。 但是沒有治理的速度可能很危險。 您的組織必須做出符合採用模式和治理與合規性需求的治理決策。
| 負責團隊 | 負責和支援小組 |
|---|---|
步驟 10：將生產工作負載交給雲端作業
作業管理是達到移轉成功的另一項需求。 將個別工作負載遷移至雲端，而不需要了解進行中的企業作業，是一個有風險的決定。 在移轉的同時，您應該開始規劃長期作業。
可交付成果：
- 部署管理基準。
- 完成作業管理活頁簿。
- 識別需要 Microsoft Azure Well-Architected 審查評估的任何工作負載。
- 時程表風險：
- 檢閱活頁簿：每位應用程式負責人需要約一小時。
- 完成 Microsoft Azure Well-Architected 檢閱評估：每個應用程式估計一小時。
| 負責小組 | 負責和支援小組 |
|---|---|
價值聲明
這些步驟可協助小組透過更好的變更管理和項目關係人一致性來加速其移轉工作。 這些步驟也會移除常見的封鎖程式，並更快速地實現商業價值。
後續步驟
雲端採用架構是一種生命周期解決方案，可協助您開始移轉旅程。 它也有助於讓支援移轉工作的小組成熟。 下列小組可以使用這些後續步驟繼續使其功能成熟。 這些平行進程不是線性的，不應該被視為封鎖程式。 相反地，每個都是並行的價值流，協助改善組織的整體雲端就緒程度。
| 團隊 | 下一個迭代 |
|---|---|
| 雲端採用小組 | 使用 移轉模型 瞭解如何移至提供有效率持續移轉功能的移轉處理站。 |
| 雲端策略小組 | 反覆改善 策略方法、計劃方法，以及採用計劃。 檢視這些概要，並繼續反覆調整您的商務和技術策略。 |
| 雲端平臺小組 | 重新檢視 就緒方法，以繼續提升支援移轉或其他採用行動的整體雲端平臺。 |
| 雲端治理小組 | 使用 治理方法，繼續改善治理程序和原則。 |
| 雲端作業小組 | 以 管理方法 為基礎，在 Azure 中提供更豐富的作業。 |
如果您的移轉案例不典型，您可以使用 策略性移轉評定和整備工具 （SMART），取得組織移轉整備程度的個人化評估。 您提供的解答可協助您識別哪些指引最符合您目前的需求。