迁移Office365：予之易，取之难

拥抱云已经成为了IT发展潮流不可违逆，但我相信许多人并不知道违逆的代价是什么。比如说我们可以很方便地将Exchange邮箱迁移到Office365，通过O365导入服务可以迁移几乎本地数据（PST, Sharepoint站点，文件服务器）。但你有没有意识到当你想把数据迁回本地会有多复杂？

在今年Ignite上碰到了Veeam和Mimecast（这是两家专注数据备份的公司）的工程师，他们说已经找到了好办法将Office365中的组织信息取出来。

微软显然非常关注并致力于将用户的数据尽可能多地导入到Office 365，他们甚至开发了FastTrack中心以加快邮箱迁移到Exchange Online的速度，还有Office 365导入服务可以将PST, Sharepoint，文件以及其他数据包快速导入到Office 365。当然，如果租户是结合本地Exchange和Exchange Online的混合部署，是可以选择双向迁移的。

然而我们渐渐发现，混合部署居然是唯一能将数据移出Office 365的架构模型。当邮箱迁移回本地服务器，用户可以再将其导出等等。

当然，Office 365不光只有Exchange服务，它纳入的文件类型包括Sharepoint文档，列表及配置数据，视频内容可以传到Office 365的视频门户，eDiscovery案例，Skype4Biz配置以及Onedrive4Biz站点等等。另一些诸如Office365Group的功能虽然无法在企业内部部署，但同样可以帮助将裸数据（Raw Data）迁移到云。

我不知道大家有没有用过Sharegate的迁移工具，他可以将Group库迁移回本地服务器，还原Sharepoint组站点以及共享邮箱，不过这都需要手工操作和配置。

在将租户的数据从Office365迁移回本地后，还需要一个自动化的过程使其满足本地的文件格式，但是目前还没有一个大而全的办法扫描Office365上的搜索结果并将所有数据条目罗列并提取出来。

我一度怀疑是Office365提供的API接口不够致使将大数据迁移回组织非常头疼，有些API确实存在并且可用，只是它们不是设计来做数据迁移的。例如EWS是用来往Exchange Online迁移PST文件的，也支持反向传输。只是作为一个用来提供用户访问接口的API在数据传输的表现实在令人捉鸡。这也就是为什么Spanning这样的公司企图使用EWS来备份Exchange Online到本地遇到的最大瓶颈。而微软提供给Office365的基于REST的API在传输大数据时也同样有速率的问题。

而且随着你使用Office365的深入，就会越来越依赖于它，因为越来越多的数据移到了Office365，越来越多的O365的功能被用到。以权限管理为例，要在组织内做权限管理相当复杂，而在Office365上就很容易，当你要抛弃Office365的时候，大批的受保护的邮件和文档怎么办呢？

当你鼓起勇气要抛弃Office365时，你要面对的是如何将大量的数据从云端移出，或者找到一家可以提供这一服务的厂商。（待续）