CRM 2011 到 CRM 2016 迁移

Question

我计划将我的 CRM（本地）2011 升级到 CRM 2016（本地）。现在我正在寻找迁移数据的最佳方式。顺便说一句，有很多自定义数据（实体、字段、WF）。 Microsoft 建议逐步升级 2011->2013->2015->2016 （因为 db 结构发生了重大变化，正如他们所说），但这对我来说不是最好的方法。我想先进行全新安装，然后将数据从 2011 年移至 2016 年。 我找到的解决方案是研究新结构，然后编写自定义 SQL 脚本，这样就可以完成工作。有什么开箱即用的方法吗？

另一个问题是关于 CRM 版本的。 Microsoft 提供 Dynamics CRM 365（本地）和 Dynamics CRM 2016（本地）。有什么区别？我发现，365 有点像订阅许可证，而 2016 年是一次性付款？

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 部署管理器处理的组织迁移可以很好地完成它的工作。我通常在不同的服务器上创建临时环境（因此 CRM 2013 -> CRM 2015 -> CRM 2016）制作数据库的完整副本，在下一个服务器上恢复它并使用部署管理器导入组织。至于定制 - 这取决于 CRM 的历史、它有多少定制以及它是否从 CRM 4.0 升级。如果最后一个是正确的并且自定义的数量很大 - 在大多数情况下，我会删除所有 Javascript 和插件并从头开始编写它们。虽然在 Rollup 12 之后成功迁移到 CRM 2011 后可能会使所有脚本和插件正常工作，但 CRM 4.0 的大部分逻辑通常可以使用 CRM 2016 的一些新功能来实现（不仅是业务规则，我不喜欢个人，但主要是计算字段或汇总字段），将所有这些内容保留在某些 JavaScript 或插件中是没有意义的。如果系统起源是 CRM 2011，那么我只会审核可以简化的功能，但通常不会重写整个事情，只是进行一些调整。如果脚本包含 OrganizationData 服务调用，我通常会重写它们以使用 webAPI - OrganizationData 很快就会从 CRM 中删除，所以这是一件好事。

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

2) 我总是将 Kingswaysoft SSIS 连接器用于此类目的。我测试了所有其他工具，这简直是最灵活的，因为它包含了 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. 为一个新的 CRM 实例提供一个新的 SQL Server 实例和一个 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. 现有基础架构（如果公司已经在云上 office 365，他们很可能最终会使用在线 CRM）。
3. 控制升级、数据库。本地客户通常是 那些喜欢对数据库、服务器、何时进行更多控制的人 更新/升级。
4. Features 仅在线（尽管微软确实推出了 它们中的大多数也用于本地安装，但它们往往会出现 比在线实例慢得多，通常是 3-6 个月）。内部视图和社交聆听等一些功能目前是在线独有的。

动态 365：

---

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

Answer 3

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

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

在对该解决方案进行了一番研究后，我得出了以下结论：Microsoft 推荐的方式难以实施、耗时且无法降低风险。请注意，在我的情况下，我们从 On Premise 迁移到 Online，这比 On Premise 到 On Premise 更难实现。

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

如果您选择 2011==> 2013 ==> 2015 ==> 2016 年的道路，您将需要完成三重工作，因为您必须填补版本之间的每个空白（例如，电话中有 4 个字段） 2011 年领先，2016 年仅 3 次），并且必须提出 3 次解决方案，而不仅仅是一次。

CRM 2016 和 CRM 365 之间的区别（两者都在本地）

CRM 没有。 除非我弄错了，否则带有服务器端同步的 365 版本将允许您使用 Outlook 的 365 插件，它比其他版本具有更多功能（即与 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 和 organizationservice 没有显着变化。

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