必須要事先考慮到未來可能需要更換云提供商的情況發生，可移植性和互操作性必須被作為云項目風險管理和安全保證的一部分而提前考慮。

大型的云提供商可以在云中提供異地災備，這使得一個云提供商為客戶提供高可用性的服務成為可能。然而，用戶部署基本的業務連續性計劃還是明智的，以把最壞情況造成的影響降至最低。在未來，企業可能會突然發現必須立刻更換其云提供商，主要的原因包括以下幾點：

· 無法接受續約帶來的費用增加

· 提供商停止了業務運營

· 提供商在沒有給出合理的數據遷移計劃之前，關停了企業正在使用的服務

· 無法接受服務質量的下降，比如無法完成關鍵業績要求或服務級別協議(SLA)

· 發生在云用戶和提供商之間的分歧

一些簡單的架構級設計可以幫助將上述問題發生的損害降至最低。然而，解決這些問題的辦法取決于云服務的類型。

使用SaaS的客戶可以使用新軟件應用替代舊的。因此，關注的重點不在于應用的可移植性，而是保持或增強舊應用程序的安全功能，以成功的完成數據遷移。

在PaaS情況下，為達到可移植性，一定程度上對應用的修改是需要的。關注的重點在于當保存或增加安全控制時，最大限度的降低應用重寫的數量，同時成功的完成數據遷移。

在IaaS情況下，關注的重點和期望是應用和數據都能夠遷移到新的云提供商并順利運行。由于缺乏可操作性方面的標準，也缺乏對此類標準的市場壓力，在云提供商之間的轉換可能會是一個痛苦的手工過程。從安全的角度看，我們主要的關注點(concerns)是在環境變更時維護安全控制的一致性。

建議

針對所有的云解決方案:

• 更換云提供商，至少對于一方來說，實際上是一種消極的商業業務，可能會導致來自于上一家云提供商的無法預計的消極反應。這必須在合同過程中、業務連續性規劃和全局治理中加以計劃。

• 理解托管在云提供商處的數據集合的規模。數據規模的偏差可能導致在傳輸中的服務中斷，或者是超出預期的傳輸周期。很多用戶發現在傳輸大量數據時，使用人工快遞硬盤比電子傳輸的速度要快。

• 用文檔記錄安全架構和每一個安全組件的配置，這些文檔可以用以內部審計，同時也有利于未來向新提供商的遷移。

針對IaaS 云解決方案:

• 理解新的云提供商是如何采集和移植虛擬機鏡像的，因為其可能使用不同的虛擬化技術。

• 識別和去除(至少記錄)虛擬機環境中特殊的提供商擴展。

• 理解在應用已經完成從云提供商的移植后，是否有措施到位來保證恰當地刪除(decommission)虛擬機鏡像。

• 理解硬盤和存儲設備“退役”的實踐做法。

• 理解以硬件/平臺為基礎的依賴關系，并在應用/數據遷移之前識別出來。

• 向之前的云提供商索取系統日志、線索(traces)的訪問權限，以及訪問和賬單記錄。

• 如果新提供商的服務質量不能令人滿意，選擇與前云提供商重新開始或延續一部分或整體服務。

• 確定現有系統中是否存在任何與新提供商不兼容的、或者是新提供商尚未實現的管理功能、接口或者應用程序接口(API)。

針對PaaS云解決方案:

• 盡可能的使用那些采用標準語法、開放應用程序接口和開放標準的平臺組件。

• 理解哪些工具可以用來做安全的數據傳輸、備份和恢復。

• 理解并文檔記錄PaaS提供商特殊的應用組件和模塊，并開發包含抽象層次的應用架構以減少對私有模塊的直接訪問。

• 理解類似監控、日志記錄和審計等基礎服務在新提供商的系統中如何傳送。

• 理解前云提供商提供的控制功能，以及如何將其過渡到新提供商的系統中。

• 當遷移到一個新平臺時，理解其對應用的性能和可用性的影響，以及這些影響的衡量辦法。

• 理解如何在遷移之前和之后完成測試，以確保服務和應用運行正常。保證提供商和客戶都清楚自己的測試責任并進行文檔記錄。

針對SaaS云解決方案:

• 執行常規的數據提取和備份，以保證其在非SaaS模式下可用。

• 理解元數據是否可以被保存和遷移。

• 理解現有系統中是否存在任何定制工具，在將來需要被重新開發或者新的提供商必須提供這些工具。

• 保證在不同云提供商之間控制的一致性。

• 保證以下數據或文件的可移植性，包括備份和日志、訪問記錄的其余拷貝，以及其他任何可能因法律和合規原因被要求的信息。

• 理解管理、監控和報表接口，及其在不同環境之間的整合方式。

• 對于新的提供商，是否有條款規定在移植前去測試和評估應用程序。