應用遷移一直是云計算的問題之一，因為競爭性的市場變化能夠創造新的“***選擇”，也可以讓提供商出局。大多數用戶認為基礎架構即服務應用易于遷移，大部分人覺得平臺即服務的遷移取決于所使用的應用性能。軟件即服務通常不是遷移問題考慮的服務，因為SaaS應用屬于提供商，無法遷移。嚴苛的說，就是如此，但是遷移計劃有助于用戶處理價格和業務穩定性問題，甚至能夠幫助用戶想相同的應用，從一項SaaS服務遷移回自托管版本中。

第三方應用和SaaS優勢

軟件即服務(SaaS)應用基于提供商自己的自定制軟件，無法遷移，除非提供商設立了這樣的選項，不過這基本上就是天方夜譚。如果企業關注于遷移，選擇SaaS應首先關注那些將自己 的應用托管在第三方軟件上的提供商，而不是自主開發的提供商。軟件開發者可能與多個提供商協定托管，因此這種形式的SaaS的遷移相對容易。也可能是為本地設施購買了一個軟件副本，因此在提供商遭遇失敗或者軟件支持缺失時，“自托管”就是一種選擇。

“遷移SaaS”的***來源也是主要的提供商所提供的應用，比如微軟、SAP、甲骨文等。幾乎所有的廠商都提供SaaS，同第三方SaaS托管簽訂協議，或者自托管。關鍵在于不管托管常規應用軟件構建起來的SaaS服務在哪里，有多種提供商的產品可用都是受歡迎的選擇。專業廠商提供了垂直市場打包服務，不太可能吸引多種SaaS托管提供商的目光，因此就需要不同的方法。

IaaS取代SaaS優缺點

SaaS遷移的第二個選擇就是“自SaaS(self SaaS)”，軟件包許可證，以及云端基礎架構即服務(IaaS)托管產品，都似乎為SaaS創造了點什么。這種方法的價值在于最終服務可以和機器鏡像一樣可移植，為托管增加了更具競爭力的選擇。不好的方面在于，這種方法不像是SaaS，從操作系統到軟件，自SaaS仍舊導致了用戶的硬件成本，以及對于整個軟件堆棧的支持。這意味著自SaaS對于已定的應用，能夠創造出一個云版本，但是并不會得到SaaS的全部好處。

DIY SaaS遷移

這兩種選擇并不能完全解決SaaS的遷移問題。很多用戶正在對SaaS應用和本地應用或者云軟件進行整合，構造一種編制化多組件應用。比如，有一家公司將Salesforce CRM服務同SaaS托管的統一通信和協作結合在一起，構造了一個銷售支持應用。我們有兩個SaaS組件，如果兩個都要改變，整個銷售支持應用就會有問題。

完整SaaS應用遷移計劃制定

這個問題的一個解決方案就是合理選擇應用整合工具，用來構建更高水平的應用。很多應用前端工具(比如，思杰)，可以讓用戶為低水平應用自定制界面，;來提供數據和流程。為一個組件變更SaaS提供商意味著改變了整合定義，但是并不是整個應用。對于這種方法，SaaS服務能夠提供靈活的應用程序接口(API)很重要，這樣就可以輕松整合。比如，RESTful API通常就比

面向服務架構/簡單對象訪問協議API更易于整合。

所有的方法都失敗的情況下，SaaS整合和遷移問題可以通過自定制基于SaaS API的應用來解決。SaaS API對于開發者來說就像是一種分布式應用組件，因此可以構建到一個程序中。為了讓這個過程遠離另一個遷移風險，***實踐就是在本地類/對象中，將訪問封裝到所有的SaaS服務API中，引用一個新的對象來訪問這個服務。某種程度上來說，如果必須改變SaaS提供商，本地對象可以進行修復，來適應新提供商的API。

SaaS廠商培育遷移市場?

對于SaaS遷移而言，所有的整合和封裝戰略都依賴于競爭SaaS提供商已定應用之間的功能一致性。顯然，如果一個提供商的統一通信/協作服務提供了視頻會議，其他的提供商沒有，再多的接口整合也無法彌補功能的缺失。并不是所有的功能區別點都是顯著的，因此在承諾SaaS整合或者封裝項目之前，要有一個可用服務提供商清單，確保你構建的應用的功能是一種通用功能。

因為SaaS服務取代了***量的平臺和基礎架構組件，它們提供了***化的好處，也更易于為非技術人員所采用。

用SaaS調節遷移問題是合理的，但是用戶要知道這些調整基本上都是要增加項目成本的，減少整合的SaaS提供商，這些風險都隱藏在SaaS成本節省之下。這些劣勢需要在采用SaaS之前作出權衡，要不然處理起來可能比災難還麻煩。