CRM 2011到CRM 2016迁移

Question

我计划将我的CRM（内部部署）2011升级到CRM 2016（内部部署）。现在我正在寻找迁移数据的最佳方法。顺便说一下，有很多自定义数据（实体，字段，WF）。 Microsoft建议逐步升级2011-＆gt; 2013-＆gt; 2015-＆gt; 2016（因为db strucutre显着改变，正如他们所说），但这对我来说不是最佳方式。我想先做清洁安装，然后将数据从2011年移到2016年。 我所遇到的解决方案是调查新结构，然后编写自定义SQL脚本，这将完成工作。有没有开箱即用的方式？

另一个问题是关于CRM版本。 Microsoft提供Dynamics CRM 365（内部部署）和Dynamics CRM 2016（内部部署）。有什么不同？我可以发现，当2016年是一次性支付时，365就像订阅许可证一样？

TL; DR：

  

  
1. 从2011年升级到2016年CRM，最佳实践的最佳方式。
  
2. 将数据从2011年迁移到清洁2016 CRM的最佳方式。
  
3. 之间的区别   CRM 2016和CRM 365（内部，两者）
  

非常感谢您即将到来的答案。

Answer 1

我做了很多从CRM 2011到CRM 201X的迁移，包括CRM 2016和Dynamics365。以下是我收集的有关问题的建议/想法

1）基本上，CRM Deployment Manager处理的组织迁移可以很好地完成其工作。我通常在不同的服务器上创建一个临时环境（因此CRM 2013 - ＆gt; CRM 2015 - ＆gt; CRM 2016）制作数据库的完整副本，在下一台服务器上恢复它并使用Deployment Manager导入组织。至于自定义 - 它取决于CRM的年龄，它有多少自定义以及是否从CRM 4.0升级。如果最后一个是真的并且自定义量很大 - 在大多数情况下我删除所有Javascripts和插件并从头开始编写它们。虽然在Rollup 12成功迁移到CRM 2011之后可能会使所有脚本和插件正常工作，但CRM 4.0的大部分逻辑通常可以通过CRM 2016的一些新功能来实现（不仅仅是业务规则，我不会这样做。就个人而言，但主要是计算字段或汇总字段）并且将所有内容保存在某些JavaScript或插件中是没有意义的。如果系统原点是CRM 2011，那么我只会审计可以简化的功能，但通常不会重写整个事情，只需进行一些调整。如果脚本包含OrganizationData服务调用，我通常会将它们重写为使用webAPI - 很快就会从CRM中删除OrganizationData，所以这是一件好事。

当然，在将组织导入目标环境后，我将应用所有已修改的自定义项（在单独的DEV环境中进行并彻底测试）。

2）我总是将Kingswaysoft SSIS Connector用于此类目的。我测试了所有其他工具，这只是最灵活的，因为它包含了SSIS包的所有功能，只是为您提供了一个易于使用的连接器。当然这是我个人的偏好，所有工具最终应该完成它们的工作。

当我在两个内部部署环境（通常在同一个域中）之间迁移数据时，我不会为迁移特殊字段（例如createdby，modifiedby，statuscode，statusreason等）而烦恼。我只关注记录ID。当我创建了所有记录时，我只需使用T-SQL脚本更新所有有问题的字段，因为它的速度要快得多。当然，迁移到Online时无法做到这一点，因此迁移将花费更多时间（并且您将无法迁移，例如modifiedon字段）

我一直使用的简化流程就像那样

1. 创建没有正确状态代码（使用默认值）和查找值的所有记录（因为很可能您没有相关记录）。如果它在线，则关注以后无法更改的特殊字段 - createdon，createdby
2. 更新所有记录的所有查询（因为在1.您拥有CRM中的所有记录后）
3. 更新所有状态，如果内部部署运行所有自定义脚本复制值
4. 应用自定义

