優先順序和遷移策略

遷移規劃的一個關鍵要素是建立優先順序標準。本練習的重點在於瞭解移轉應用程式的順序。該策略是採取迭代和漸進的方法來發展優先級模型。

排定應用程式的

此評估階段著重於建立初始準則，以排定低風險和低複雜性工作負載的優先順序。這些工作負載是試驗應用程式的理想選擇。在初始移轉中使用低風險、低複雜性的工作負載可降低風險，並讓團隊有機會獲得經驗。這些準則將在進一步的評估階段進行演進，以便在建立遷移浪計劃時與業務驅動程式的優先順序保持一致。

初始準則應優先考慮具有少量相依性的應用程式、在雲端支援的基礎架構中執行，以及來自非生產環境的應用程式。一個例子是具有 0-3 依賴關係的應用程序準備在開發或測試環境中按原樣重新託管。這些準則適用於定義試驗應用程式，以及可能是第一次和第二個遷移浪潮，具體取決於雲端採用成熟度和可信度等級。

決定使用什麼初始標準

選取 2—10 個資料點，用於排定第一個工作負載的優先順序。這些資料點來自您的初始應用程式和基礎結構清查 (請參閱資料收集部分)。

接下來，為每個資料點的每個可能值定義分數或權重。例如，如果選取了環境屬性，且可能的值為生產、開發和測試，則會為每個值指派一個分數，而較大的數字代表較高的優先順序。雖然它是可選的，但我們建議您為每個資料點指定重要性或相關性的乘法係數。這個選擇性步驟提供了更高層級的差異字元來強調什麼是更重要的，這有助於在重複指派分數給值時保持一致的準則。

下表根據針對前幾個移轉波排定低風險、簡單應用程式優先順序的策略，顯示範例屬性選取及其值指派。

屬性 (資料點)	可能的值	得分 (0 至 9)	重要性或相關性乘法因子
環境	測試	60	高（1 倍）
	開發	40
	生產	20
業務重要性	低	60	高（1 倍）
	中	40
	高	20
監管或合規框架	無	60	高（1 倍）
	FedRAMP	10
作業系統支援	雲端就緒	60	中高位 (0.8 倍)
	雲端中不支援	10
運算執行個體數	1-3	60	中高位 (0.8 倍)
	4-10	40
	11 人或以上	20
遷移策略	重新主持	70	中等 (0.6 倍)
	平台重建	30
	重構，或重新建築	10

請確定您選取的屬性可做為應用程式之間的關鍵區分。否則，準則將導致許多工作負載共享相同的優先順序。套用模型後，我們建議您查看結果排名的頂部和底部，以查看您是否同意。如果您通常不同意，則可以重新審視用於評分工作負載的準則。

獲得排名後，請查看整個投資組合中的分數分佈。分數本身並不重要。重要的是分數之間的差異。例如，您可能會發現最高的總分為 8,000，最低得分為 800。考慮將產生的分數繪製為長條圖，以便您可以驗證您的分佈是否良好。理想的分配看起來像是標準的鐘形曲線，具有一些非常高優先順序的工作負載和一些非常低優先順序的工作負載。大多數應用程序將在中間的某個地方。

初始優先順序的另一個關鍵方面是包括對成為雲端早期採用者感興趣的內部團隊或業務單位。在獲得業務支持以遷移給定應用程序時，這些可能是一個相當大的槓桿，尤其是在早期。如果您的組織是這種情況，請在上表中包含業務單位屬性。指派高分給那些願意提出應用程式的業務單位。使用業務單位屬性將有助於將這些應用程式置於清單頂端。

在您與結果排名同意後，選擇頂部 5-10 應用程序。這些將是您的初始應用程式移轉候選項。精簡清單，以便確認 3-5 個應用程式。這可協助您在執行詳細的應用程式評估時採取有針對性的方法。如需詳細資訊，請參閱應用程式優先順序評估。

確定用於遷移的 R 類型

決定每個應用程式和相關基礎架構的移轉策略，將會影響移轉速度、成本和權益等級。基於平衡的因素組合（包括業務驅動因素、技術指導原則、優先順序標準和業務策略）來確定策略是關鍵。

有時這些因素會產生衝突的視圖。例如，移轉的主要驅動因素可能是創新和敏捷性。同時，您可能需要快速降低成本。從長遠來看，將範圍內的所有應用程式現代化都可以降低成本，但預先需要更大的投資。在這種情況下，一種方法是使用需要較少努力的策略來遷移應用程序，例如重新裝載或重新平台。這可以在短期內提供快速的效率和成本降低。然後，將節省的成本重新投資到稍後階段將應用程式現代化，並進一步降低成本。

然而，從所有應用程式的完整重新裝載開始，延遲了現代化的更大優勢。關鍵在於在遷移策略之間取得平衡，以便將業務策略應用程式排定優先順序以進行現代化，而其他應用程式則可以先重新裝載或重新整理，然後再進行現代化。

如何決定應用程式的移轉策略？

在此評估階段，重點是整合初始模型，以引導選擇移轉策略。若要驗證初始應用程式的移轉策略，請將模型與業務驅動程式和優先順序準則搭配使用。決策樹的默認邏輯將幫助您確定範圍的初始處理。在樹狀結構中，最複雜的方法 (例如重構或重新架構) 會保留給您的策略性工作負載使用。

此圖表的可自訂 draw.io 版本可在「附件」區段中找到。

初始模型的第一個步驟是更新樹狀結構頂端的業務驅動程式與您的組織所定義的業務驅動程式。接下來，將樹狀結構套用至應用程式元件，而非整體應用程式。例如，如果是具有三個元件 (前端、應用程式層和資料庫) 的三層式應用程式，則每個元件都應該獨立傳輸樹狀結構，並指派特定的策略和模式。這是因為在某些情況下，您可能需要重新裝載或重新平台給定的層並重構（重新架構）其他層。

獨立元件指派會引導您為相關基礎結構定義移轉策略。基礎結構策略可能與其支援的應用程式元件採用相同的策略，也可能不同。例如，將重新格式化為具有較新作業系統之新虛擬機器的應用程式元件，將遵循重新平台策略，而主控該伺服器的目前虛擬機器將淘汰。基礎架構的移轉策略是根據為應用程式元件選擇的策略來計算。

在使用決策樹建立移轉策略之前，請先使用一些應用程式測試邏輯，並查看您是否通常同意結果。6 Rs 決策樹是一種指南，不會取代確定其正確性所需的分析。樹狀結構邏輯可能不適用於特定情況。將這些情況視為例外狀況，並透過記錄覆寫的理由而不是變更樹狀結構邏輯來覆寫樹狀結構所驅動的決策。這樣可以防止多個決策樹版本，這可能會變得難以管理。一般指引是，樹狀結構應該對至少 70-80% 的工作負載有效。對於其餘的，會有例外。在這個評估階段，對樹木邏輯作出任何調整，都應集中在建立初始模型上。進一步的迭代和細化將在後續階段進行，例如產品組合分析和遷移規劃。

附件

attachment.zip