本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

範圍、策略和時間軸

三個關鍵元素構成了所有程式的建置區塊及其在大型遷移中的相關性：範圍、策略和時間軸。

若要設定遷移旅程的階段，這些元素必須從遷移程式開始就對齊和理解。其中一個元素的任何變更都會影響其他元素。重新對齊必須納入每個變更的考量，無論變更看起來有多基本或合理。

範圍 – 您要遷移什麼？

即使您完成遷移的一半，程式的總範圍也很常見。這是因為在後期階段之前，可能不會解壓縮各種因素。例如，在遷移的中途，您可能會發現未記錄在組態管理資料庫 (CMDB) 中的影子 IT。或者，規劃可能已專注於伺服器檢視，而不考慮執行這些應用程式所需的支援網路和安全服務 （例如 VPN 連線至 AWS 合作夥伴，以及憑證授權單位簽署憑證）。我們建議您花一些時間定義範圍，從您的目標業務成果向後工作。您最終可能會使用探索工具來探索資產，這是本指南稍後將討論的最佳實務。

範圍將會變更，因為大型遷移會伴隨未知。這些未知情況的形式可能是已成為環境架構一部分的系統，幾乎無法理解其相關性，或導致您制定的計劃延遲和轉移的生產事件。關鍵是保持彈性，並制定緊急應變計畫，讓計畫持續向前。

策略 – 為什麼要遷移？

基於下列 AWS 一或多個原因，您可能打算遷移至 ：

無論原因為何，所有這些原因等等都會考慮您的業務和 IT 組織。了解您的驅動因素是什麼、進行溝通以及排定優先順序至關重要。每個額外的驅動程式可能會為您的大型遷移增加時間、成本、範圍和風險。完全了解策略對時間軸和範圍的影響是關鍵。

定義遷移策略之後，成功的主要關鍵之一就是讓各個利益相關者和團隊的需求保持一致。執行遷移需要整個組織的不同團隊，包括基礎設施、安全、應用程式和營運。這些團隊會有個別的優先順序，以及其他可能已經開始的專案。如果這些團隊正在努力實現不同的時間表和優先順序，就更具挑戰性地同意和實作遷移計畫。遷移團隊和關鍵利益相關者必須確保所有參與的團隊都朝單一目標努力，並將其優先順序與遷移的單一時間表保持一致。

我們建議探索如何在各個團隊之間保持一致所需的業務成果。例如，遷移至 AWS 並使用 AWS Key Management Service (AWS KMS) 加密靜態儲存體，可能同時滿足遷移和安全性目標。

通常，企業想要將應用程式現代化，這可能會導致基礎設施升級，而基礎設施團隊想要採取非法方式並將基礎設施變更降至最低。大型遷移的思維應盡可能基本。涉及的團隊必須避免嘗試一次完成所有工作。

若要達成此目的，請在專案的早期設定正確的期望。關鍵訊息應該是「先遷移，然後再現代化」。這種方法不僅讓組織能夠減少技術負債，並最終大規模運作，還能使用 AWS 雲端 提供的可擴展性和敏捷性，為不同的現代化方法開闢道路。長期思考將有助於基礎設施團隊簡化基礎設施部署和管理。因此，業務可以有更快的功能發行週期。

時間軸 – 何時需要完成遷移？

根據您的業務案例，您必須確保在分配的時間內不會接受超過可能達到的 。如果您的遷移驅動程式是以固定的完成日期為基礎，您必須選擇符合該時間軸需求的策略。大多數大型遷移都以這些以時間為基礎的限制為基礎，因此遷移策略必須具有已定義的固定時間表和結果，很少有空間進行延伸或超支。

在這些時間敏感類型的遷移中，我們建議先遷移，然後現代化。這有助於設定期望，並鼓勵團隊確保其個別專案計劃和預算符合整體遷移目標。請務必儘早在專案中找出任何分歧、快速失敗並解決指導委員會層級的分歧，以及與適當的利益相關者互動，以確保保持一致。

相反地，如果您遷移的主要目標是獲得應用程式現代化的優勢，則必須在程式的早期進行呼叫。許多計劃從固定截止日期的初始目標開始，而且他們不打算滿足希望解決未完成問題和問題的利益相關者的要求。在某些情況下，這些問題已在來源系統中存在多年，但現在會成為遷移的人工封鎖程式。

遷移期間的現代化活動可能會影響商業應用程式的功能。即使被認為是小型升級，例如作業系統版本變更，也可能對程式時間表產生重大影響。這些不應被視為微不足道。