CRM 2011到CRM 2016迁移

Question

我计划将我的CRM（内部）2011升级到CRM 2016（内部部署）。现在我正在寻找迁移数据的最佳方法。顺便说一下，有很多自定义数据（实体，字段，WF）。 Microsoft建议逐步升级2011-> 2013-> 2015-> 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 - > CRM 2015 - > 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的一个包装器，它允许你以更多的“工作单元”方式使用它 - 当然对于检索数据很有用，但我不喜欢它，因为它涉及所有其他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实例和SSRS实例（如果适用）设置新的CRM实例
2. 应用任何产品更新/汇总/累积更新。备份现有的CRM数据库。
3. 将数据库还原到已配置的新SQL Server实例。
4. 使用Deployment Manager并启动指向已还原数据库的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年==> 2013 ==> 2015 ==> 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软件包而不是直接汇编引用）。您的代码应该编译没有错误。