我正好做過兩個大型專案雲上的遷移，有一些經驗，僅供參考。

簡單說一下遷移的流程，

首先，我們編制一個遷移計劃，其中包括收集現有系統的物理架構需求，識別出來哪些業務/資料可以遷移到雲上，這個非常重要，遷到哪個雲提供商，遷移的方法等等

然後，評估每一個遷移專案的風險，風險包括避免洩露關鍵資料或資產，預算，技術等等。由於遷移期間，IDC和雲上都要同時執行一段時間，預算一定要充足。比如雲上是不支援多播技術的，這種專案就不適合遷移。

最後，要做大量培訓，形成統一認識，堅定上雲的方案。雲不是完美的，遷移過程會碰到這那樣的問題，有堅強的信念最後才能成功，尤其有一些非常複雜問題，技術非常的陳舊等等。我們過去也有一些專案遷移失敗。

下面簡單說一下具體的比較有效的三種方法：

第一種方法是指將本地硬體或虛擬機器上的資料遷移到與之相匹配的雲上。例如，如果公司的前端應用伺服器具有8個CPU、64GB的RAM和512GB的本地儲存，那麼他們將盡可能使用與該配置相匹配的雲端儲存和計算資源。但是，該解決方案缺乏彈性，該方案通常是為了滿足峰值負載而過度供應，這就會導致了雲計算成本的增加，因此這種方法作為一種短期解決措施會更佳。

第二種方法是指對企業的應用技術進行重新架構。資料遷移需要花費一定時間，而且具有較強的強制性，而對企業技術進行重新架構反而會獲得更好的效能。的確，重新對應用技術的選擇進行評估也不失為一種更好的選擇。因為企業可能會將一些解決方案從使用昂貴的商業軟體轉向開源產品上來。

第三種方法是擱置IDC應用程式，將程式內部資料遷移到SaaS。這種方法既實現了業務的現代化標準，又將基礎架構和服務的運營負擔轉嫁給了SaaS提供商。

當下國內許多IDC服務商都面臨著同一個問題，那就是整體業務下滑，不僅營收減少，還造成大量閒置資源浪費，我們要做的就是幫助IDC服務商將原來的硬體租賃轉成提供雲服務。

“把傳統IDC的伺服器硬體租賃轉化成雲服務提供”，從這個問題看，算是比較明確的“企業上雲”需求。不過，針對企業前期網上業務的不同規模和性質，企業具體的“上雲”方式還是存在不小差異的。

不過，總體來說，企業上雲和搬家類似：

1.東西不多，自己搬，東西多而雜，找搬家公司：如果企業前期網上業務很少，例如只有一個比較規整的企業網站或小程式/app後臺，那麼，直接把伺服器端的程式打包，部署到雲平臺上，再重新做好域名備案等一系列工作，測試沒問題了，把傳統IDC業務停掉就可以了。但如果東西很多，自己搬費時費力，也很難快速恢復原狀，那就找一些專門為企業提供上雲服務的公司就行。

2.專業的東西找專業的人來搬：典型的就是比較複雜而龐大的資料了，包括有些企業需要在上雲的過程中，更換資料庫產品，例如從Orcale到Mysql，這就更需要藉助專業的公司或工具了，畢竟資料屬於企業的命脈所在，非常珍貴，不容有失。

3.想在搬家的時候煥然一新，那就需要找個設計師重新設計一下：例如有些企業，以前的業務系統非常龐雜而笨重，這時候如果想上雲，可能就不是簡簡單單的搬家了，而是需要對企業的業務系統進行一下重構，包括基於比較熱門的微服務架構進行一些系統改造，或者如果企業擔心自己的資料安全，那麼可以設計一個混合雲的上雲模式等等。這樣進行企業上雲，才能夠更好地發揮雲計算的能力，也可以為企業以後的業務系統擴充套件打好基礎。既然是搬家，就要搬到一個煥然一新的新家裡去，而不是把以前的垃圾場原封不動地搬過去。