

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

# 通往雲端的路徑
<a name="cloud-paths"></a>

本節說明實作最佳實務以遷移 Windows 應用程式至 的高階方法 AWS。這些遷移策略和步驟的詳細資訊會在本指南的後續章節中說明。

## 遷移策略
<a name="migration-strategies"></a>

遷移策略是用來將工作負載遷移至 的方法 AWS 雲端。將應用程式移至雲端有七種遷移策略。這些策略稱為 7 個 R，並以 2019 年 Gartner 所識別的 [7 個 R](https://www.gartner.com/smarterwithgartner/7-options-to-modernize-legacy-systems) 為基礎。
+ **Rehost （提升和轉移）** – 將應用程式移至雲端，而不進行任何變更以利用雲端功能。
+ **重新定位 (Hypervisor 層級提升和轉移）** – 將基礎設施移至雲端，而無需購買新硬體、重寫應用程式或修改現有的操作。
+ **Replatform （提升和重塑）** – 將應用程式移至雲端，並引入某種程度的最佳化，以利用雲端功能。
+ **回購 （捨棄和購買）** – 切換到不同的產品，通常是從傳統授權轉移到軟體即服務 (SaaS) 模型。
+ **重構/重新架構師** – 透過充分利用雲端原生功能來改善敏捷性、效能和可擴展性，以移動應用程式並修改其架構。
+ **保留 （重新瀏覽）** – 將應用程式保留在您的來源環境中。這些可能包括需要重大重構的應用程式，而且您想要將該工作延遲到稍後的時間，以及您想要保留的舊版應用程式，因為沒有遷移它們的商業理由。
+ **淘汰 **– 停用或移除來源環境中不再需要的應用程式。

## 主要轉換
<a name="main-transformations"></a>

當您將舊版 Windows 應用程式和資料庫現代化時，會發生下列主要轉換：
+ **Rehost** – 第一步是將內部部署基礎設施移至雲端基礎設施。此策略通常稱為「提升和轉移」或重新託管。重新託管意味著將現有的應用程式和資料庫遷移到雲端伺服器執行個體。您不需要變更程式碼，而且您必須負責管理執行個體組態、軟體映像和其他資源。
+ **Replatform** – 遷移至雲端環境後，下一個轉型是將應用程式和資料庫轉換為更自動化且受管的環境。從應用程式角度來看，這表示從虛擬機器 VMs) 移至容器或受管應用程式平台。容器化應用程式可協助您更快速地開發、維護和部署應用程式，並改善可攜性。或者， [AWS Elastic Beanstalk ](https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/Welcome.html)提供的受管平台會自動處理容量佈建、負載平衡和擴展。這可協助您以最少的基礎設施管理來重建應用程式，而不需要將其完全容器化。在資料庫端，從自助式模型移至受管資料庫服務，例如 Amazon RDS for SQL Server，不需要佈建、修補和備份。這會釋放資源，用於可為您的組織增加更多價值的活動。
+ **重構/重新架構師** – 轉換的第三個領域是從商業軟體授權轉移到開放原始碼選項。許多傳統的商業軟體廠商都以鎖定客戶和使用懲罰性授權條款來強制升級和遷移為目標的軟體授權協議為基礎建立業務。除了對等的開放原始碼選項之外，商業軟體授權費用通常會增加 20–50% 的成本。我們建議您重構應用程式和資料庫，以利用開放原始碼選項，讓您可以降低成本、改善效能，以及存取最新的創新。

您可以根據您的應用程式和整體現代化準備程度，分階段或一次完成這些主要轉型領域。

## 選擇移轉策略
<a name="choosing-migration-strategy"></a>

要選擇的遷移策略取決於組織的業務和 IT 目標。一些最常見的業務驅動因素是降低成本、降低風險、提高效率、解決技能差距，以及加速創新。我們建議您評估哪些驅動程式對您很重要，然後使用下列指引，根據您的驅動程式選擇遷移策略。此外，請記住，這三種方法都是雲端現代化旅程中可能的道路，取決於您在旅程每個階段的優先順序。

### 何時重新託管
<a name="choosing-migration-strategy-rehost"></a>

託管 （或提升和轉移） 通常更快、更輕鬆，因為您不需要在應用程式中變更程式碼或架構。重新託管也會將業務的風險和中斷降至最低。營運團隊可以繼續照常執行業務，因為應用程式不會變更。對於大規模遷移來說尤其如此，因為涉及大量工作負載，即使小幅變更也會變得顯著。不過，請務必考慮重新託管不會充分利用雲端優勢。例如，如果您遷移具有現有平台問題的應用程式，該問題將在遷移後保留。最後，值得考慮的是，與其他遷移方法相比，重新託管的總擁有成本 (TCO) 和投資報酬率 (ROI) 較低。

### 何時進行 replatform/re-architect
<a name="choosing-migration-strategy-replatform"></a>

轉換通常比重新託管更具成本效益。您可以使用轉換來增強自動化，並讓應用程式更妥善地使用雲端功能，例如自動擴展、監控和執行備份。轉換可減少雲端營運團隊的營運開銷，並將既有平台問題的風險降至最低。不過，轉換需要比重新託管遷移更長的時間。此外，轉換需要額外的技能來設定在應用程式上執行程式碼變更的自動化，以及操作新平台。

### 何時重構
<a name="choosing-migration-strategy-refactor"></a>

重構通常是最具成本效益的遷移方法。重構是一種雲端原生方法，可透過解耦應用程式元件來改善應用程式彈性，讓應用程式快速適應新需求。不過，重構需要更進階的編碼和自動化技能。重構也需要更長的時間才能實作，因為它涉及重建應用程式。