一旦企業承諾在雲中運行關鍵的業務應用，他們就很少會再轉向其他的提供商，其中一個重要的原因是：他們經常被鎖定在他們所選擇的廠商生態系統中。Gartner雲服務和技術副總裁Sid Nag表示，遷移成本實在太高了。「但如果你的規劃工作做得正確，你就不必遷移你的應用。」
專業服務公司Globant的雲運營和網路安全工作室合作人Pablo Del Giudice補充說，如果你正確地定位了組織，遷移是有可能的。他和他的團隊已經成功做到了這一點。他說：「關鍵是要戰略性地採用開放平台和框架，將雲提供商降級為基礎設施層的角色。」他說，雖然這種方法的學習曲線更陡一些，但從中長期來看，會產生更有利的結果。「關鍵是要引入一個平台中立的軟體架構師，他可以劃定業務邊界並創建與特定廠商較少糾纏的解決方案。」
美國專利商標局首席資訊官Jamie Holcombe的看法則稍微微妙一些：他希望保留在雲服務提供商之間移動應用的選擇，並與所有主要提供商進行市場研究。但要做到這一點需要在第一次將應用遷移到雲之前就提前規劃好。
將鎖定風險降至最低
在利用每家廠商的雲原生服務時，你需要仔細權衡利弊。Holcombe說：「如果你選擇不使用雲提供商的原生服務來確保自己是『雲無關的』，那麼你就會失去很多『更好的、更便宜的、更快的』的業務案例指標。因此這是有代價的，就像廠商鎖定是有代價的一樣。」
Del Giudice將雲廠商鎖定分為三種形式。當你擁有完整的雲基礎配置（資源分組、策略、RBAC、混合連接、監控、合規性等）時，就會發生平台鎖定的情況，由於在新平台上重新創建所有這些配置的複雜性，導致遷移到另一個平台變得十分困難。
架構鎖定是指應用依賴於雲提供商的多個託管服務。在這種情況下，你必須先重新構建應用，然後才能遷移應用。
然後是法律鎖定，即你在預定時間內要承諾遵守企業服務協議。他說：「這些承諾很難終止，也導致遷移的執行變得十分困難。」
有時，儘管CIO們盡了最大努力避免廠商鎖定，但廠商鎖定的情況還是會出現。Nag表示，合併和收購活動通常會讓組織擁有多雲的架構，雖然CIO通常希望進行整合，但成本往往太高而無法證明其合理性。大多數時候這些CIO決定保留多雲模式，因為他們被鎖定了。「你被困住了，太大了。」
Del Giudice表示，儘管存在障礙，但組織可能有充分的理由在IaaS提供商之間進行遷移。最常見的是在價值和運營支出之間獲得更好的成本比，以利用競爭雲服務提供商的大幅折扣，並在組織想要提高可靠性時利用多雲架構。
提前規劃未來潛在的遷移
然而Nag表示，在雲提供商之間遷移關鍵應用的願望（Gartner稱之為「雲遣返」），通常是規劃不當的結果，例如在向雲直接部署的過程，或者當組織決定使用價格實惠的雲原生中間件和開發工具，以便在完成後將應用遷回本地私有雲的時候。
他建議保留MSP或者系統集成商的服務來進行規劃，並確保你選擇了正確的應用遷移到雲。「這一點很重要，因為一旦你移動了應用，就相當於你同意被鎖定在這個平台上。」
金融服務公司USAA仔細選擇了四個雲服務提供商中的哪一家來託管他們的每個工作負載和常規業務應用。「我們將雲提供商與他們最擅長的業務或技術服務結合起來，」該公司高級副總裁兼首席技術官Jeff Calusinski說道。
USAA的多雲戰略是基於他所謂的「設計開放」原則。他說：「我們使用開放標準，從而減少廠商鎖定的可能性。」但他承認，一些本地服務提供了令人信服的價值主張，必須權衡鎖定的可能性。
Nag表示，開放式設計原則在鎖定方面只能到此為止，因為即使你使用的是現代服務，每個平台上的實現方式也是有所不同的。例如，Amazon的EC2底層和谷歌的GCP做的事情是相同的，但在EC2上運行的應用如果不進行大量昂貴的返工就無法運行在GCP上。雖然Kubernetes是一個行業標準，但它的實現方式（例如Azure Communication Services 和Google Kubernetes Engine）卻是不同的。
「然而，雲提供商和應用之間已經出現了一些抽象層，」Del Giudice說，即使使用本地雲提供商服務，這些抽象層也可以簡化遷移。「這些服務，例如發布/訂閱、服務調用、機密管理、狀態管理等，抽象應用的組件，無論雲提供商是誰。」因此底線是，「你的選擇仍然是開放的，但需要進行一些操作，以便從一個雲提供商遷移到另一個雲提供商。」
數據要求是另一個需要仔細規劃的方面。Nag表示：「跨雲遷移應用的成本很高，因為你還需要移動其他相關數據，而數據移出是一項成本非常高的工作。」
Holcomble補充說，因此請提前做好計劃。「除非你達成了協議，可以知道如何取出數據以及如何在其他地方複製這些軟體服務，否則不要與提供商簽約。」
但Del Giudice表示，即使有恰當的ETL策略可以確保你能夠以結構化的方式和可用的格式在提供商之間遷移數據，但這些計劃通常是不存在的。「儘管雲服務提供商強調使用開放平台和數據訪問協議，理論上這些平台和數據訪問協議是很容易使用的，但訪問這些服務的網路限制和安全性往往被忽視了。」
在決定使用哪些雲原生服務時，有時組織別無選擇。安全就是一個很好的例子。「如果你的安全需求很高，通用的網路安全可能是不夠的。」你的需求越具體，在供應商鎖定方面對服務的要求就越嚴格。他表示，數據密集型運營的企業同時面臨存儲和帶寬問題，PaaS和IaaS提供商將這兩個因素作為他們的競爭優勢。「如果你想同時獲得高性能的存儲和帶寬，那麼問題就很棘手了。」
Holcombe遵循他所謂的「黑雲杉」方法來利用本地服務進行定製。他說，就像黑雲杉的樹枝靠近樹幹一樣，美國專利商標局也讓定製儘可能變「瘦」。這不僅可以減少鎖定，還可以確保組織不會面對負擔過重、成本高昂的版本控制路徑帶來的壓力。
Calusinski也採取了類似的方法。「大多數PaaS都具有核心功能和一些輔助功能，我們會限制輔助能力的數量，而專注於核心功能。」
Holcombe補充說，基於SaaS的應用也是如此——這是他的團隊從Remedy轉向ServiceNow和Salesforce之後所遵循的一個原則。他說：「不要進行太多定製，並在需要的時候進行更改，我們不依賴他們，這是一個很好的結構平台。但如果優化過多，你就會陷入困境。」
然而這一次，Calusinski的處理方式有所不同。「對於SaaS平台，我們會儘可能多地採用這種平台，因為作為一家企業，我們在廠商能力方面沒有看到足夠的差異化，而且變化的可能性也很低。」
避免潛在的遷移痛苦
顯然，在雲提供商之間進行遷移會帶來無數挑戰，其中包括兼容性問題、安全問題、大規模應用重新配置的需要，以及處理基於舊作業系統和過時技術堆棧的圖像，這些圖像無法無縫集成到新環境中。傳輸大量數據還可能導致停機和潛在的數據丟失，因此在遷移期間確保性能一致和可擴展性是至關重要的。「應對這些挑戰需要細緻的規劃、徹底的測試和明確的回滾策略，」Del Giudice說。
此外，PaaS遷移的關鍵失敗點包括未滿足成本或業務預期、資源技能不足、缺乏標準化和安全基礎、未利用雲原生功能、安全性和合規性問題、以及未採用雲運營模型。
Del Giudice建議，任何組織在考慮雲提供商之間遷移的時候採用六步走的方法。首先，評估訂閱模式以確保模式符合你的投資回報率目標。採用混合雲方法。儘可能使用與雲無關的解決方案，以保持未來遷移選項的開放性。使用本機雲服務時，請使用抽象層設計應用。投資數據遷移規劃、測試和備份策略以降低風險。根據需要審查和調整許可協議。
仔細權衡你的選擇
Calusinski表示，在考慮任何雲提供商遷移的時候，你始終要考慮遷移成本和數據所有權。
Holcombe表示，當你需要在使用增加鎖定的本地雲服務與保持雲無關性之間取得平衡時，沒有一個正確的答案，只有適合你組織及其使命的最佳答案。他說，問題在於基於雲的應用是否符合你組織的使命，以及隨著時間的推移為實現這一目標提供最佳價值。他說：「如果你的成本基礎設施過於複雜，那麼當業務模式發生變化的時候，你就無法改變，他補充說，要保持你的選擇是開放的，就像美國專利商標局在設計上採用多雲架構一樣。「主要原因就是服務提供商之間存在競爭。」
Del Giudice表示，在制定雲遷移策略時，務必要注意定價模型。「探索潛在的成本節約計劃，考慮數據傳輸成本，這種方法對於防止雲運營費用意外激增並確保符合預算限制來說，是至關重要的。」他補充說，在執行遷移策略時，請考慮其他兩個因素。首先，雲服務提供商可以提供哪些服務（例如微服務或無伺服器）來促進遷移？你需要決定是使用定製解決方案還是雲提供商的託管服務，這存在廠商鎖定的風險。其次，雲提供商可能會為遷移應用提供激勵計劃，對於大型遷移來說折扣力度可能是很大的。
就其本質而言，雲遷移會是存在風險。但那些提前規劃並有足夠毅力完成這一過程的CIO們，可能會看到更具成本效益的雲服務和定價模型、改進的可擴展性和資源分配、增強的性能和響應能力。Del Giudice說：「減少廠商鎖定可以促進更大的敏捷性和創新，最終，雲遷移可以推動競爭力、創新和效率。」
