云遷移≠云轉型 先遷移還是先轉型？
原創各大企業希望開始他們的云之路。但是，幾乎所有的大型企業都有一些現有的數據中心應用。向云中遷移一般可以通過兩種互為補充的方式來實現：
遷移：
現有的數據應用程序向云中遷移意味著在不改變架構，設計或交付模式的前提下，把內部的IT應用程序遷移到私有云或公有云的基礎設施中。這主要包括：
◇ 選擇一個私有云或公有云基礎設施
◇ 選擇托管應用程序的虛擬化平臺
◇ 建立一個提供應用程序服務的目錄
◇ 為應用程序創建自動操作和監控選項，以便于在私有云平臺內部進行調整。
轉型
無論遷移完成以后，還是根本就沒有選擇遷移，有時針對云平臺讓現有的應用程序做一個徹底的轉型都會是一個更好的選擇。從云的角度來看，轉型主要包括：
◇ 重新設計應用程序，讓它支持多租戶的環境
◇ 把應用程序平臺遷移到支持云的PaaS（Platform-as-a-Service）平臺上（例如：Windows Azure）
◇ 把關系數據庫遷移到云數據庫中（例如：Sql Azure或），或者遷移到Big Table（“NO SQL”數據庫）中
◇ 增加應用程序在計算方面的需求，以便于應用程序可以利用上像“Map Reduce”那樣的高性能計算
在遷移和轉型之間，各大企業可以選擇下面這些執行序列：
◇ 只遷移，不轉型
◇ 先完成遷移，然后開始轉型
◇ 遷移和轉型并行進行
◇ 馬上轉型
#p#
企業應用程序***轉化路徑（圖表）
下面這張表格可以告訴你，對于企業應用程序來說，在把數據中心遷移到云中的過程中，到底應該選擇遷移還是轉型。是/是表示先遷移，然后再轉型。
| 應用程序特征 | 遷移 |
轉型 |
| 和知識產權有關，和企業核心機密有關的應用程序 | 否 | 否 |
| 在企業內部，這個應用程序已經是一個全局性的應用 程序了，并且，這個應用程序和其他應用程序沒有功能上的重疊 |
是 | 是 |
| 實現公用的業務功能（例如：政府報告，地址清理或驗證）的應用程序（當現有的應用程序不存在授權問 題的時候，可以考慮轉型為SaaS服務） |
是 | 是 |
| 應用程序當前運行在一個不支持遺留系統的平臺上 | 否 | 是 |
| 由于合并和收購，應用程序的功能橫跨了多個業務部門和/或區域 | 否 | 是 |
| 應用程序和當前用戶在可擴展性，可用性，安全性和性能方面的QoS ( Quality Of Service：服務質量)無關 | 否 | 是 |
| 應用程序緊密地和內部的遺留應用程序耦合在了一起，而且，如果遺留應用程序程序發生了改變，這些應用程序也會被破壞 | 否 | 是 |
| 和其他企業有關的數據備份和冗余應用程序 | 否 | 是 |
| 有安全漏洞的應用程序 | 否 | 是 |
| 應用程序需要轉型，但是可用性是一個大問題，也就是說這個應用程序不能存在宕機時間。在這種情況下，可以首先把這個應用程序“原封不動”地遷移到云中，然后并行地做一些轉型工作，在應用程序徹底穩定之前，都要保證應用程序一直處于運行狀態之中。 | 是 | 是 |
| 應用程序的功能可以通過把幾個基于SaaS（Software-as-a-service）的服務組合起來來實現 | 否 | 是 |
| 應用程序運行在對PaaS（Platform-as-a-Service）比較友好的平臺（例如：Microsoft .net）上 | 是 | 否 |
| 應用程序可能不久就要“退役”了 | 否 | 否 |
總結
企業應用程序的***組合應該是這樣的：
◇ 某些公有云服務
◇ 某些遷移到私有云中的應用程序
◇ 某些由內部的應用程序，私有云的應用程序和公有云的應用程序組合而成的應用程序
只有“量體裁衣”地把應用程序遷移到公有云或私有云中，這個***組合才能實現。當遷移這些應用程序的時候，遷移它們（Transition）還是重新設計它們（Transform）的決策在企業實施云模型的過程發揮了關鍵性的作用，它直接決定了云模型是否可以取得成功。
上面提到的決策標準可以幫助企業做出這一決策。
原文名：Cloud Transition vs Cloud Transformation 作者：Srinivasan Sundara Rajan
【本文乃51CTO精選譯文，轉載請標明出處！】
【編輯推薦】
- 使用Microsoft Azure 讓云遷移變得簡便的5種方法
- VMware的混合云遷移工具：vCloud Connector
- 企業CRM等業務系統遷移到 "云"中的***實現
- 云計算該“遷移”還是“自建”?
- 云遷移全攻略：哪些應用適合遷移
