本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 階段 2：計劃 在此階段中，您會使用準備階段期間收集的資訊，並提出遷移策略。遷移規劃的一個關鍵方面是合理化您針對遷移的 7 個 R 收集的資訊：重新託管、轉換、重新定位、重新購買、重構、淘汰和保留。 選擇遷移策略取決於您的業務驅動因素以進行雲端採用，以及時間考量、業務和財務限制，以及資源需求。如果您想要在雲端維持目前的工作負載，請選擇重新託管。不過，如果您想要最佳化和擴展工作負載，請考慮其他其中一個選項。 以下是資料庫遷移的 7 個 R 概觀。這些如下圖所示。 ![Database migration paths](http://docs.aws.amazon.com/zh_tw/prescriptive-guidance/latest/strategy-database-migration/images/database-migration-paths.png) + **Rehost** （提升和轉移） – 將應用程式移至雲端而不進行任何變更。例如，將您的內部部署 Oracle 資料庫遷移至雲端中 [Amazon Elastic Compute Cloud](https://aws.amazon.com/ec2/) (Amazon EC2) 執行個體上的 AWS Oracle。 + **重新定位 **(Hypervisor 層級提升和轉移） – 將基礎設施移至雲端，而無需購買新硬體、重寫應用程式或修改現有的操作。您可以將伺服器從內部部署平台遷移到相同平台的雲端服務。例如，將 Microsoft Hyper-V 應用程式遷移至 AWS。 + **Replatform** （提升和重塑） – 將應用程式移至雲端，並引入某種程度的最佳化，以利用雲端功能。例如，將內部部署 Oracle 資料庫遷移至 AWS 雲端中的 [Amazon RDS for Oracle](https://aws.amazon.com/rds/oracle/)。 + **回購 **（捨棄和購買） – 變更為不同的產品，通常是從傳統應用程式移至軟體即服務 (SaaS) 產品，然後將資料從現場部署應用程式遷移至新產品。例如，將客戶資料從現場部署客戶關係管理 (CRM) 系統遷移至 Salesforce.com。 + 重**構 **（重新架構） – 透過充分利用雲端原生功能來提高敏捷性、效能和可擴展性，以移動應用程式並修改其架構。例如，將您的現場部署 Oracle 資料庫遷移至 [Aurora PostgreSQL](https://aws.amazon.com/rds/aurora/)。此策略也可以包括重寫您的應用程式，以使用針對不同工作流程 AWS 提供的專用資料庫。或者，您可以選擇將整體應用程式現代化，方法是將其分解為存取其資料庫結構描述的小型微服務。 + **保留** （重新檢視） – 將應用程式保留在您的來源環境中。這些可能包括需要重大重構的應用程式，而且您想要將該工作延遲到稍後的時間，以及您想要保留的舊版應用程式，因為沒有遷移它們的商業理由。 + **淘汰** – 停用或移除來源環境中不再需要的應用程式。