这一次要与大家分享的议题是如何将本地端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的“虚拟机”迁移
- 基于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，需要与开发人员进行沟通协商，可以转换的进行转换，可以重写的进行重写。
- 根据收集信息，迁移评估信息，测试结果，与开发人员协商产生的结果，计划执行列表，编写实施方案，确保每一个过程得到过合理的审核验证
- 确保实施之前对Sharepoint系统执行备份
- 按照计划列表进行实施，记录实施步骤，更新计划列表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。