3）已经给出了相当不错的答案，Dynamics365只是CRM 2016的更新（这就是为什么它的8.2版而不是9.0版），因此从CRM的角度来看，没有太多变化。在升级过程中可以考虑的最大变化是可编辑的网格 - 它可以很容易地准备一个可编辑的视图（虽然它有它的缺点，如没有内联记录创建），它可以简化一些场景（或者允许你放弃一些自定义解决方案）。业务流程处理得更好，因为它们有单独的数据库表，其中保留了有关流程状态的所有重要信息（这也引入了对此流程的新SDK访问）其他东西只是化妆品，主要是针对业务人员，而不是开发者。

4）至于赏金问题 - 所有应用程序仍然可以使用普通的Organization.svc（通过获取IOrganizationService对象），这是CRM的SOAP端点。暂时没有计划删除此端点，因此我无法看到重写此应用程序以使用webAPI的任何优势（当然可能）。 XrmServiceContext只是IOrganizationService的一个包装器，它允许你在更多＆＃34;工作单元＆＃34;中使用它。方式 - 对于检索数据肯定有用，但我不喜欢它，因为它涉及到所有其他CRUD操作。但无论如何 - 它仍然只是一个包装器，所以唯一重要的是你如何获得IOrganizationService。回到CRM 2011，你最有可能使用OrganizatoinServiceProxy类，你使用适当的凭据数据进行实例化（就像我在这里解释的那样：https://stackoverflow.com/a/42873662/7708157）。目前建议的方法是使用Microsoft.Xrm.Tooling.Connector程序集（只需从nuget-Microsoft.CrmSdk.XrmTooling.CoreAssembly获取它）并将CrmServiceClient与连接字符串一起使用（请参阅：https://msdn.microsoft.com/en-us/library/jj602970.aspx）。这将允许您获取IOrganizationService，您可以将其包装在xrmservicecontext或任何您想要的内容中。建议使用此方法，因为将来很可能这个包将开始使用webAPI而不是Organization.svc端点，因此如果Microsoft决定删除或弃用此服务，您的应用程序仍然可以正常运行。

Answer 2

由于问题非常广泛，答案是准确的，并没有深入研究。

从CRM 20XX升级到20YY

虽然您可以进行就地升级（现有CRM服务器+现有SQL数据库），这实际上几乎就像您应用累积更新，或者配置新服务器并使用现有SQL服务器，微软推荐的升级方法是开始Migration Upgrade（新的CRM服务器+新的SQL服务器）。

迁移步骤（短篇小说）：

1. 使用新的SQL Server实例和一个新的CRM实例 SSRS实例（如适用）
2. 应用所有产品更新/汇总/累积更新。备份 现有的CRM数据库。
3. 将数据库还原到新配置的SQL Server实例。
4. 使用部署管理器并启动Import Organization 进程指向已恢复的数据库，该数据库将启动 升级过程。

长篇故事涉及使用最新版本的SDK升级插件（包括取消注册，升级和重新注册所有插件和步骤），设置身份验证，SPN等。我建议给予文章上面链接了很好的阅读。

请注意，升级必须是增量的（例如2011年 - 2013年 - 2015年 - 2016年，如果有的话，适用的CU之间）。

将数据从20XX迁移到20YY CRM的最佳方式

如果您按迁移升级路由或任何支持的升级路径，则无需将数据从20XX迁移到20YY。有一个思考过程，升级会无意中需要数据迁移，但实际上并非如此。除非您从其他系统移动数据或更改/清理现有的CRM数据结构（合并实体，移动注释等），否则您很可能不需要任何迁移。

假设您需要执行上述操作之一，一些最常用的集成工具是Scribe for Microsoft Dynamics CRM或KingswaySoft for Dynamics CRM。我最喜欢的是KingswaySoft可轻松扩展以及定价模式（您实际上可以购买3个月的许可证并完成迁移，因为迁移是一次性操作）。

CRM On-Prem和CRM Online之间的区别

除了整个云，两者之间的许可模式差异，仍然有一些在线独占的功能（至少目前或直到下一个本地更新）。

根据我与在线和本地客户合作的经验，选择两者之间基本上归结为：

