6 個應用程序遷移策略：“6 R”，我們看到的 6 種最常見的應用程序遷移策略是：

1.重新托管?——也稱為“直接遷移”。

我們發現許多早期的云項目傾向于使用云原生功能進行凈新開發，但在組織希望快速擴展其遷移以滿足業務案例的大型遺留遷移場景中，我們發現大多數應用程序都被重新托管。例如，GE Oil & Gas發現，即使不實施任何云優化，也可以通過重新托管節省大約 30% 的成本。

大多數重新托管可以通過工具（例如CloudEndure Migration、AWS VM Import/Export）實現自動化，盡管有些客戶在學習如何將其遺留系統應用到新的云平臺時更喜歡手動執行此操作。

我們還發現，一旦應用程序已經在云中運行，就更容易優化/重新構建它們。部分原因是您的組織將具備更好的技能來做到這一點，部分原因是困難的部分（遷移應用程序、數據和流量）已經完

2.平臺重塑?——我有時稱之為“提升修補和轉變”。

在這里，可能會進行一些云（或其他）優化，以獲得一些切實的好處，但不會以其他方式更改應用程序的核心架構。您可能希望通過遷移到數據庫即服務平臺，或將應用程序遷移到 完全托管平臺來減少管理數據庫實例所花費的時間。

我們合作的一家大型媒體公司將其在本地運行的數百個 Web 服務器遷移到了 AWS，在此過程中，它從 WebLogic（一種需要昂貴許可證的 Java 應用程序容器）遷移到了 Apache Tomcat（一個開源等效項） 。除了通過遷移到 AWS 獲得的節省和敏捷性之外，該媒體公司還節省了數百萬美元的許可成本。

3.重新購買?——轉向不同的產品。

我最常將回購視為轉向 SaaS 平臺。將 CRM 遷移到Salesforce.com，將 HR 系統遷移到Workday，將 CMS 遷移到Drupal，等等。

4.重構/重新架構?——重新構想應用程序的架構和開發方式，通常使用云原生功能。

這通常是由強烈的業務需求驅動的，即添加功能、規模或性能，否則在應用程序的現有環境中很難實現。

您是否希望從整體架構遷移到面向服務（或無服務器）架構以提高敏捷性或提高業務連續性（我聽說過在 e-bay 上訂購大型機風扇皮帶的故事）？這種模式往往是最昂貴的，但是，如果您有良好的產品市場契合度，它也可能是最有利的。

5.退休?——擺脫。

一旦您發現了環境中的所有內容，您可能會詢問每個功能區域誰擁有每個應用程序。我們發現企業 IT 組合中多達 10%（我見過 20%）不再有用，可以簡單地關閉。這些節省可以促進業務案例，將團隊的注意力轉移到人們使用的東西上，并減少必須保護的表面積。

6. 保留?——通常這意味著“重新訪問”或什么也不做（暫時）。

也許仍在承受一些折舊，還沒有準備好優先考慮最近升級的應用程序，或者不愿意遷移某些應用程序。應該只遷移對業務有意義的內容；而且，隨著投資組合的重心從本地轉移到云端，保留的理由可能會減少。