這一次要與大家分享的議題是如何將本地端Sharepoint2013遷移至Sharepoint Online，
首先，爲什麼要遷移到Sharepoint Online呢，通常會有這樣幾個原因1.公司Sharepoint 2013訪問量過高，沒有那麼多的財力人力去維護支撐這樣一套Sharepoint平臺 2.覺得本地端的某些體驗不如Sharepoint Online上面的體驗好，爲了更好的體驗而選擇Sharepoint Online 。
對於Office 365 相信大家都有或多或少的瞭解，簡單來說，Office 365 是微軟公司提供的一套Saas模型的公有云租用平臺，由微軟在Windows Azure數據中心，部署了一套大規模的Sharepoint+Exchange+Lync+其它Office產品構成的多租戶的架構。從筆者2011年接觸至現在，Office 365已經發展爲一個相對於比較成熟的平臺
使用Office 365的一個體驗就是服務器的硬件，虛擬化，以及服務器產品，甚至你都不需要去管理，所有的這些都是由微軟的工程師負責，他們會在保證你的業務連續性的情況下進行補丁更新及維護操作。這就是Saas模型雲計算的特徵，用戶只需要進行基本的管理、使用與監控操作。後臺的服務器管理完全由雲提供商進行，你只需要按需使用付費就可以了
微軟的SharepointOnline 不光提供了純粹了公有云模型，你也可以根據需求部署爲混合雲的模型，Sharepoint Online可以與本地端進行的混合點大體包括
身份驗證可以在本地搭建一臺ADFS將用戶同步至365，身份驗證返回至本地端驗證
本地端Sharepoint2013 with SP1 OneDrive for Business 可以重定向至雲端OneDrive
本地端Sharepoint2013 with SP1 新聞源可以重定向至Yammer，或集成yammer至本地
混合式搜索
基於沙箱或SharepointApps Model的應用程序混合部署遷移
Sharepoint Online通過BCS寫回至本地端Sharepoint 2013
基於IAAS的“虛擬機”遷移
基於Hybrid Picker的自動化站點遷移
基於SAAS的“Sharepoint內容資料”遷移
今天我們主要介紹的是最後一種基於SAAS的“Sharepoint內容資料”遷移，所謂內容資料的遷移就是簡單的將本地的Files Server 裏面的文件或 Sharepoint 2013 裏面的文檔庫，列表，在保證內容完整性與一致性的前提下遷移至Sharepoint Online 。
在遷移之前，我們有幾個事情要進行考慮
那些資料要遷移到SharepointOnline à遷什麼
決定什麼資料要遷移到SharepointOnline是第一步要做的事情，也是規劃裏面最重要的一環，首先，從管理員的角度進行收集，查看當前Sharepoint 2013裏面存放多少文檔，如果文檔很少的話，可以採取自助遷移的方式，讓用戶手動將文檔上傳至Sharepoint Online。如果文檔很多，文件夾嵌套也有很多的話，就需要考慮由IT管理員進行遷移了。一旦決定要由IT管理員進行遷移，那麼IT管理員應該去與公司相關使用Sharepoint 2013的部門進行溝通，對於部門使用相對而言比較頻繁的文檔是一定要遷移上去的，對於已經陳舊不被使用的文檔，不使用或空的文檔等可以選擇性的進行排除操作。建立起遷移包含與遷移排除記錄列表，在初步規劃定義的時候，應儘可能謹慎，細化的去進行記錄。
採取什麼方式進行遷移 à怎麼遷
決定了那些資料要進行遷移後，就可以開始着手規劃遷移設計了，一共有哪些資料，不同的資料應該如何進行遷移
文件或文件夾
這類文件通常屬於在FileServer 文件夾中或Sharepoint Server 的文檔庫，這一類文件資料是最容易遷移上去的，微軟提供了Import Services 或者 Migration API 兩種自帶的遷移方案，本次博客裏面主要將以Migration API爲主，通過Migration API或者Import Services遷移上去的文件資料可以保存文件的詳細信息，通過與AAD配合也可以將權限映射過去
工作流、網站功能、網站架構
這類文件，通常是Sharepoint網站上自帶的一些工作流，網站自帶的網站功能，對於Sharepoint自帶的一些工作流或者功能，是可以通過導入導出進行遷移的，如果是一些定製化的程序，例如場解決方案，需要註冊到GAC的，這些定製化或者是需要在操作系統做修改的，都不能遷移過去，針對於這一類定製化的程序，通常是轉換代碼爲支持遷移至Sharepoint Online的，例如，可以考慮轉換爲沙箱code，或者Sharepoint apps model
定製化界面
這類文件，通常是由開發人員定製的一些html，JS，CSS，針對於這類文件，通常要開發人員配合進行替換操作。
通過以上總結，我們可以大概看到，整個遷移的遷移成本與遷移難度，大致是如下圖所示
簡單的總結一下，整體的遷移流程建議是這樣
管理員使用相關工具，蒐集當前Sharepoint 裏面的文件，定製化代碼，解決方案，功能，工作流等，可以考慮使用stsadm -o enumallwebs命令進行蒐集
收集完成後管理員獲得當前SharepointServer的內容列表，應根據使用率情況，去與公司相關使用部門進行溝通，確認需要遷移的文件列表，確認不需要進行遷移的文件排除列表，例如陳舊文件，空文件等。梳理完成文件
進行遷移評估，評估遷移所需網絡，相關技術限制，兼容性限制，建議搭建測試環境進行測試，在測試環境進行測試可以幫助管理員暴露出問題，便於進行排錯整理。
如果定製化內容過多，或者定製化內容不兼容Sharepoint Online，需要與開發人員進行溝通協商，可以轉換的進行轉換，可以重寫的進行重寫。
根據收集信息，遷移評估信息，測試結果，與開發人員協商產生的結果，計劃執行列表，編寫實施方案，確保每一個過程得到過合理的審覈驗證
確保實施方案有相關的回退計劃，並且經過風險評估，風險控制。
按照計劃列表進行實施，記錄實施步驟，更新計劃列表check狀態
大體上的一些東西說完之後，我們接下來再來看看具體的實戰，本次實戰我們主要採用Migration API的方式進行遷移，遷移內容主要以文件服務器內容以及Sharepoint文檔庫內容爲主。
Migration API是微軟提供的一組本地端對雲端的遷移API，它的遷移流程大概如下
資料來源可以是文件服務器、SharepointServer，或者是企業內部其它文件存放的地方
通過MigrationAPI 提供的Powershell命令，它會將不論你是來自於文件服務器還是其它產品的文件內容，轉換爲和Sharepoint Server導出的文件格式一樣的文件。如果你的來源是Sharepoint Server，這一步就不需要進行。
將來源的文件轉換爲統一的SharepointExport格式之後，通過Migration API powershell執行，會再次將export之後的文件，轉換爲SharepointOnline 所支持的導入文件格式，這裏你會得到兩個文件，一類是真實的文件內容，一類是有元數據組成的XML
轉換完成後，按照SharepointOnline的需求，你可以選擇在Azure Blob中建立兩個容器來存放轉換的文件及XML，你也可以選擇直接使用Office 365提供的導入服務進行存放
存放完成後，在SharepointOnline裏面，會把遷移工作做成一個timejob，我們需要去submit這個job，調取導入Azure blob裏面的內容
觀察這個Job的執行狀態，剛開始可能會是queue狀態，當狀態消失後，Job執行完成，即可看見遷移之後文件出現在Sharepoint Online。