1. 前期费用，持续维护。
2. 现有基础设施（如果公司已经在云上使用 办公室365，他们最有可能最终使用CRM在线）。
3. 控制升级，数据库。 On-Prem客户通常是 那些喜欢更多控制数据库，服务器，什么时候 更新/升级。
4. Features仅在线（虽然微软确实在线） 其中大部分都是在内部安装，但它们往往会来 比在线实例慢得多，通常是3-6个月）。一些功能，如内部视图和社交聆听，目前在线独家。

Dynamics 365：

Dynamics 365是ERP（GP，NAV，AX），Dynamics CRM和一些集成扩展工具（如Parature）的组合。从CRM的角度来看，它与CRM 2016在线无异。只是后端数据结构可能会更适合所有型号。虽然还有更多细节尚未公布，但从功能的角度来看，它不会是一个全新的产品。他们可能会提出一些新的功能，就像他们对每个主要版本一样，但我们所知道的CRM仍将是主要的。

Answer 3

将数据从2011年迁移到清洁2016 CRM的最佳方式。

几个月前，我和我正在管理的项目（本周末交付）处于同样的位置。

在仔细研究了这个解决方案之后，我得出了以下结论：微软推荐的方式难以实现，耗时并且不会降低风险。请注意，在我的情况下，我们从On Premise迁移到Online，这比On Premise to On Premise更难实现。

在我们的案例中，我们选择了旧数据库与新数据库的映射，并通过我们的集成商配置的ETL作业将所有内容迁移到CRM 2016 Online。我相信这是最好的方法，因为我们可以完全控制正在发生的事情，如果缺少某个字段（例如，导致传真没有迁移），您可以轻松迁移该字段。

如果你去参加2011年==＆gt; 2013 ==＆gt; 2015 ==＆gt; 2016年道路，您将拥有三重工作，因为您必须涵盖版本之间的每个差距（例如，2011年有一个领域的电话有4个领域，2016年只有3个领域）并且必须提供三次解决方案而不是只有一次。

CRM 2016和CRM 365之间的区别（内部，两者）

没有CRM。除非我弄错了，带有服务器端同步的365版本将允许您使用Outlook的插件，它具有比其他版本更多的功能（这是几乎与2011年相似）。编辑：我错了。 Dynamics 365是CRM 2016的新名称（遵循Microsoft的新365品牌，也适用于Dynamics AX）。您的系统应该已经更新，除了名称更改（以及尚未测试的全新Outlook附加组件）之外，您还可以将“客户之声”集成到系统中，而不是作为解决方案。我认为还有其他一些变化。请注意，您需要从管理界面手动升级解决方案，例如“现场服务”。

Answer 4

迁移计划：

由于问题被提名为赏金，我将分享我在2011年至2016年升级期间所采取的步骤（虽然我不是官方消息来源，但可能会有所帮助）。

1. 我已经取消注册并删除了以下自定义项：javascript库，html和silverlight（xap）网络资源，插件，解决方案，工作流程。
2. 然后，我逐步升级了我的数据库。我有3个安装了不同CRM版本的虚拟机：2013年，2015年和2016年。当我最终将我的组织导入CRM 2016并完成检查时 - 所有数据都得到了准确更新。
3. 然后我重构并更新了我的自定义（在步骤1中删除了什么）。毕竟我在临时环境中对它们进行了测试。

自定义升级如何：

1. 80％的js代码被2013年推出的新功能 - 业务规则所取代。它们有助于字段级安全性：如果需要，我们可以根据特定条件或另一个字段的状态隐藏/禁用字段。
2. .net自定义：工作流活动，插件，自定义应用程序保持不变。 2016年支持2011版本的所有代码（但不支持CRM 4代码）。
3. 50％的工作流程作为插件实现，是更快速，更强大的解决方案。

现在讨论赏金问题：

使用xrmservicecontext和organisationservice并没有显着改变。

确保您没有对CRM 4 dll的引用，然后将其所有CRM SDK引用替换为其2016版本（我建议使用nuget软件包而不是直接汇编引用）。您的代码应该编译没有错误。