走进Sharepoint2013至Sharepoint Online迁移①

标签：迁移   sharepoint   migration   sharepoint online   

  这一次要与大家分享的议题是如何将本地端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。

本文出自 “一个倔强的孤岛” 博客，请务必保留此出处http://wzde2012.blog.51cto.com/6474289/1718949

走进Sharepoint2013至Sharepoint Online迁移①

标签：迁移   sharepoint   migration   sharepoint online   

原文地址：http://wzde2012.blog.51cto.com/6474289/1718949