本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 優先順序和遷移策略
遷移規劃的關鍵元素是建立優先順序條件。本練習的重點是了解應用程式遷移的順序。策略是採取反覆且漸進的方法，以發展優先順序模型。
## 排定應用程式的優先順序
此評估階段著重於建立初始條件，以排定低風險和低複雜度工作負載的優先順序。這些工作負載是試行應用程式的良好候選項目。在初始遷移中使用低風險、低複雜度工作負載可降低風險，並讓團隊有機會獲得體驗。這些條件將在進一步的評估階段發展，以在建立遷移波動計畫時與業務驅動因素保持一致的優先順序。
初始條件應優先考慮具有少量相依性的應用程式、在雲端支援的基礎設施中執行，以及來自非生產環境的應用程式。例如，具有 0-3 個相依性的應用程式已準備好在開發或測試環境中重新託管。根據雲端採用成熟度和可信度層級，這些條件對於定義試行應用程式以及可能的第一和第二遷移波有效。
*決定要使用的初始條件*
選取要用於排定第一個工作負載優先順序的 2-10 個資料點。這些資料點來自您的初始應用程式和基礎設施庫存 （請參閱[資料收集](initiating-data-collection.md)一節）。
接著，為每個資料點的每個可能值定義分數或權重。例如，如果選取環境屬性，並且可能的值是生產、開發和測試，則每個值都會獲得一個分數，數字越大，表示優先順序越高。雖然這是選用的，但我們建議您為每個資料點的重要性或相關性指派乘數。這個選用步驟提供更高層級的差異性，以強調更重要的項目，這有助於在您反覆將分數指派給值時保持條件的一致性。
根據為前幾個遷移波排定低風險、簡單應用程式優先順序的策略，下表顯示範例屬性選擇及其值指派。
| **屬性 （資料點）** | **可能的值** | **分數 (0-99)** | **重要性或相關性乘數** |
| --- |--- |--- |--- |
| Environment | 測試 | 60 | 高 (1x) |
| 開發 | 40 |
| 生產 | 20 |
| 業務關鍵性 | 低 | 60 | 高 (1x) |
| 中 | 40 |
| 高 | 20 |
| 法規或合規架構 | 無 | 60 | 高 (1x) |
| FedRAMP | 10 |
| 作業系統支援 | 雲端就緒 | 60 | 中高 (0.8x) |
| 雲端不支援 | 10 |
| 運算執行個體的數量 | 1-3 | 60 | 中高 (0.8x) |
| 4-10 | 40 |
| 11 個或更多 | 20 |
| 遷移策略 | 重新託管 | 70 | 中型 (0.6x) |
| 平台重建 | 30 |
| 重構或重新架構 | 10 |
請確定您選取的屬性可以做為應用程式之間的關鍵差異。否則，這些條件將導致許多工作負載共用相同的優先順序。套用模型後，建議您查看結果排名的頂端和底部，以查看您是否同意。如果您通常不同意，您可以重新檢視用於對工作負載進行評分的條件。
在您取得排名後，請查看整個產品組合的分數分佈。分數本身並不重要。這是重要的分數之間的差異。例如，您可能會發現最高總分為 8，000，最低分數為 800。考慮將產生的分數繪製為長條圖，以便您可以驗證您是否具有良好的分佈。理想的分佈看起來像標準鐘形曲線，具有幾個非常高優先順序的工作負載和幾個非常低優先順序的工作負載。大多數應用程式將位於中間的某個位置。
初始優先順序的另一個關鍵方面是包含內部團隊或業務單位，這些團隊或業務單位對成為雲端的早期採用者表示興趣。這些可能是取得商業支援以遷移指定應用程式的重要手段，特別是在早期。如果您的組織發生這種情況，請在上表中包含業務單位屬性。為願意轉發其應用程式的業務單位提供高分。使用業務單位屬性有助於將這些應用程式排在清單頂端。
同意產生的排名後，請選取前 5-10 個應用程式。這些將是您初始的應用程式遷移候選項目。精簡清單，以確認 3-5 個應用程式。這可協助您在執行詳細的應用程式評估時採取有針對性的方法。如需詳細資訊，請參閱[優先應用程式評估](prioritized-applications-assessment.md)。
## 判斷遷移的 R 類型
決定每個應用程式和相關基礎設施的遷移策略，將會影響遷移速度、成本和效益層級。這是根據平衡的因素組合來確定策略的關鍵，包括業務驅動因素、技術指導原則、優先順序標準和業務策略。
有時，這些因素會產生衝突的觀點。例如，遷移的主要驅動因素可能是創新和敏捷性。同時，您可能需要快速降低成本。現代化範圍內的所有應用程式，將可降低長期執行的成本，但需要更大量的前期投資。在這種情況下，一種方法是使用較不費力的策略來遷移應用程式，例如重新託管或轉譯。這可以在短期內提供快速的效率和降低成本。然後，在稍後階段重新投資節省的成本來現代化應用程式，並進一步降低成本。
不過，從完全重新託管所有應用程式開始，會延遲現代化所帶來的更大優勢。關鍵是尋找遷移策略之間的平衡，以便商業策略應用程式優先進行現代化，而其他應用程式可以先重新託管或重新格式化，然後再進行現代化。
*如何判斷應用程式的遷移策略？*
在此評估階段，重點是納入引導遷移策略選擇的初始模型。若要驗證初始應用程式的遷移策略，請搭配業務驅動因素和優先順序條件使用模型。決策樹的預設邏輯將協助您判斷範圍的初始處理方式。在樹狀目錄中，最複雜的方法，例如重構或重新架構，會保留給您的策略工作負載。
此圖表的可自訂 [draw.io](https://github.com/jgraph/drawio-desktop/releases) 版本可在*[附件](#attachments)*區段中取得。
初始模型的第一步是將樹狀結構頂端的業務驅動程式更新為組織定義的業務驅動程式。接著，將樹狀結構套用至應用程式元件，而非整個應用程式。例如，如果三層應用程式有三個元件 （前端、應用程式層和資料庫），則每個元件都應獨立傳輸樹狀目錄，並獲指派特定的策略和模式。這是因為在某些情況下，您可能想要重新託管或轉換指定的層，並重構 （重新架構） 其他層。
獨立元件指派將引導您定義相關聯基礎設施的遷移策略。基礎設施策略可能與其支援的應用程式元件具有相同的策略，也可能不同。例如，將複寫到具有較新作業系統的新虛擬機器中的應用程式元件將遵循複寫策略，而託管它的目前虛擬機器將被淘汰。基礎設施的遷移策略是根據為應用程式元件選擇的策略來計算。
使用決策樹來建立遷移策略之前，請使用幾個應用程式測試邏輯，並查看您是否通常同意結果。6 Rs 決策樹是一份指南，不會取代判斷其正確性所需的分析。樹狀結構邏輯可能不適用於特定案例。將這些案例視為例外狀況，並透過記錄覆寫的原理來覆寫樹狀結構驅動的決策，而不是變更樹狀結構邏輯。這可防止多個決策樹版本，這可能會變得難以管理。一般指引是樹狀結構在工作負載中應至少 70-80% 有效。其餘部分則會有例外狀況。在此評估階段，對樹狀結構邏輯的任何調整都應專注於建立初始模型。進一步的反覆運算和精簡會在稍後階段進行，例如[產品組合分析和遷移規劃](portfolio-analysis-migration-planning.md)。
## 附件
[attachment.zip](samples/attachment.zip)