

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

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

*遷移策略*是用來將工作負載遷移到 的方法 AWS 雲端。將應用程式移至雲端有七種遷移策略，稱為 *7 R*：
+  [淘汰](#retire)
+  [保留](#retain)
+  [重新託管](#rehost)
+  [重新放置](#relocate)
+  [重新購買](#repurchase)
+  [平台重建](#replatform)
+  [重構或重新架構](#refactor)

大型遷移的常見策略包括重新託管、轉換、重新定位和淘汰。大型遷移不建議使用重構，因為它涉及在遷移期間現代化應用程式。這是遷移策略中最複雜的方法，而且針對大量應用程式進行管理可能會很複雜。反之，我們建議重新託管、重新放置或重新轉譯應用程式，然後在遷移完成後現代化應用程式。

選取遷移策略對大型遷移至關重要。您可能已在調動階段或在初始產品組合評估期間選取遷移策略。本節會檢閱每個遷移策略及其常用案例。

## 淘汰
<a name="retire"></a>

這是您要停用或封存之應用程式的遷移策略。淘汰應用程式表示您可以關閉該應用程式堆疊內的伺服器。以下是淘汰策略的常見使用案例：
+ 保留應用程式或將其移至雲端沒有商業價值。
+ 您想要消除維護和託管應用程式的成本。
+ 您想要降低使用不再支援的作業系統 (OS) 版本或元件之應用程式操作的安全風險。
+ 您可能想要根據應用程式的效能淘汰應用程式。例如，您可能想要淘汰平均 CPU 和記憶體用量低於 5% 的應用程式，稱為*殭屍應用程式*。您也可以選擇淘汰在 90 天內平均 CPU 和記憶體使用量介於 5% 到 20% 的應用程式，稱為*閒置應用程式*。您可以使用探索工具中的使用率和效能資料來識別殭屍和閒置應用程式。
+ 過去 90 天內，應用程式沒有傳入連線。

如需詳細資訊，請參閱[在遷移至 期間評估要淘汰之應用程式的最佳實務 AWS 雲端](https://docs.aws.amazon.com/prescriptive-guidance/latest/migration-retiring-applications/)。

## 保留
<a name="retain"></a>

這是您要保留在來源環境中的應用程式或您尚未準備好遷移的應用程式的遷移策略。您可以選擇在未來遷移這些應用程式。

以下是保留策略的常見使用案例：
+ **安全與合規** – 您可能想要保留應用程式，以保持符合資料落地要求。
+ **高風險** – 您可以決定保留應用程式，因為它在遷移之前需要詳細的評估和計劃。
+ **相依性** – 如果您需要先遷移一或多個其他應用程式，您可以決定保留應用程式。
+ **最近升級的應用程式** – 您可能想要將遷移應用程式延遲到下一次技術重新整理，因為您最近投資了升級目前的系統。
+ **沒有要遷移的商業價值** – 沒有將某些應用程式遷移到雲端的商業價值，例如只有少數內部使用者的應用程式。
+ **遷移至軟體即服務 (SaaS) 的計劃** – 您可以選擇保留應用程式，直到廠商發佈 SaaS 版本為止。這是廠商型應用程式的常見策略。
+ **未解決的實體相依性** – 您可以選擇保留依賴沒有雲端對等之特殊硬體的應用程式，例如製造工廠中的機器。
+ **大型主機或中階應用程式和非 x86 Unix 應用程式** – 這些應用程式需要仔細評估和規劃，才能將其遷移至雲端。中階應用程式的範例包括 IBM AS/400 和 Oracle Solaris。
+ **效能** – 您可能想要根據應用程式的效能來保留應用程式。例如，您可能想要在來源環境中保留 zombie 或閒置應用程式。

## 重新託管
<a name="rehost"></a>

此策略也稱為*提升和轉移*。使用此策略，您可以將應用程式從來源環境移至 ， AWS 雲端 而不需要對應用程式進行任何變更。例如，您將應用程式堆疊從內部部署遷移到 AWS 雲端。

透過重新託管，您可以將大量機器從多個來源平台 （實體、虛擬或其他雲端） 遷移到 ， AWS 雲端 而不必擔心相容性、效能中斷、長切換時段或長距離資料複寫。

遷移工作負載時，您的應用程式會繼續為使用者提供服務，將中斷和停機時間降到最低。停機時間取決於您的切換策略。

此策略可協助您擴展應用程式，而無需實作任何可節省時間或金錢的雲端最佳化。應用程式在雲端中執行時更容易最佳化或重新架構，因為整合到 AWS 服務和管理工作負載更容易。

您可以使用下列服務來自動重新託管：
+ [AWS Application Migration Service](https://aws.amazon.com/application-migration-service/when-to-choose-aws-mgn/)
+ [AWS 雲端遷移工廠解決方案](https://aws.amazon.com/solutions/implementations/aws-cloudendure-migration-factory-solution/)
+ [VM Import/Export](https://aws.amazon.com/ec2/vm-import/)

如需重新託管遷移策略的遷移模式清單，請參閱 AWS 規範性指導網站上的[重新託管](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-rehost-pattern-list.html)。

## 重新放置
<a name="relocate"></a>

使用此策略，您可以在指定時間將包含一或多個應用程式的大量伺服器從內部部署平台轉移到平台的雲端版本。您也可以使用重新放置策略，將執行個體或物件移至不同的虛擬私有雲端 (VPC) AWS 區域，或 AWS 帳戶。例如，您可以使用此策略將 Amazon Relational Database Service (Amazon RDS) 資料庫執行個體轉移到另一個 VPC 或 AWS 帳戶。

重新定位策略不需要您購買新的硬體、重寫應用程式或修改現有的操作。在重新定位期間，應用程式會繼續為使用者提供服務，將中斷和停機時間降到最低。重新定位是在雲端遷移和操作工作負載的最快方式，因為它不會影響應用程式的整體架構。

如需重新放置遷移策略的遷移模式清單，請參閱 AWS 規範指引網站上的[重新放置](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-relocate-pattern-list.html)。

## 重新購買
<a name="repurchase"></a>

此策略也稱為 *drop 和 shop*。您可以將應用程式取代為不同的版本或產品。新應用程式應提供比現有現場部署應用程式更高的商業價值，包括可從任何地方存取、無需維護基礎設施和pay-as-you-go定價模型等功能。重新購買應用程式通常會降低與維護、基礎設施和授權相關的成本。

以下是回購遷移策略的常見使用案例：
+ **從傳統授權轉移到 SaaS** – 這消除了管理和維護基礎設施的負擔，並有助於減少授權問題。
+ **版本升級或第三方對**等項目 – 透過將現有的內部部署應用程式取代為廠商的最新版本或第三方對等雲端，您可以利用新功能、與雲端服務整合，並更輕鬆地擴展應用程式。
+ **取代自訂應用程式** – 您可以透過重新購買以廠商為基礎的 SaaS 或雲端應用程式，來避免重新編碼和重新建構自訂應用程式。

在購買之前，您需要根據您的業務需求評估應用程式，尤其是安全和合規。

購買新應用程式後，後續步驟如下：
+ 使用新系統培訓您的團隊和使用者
+ 將您的資料遷移至新購買的應用程式
+ 將應用程式整合到您的身分驗證服務，例如 Microsoft Active Directory，以集中化身分驗證
+ 設定聯網，以協助確保已購買應用程式、使用者和基礎設施之間的通訊安全 

一般而言，應用程式廠商會協助您進行這些活動，以便順利轉換。

## 平台重建
<a name="replatform"></a>

此策略也稱為*提升、修補、轉移*或*提升和重塑*。使用此遷移策略，您可以將應用程式移至雲端，並引入某種程度的最佳化，以便有效率地操作應用程式、降低成本或利用雲端功能。例如，您可以將 Microsoft SQL Server 資料庫複製到 Amazon RDS for SQL Server。

使用此策略，您可能會對應用程式進行一些或許多變更，這取決於您的業務目標和目標平台。

以下是轉換遷移策略的常見使用案例：
+ 您想要在 中移至全受管服務或無伺服器服務，以節省時間並降低成本 AWS 雲端。
+ 您想要將作業系統升級到最新版本，以改善安全性和合規狀態。
+ 您可以使用 [AWS Graviton 處理器](https://aws.amazon.com/ec2/graviton/)，這是 開發的自訂處理器，以降低成本 AWS。
+ 您可以將 Microsoft Windows 作業系統移至 Linux 作業系統，以降低成本。您可以將 .NET Framework 應用程式移植到可在 Linux 作業系統上執行的 .NET Core。適用於 [.NET 的 Porting Assistant](https://aws.amazon.com/porting-assistant-dotnet/) 是一種分析工具，可協助您將應用程式移植到 Linux。
+ 您可以將虛擬機器遷移至容器來改善效能，而無需進行任何程式碼變更。您可以使用 [AWS App2Container 遷移工具](https://aws.amazon.com/app2container/)，將 .NET 和 Java 應用程式現代化為容器化應用程式。

轉換策略可讓您的舊版應用程式保持執行狀態，而不會影響安全性和合規性。

Replatform 透過遷移至受管或無伺服器服務、將虛擬機器移至容器，以及避免授權費用，來降低成本並改善效能。

如需平台遷移策略的遷移模式清單，請參閱 AWS 規範指引網站上的[平台。](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-replatform-pattern-list.html)

## 重構或重新架構
<a name="refactor"></a>

使用此策略，您可以將應用程式移至雲端，並充分利用雲端原生功能來修改其架構，以提高敏捷性、效能和可擴展性。這取決於強大的業務需求，以擴展、加速產品和功能發佈，以及降低成本。

以下是重構遷移策略的常見使用案例：
+ 由於業務的限制或維護成本高昂，舊版大型主機應用程式無法再因應業務需求。
+ 您有一個整體應用程式已經阻礙了快速交付產品或滿足客戶需求和需求的努力。
+ 您有一個舊版應用程式，沒有人知道如何維護，或來源碼無法使用。
+ 應用程式難以測試，或測試涵蓋範圍非常低。這會影響新應用程式功能和修正的品質和交付。透過重新設計雲端的應用程式，您可以提高測試涵蓋範圍並整合自動化測試工具。
+ 基於安全與合規考量，將資料庫移至雲端時，您可能需要擷取一些資料表 （例如客戶資訊、病患或病患診斷資料表），並將這些資料表保留在內部部署。在這種情況下，您需要重構資料庫，以便將遷移的資料表與將保留在內部部署的資料表分開。

如需重構遷移策略的遷移模式清單，請參閱 AWS 規範性指導網站上的[重新架構](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migration-rearchitect-pattern-list.html)。