CRM 2011到CRM 2016的迁移

Question

我计划将我的CRM（本地版）2011升级到CRM（本地版）2016。现在我正在寻找最佳方式来迁移数据。顺便说一下，有很多自定义数据（实体、字段、工作流程）。 微软建议逐步升级2011->2013->2015->2016（因为数据库结构发生了显着变化，正如他们所说），但这对我来说不是最佳方式。我想先进行清洁安装，然后将数据从2011移动到2016。 我想到的解决方案是调查新结构，然后编写自定义SQL脚本来完成工作。是否有现成的方法？ 另一个问题是关于CRM版本。微软提供Dynamics CRM 365（本地版）和Dynamics CRM 2016（本地版）。有什么区别？据我所知，365类似于订阅许可证，而2016是一次性付款？

TL;DR: 1. 从2011升级到2016 CRM的最佳方式，最佳实践。 2. 从2011迁移到清洁的2016 CRM的最佳方法。 3. CRM 2016和CRM 365之间的区别（本地版，两者都是）

谢谢您即将提供的答案。

- Arsinclair

---

我的问题有什么问题，为什么会被扣分？我该如何改进它？ 我已经在互联网上搜索了很长时间的信息，但如果明显的主题广泛是一个原因，我没有找到任何符合我的需求的东西。 - Arsinclair

我不知道它出了什么问题，但我们处于同一艘船上，这也是一个对我们有益的好问题。我会点赞它。 - TravisWhidden

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升级而来。如果最后一个是真的，并且自定义的数量很大 - 在大多数情况下，我会删除所有Javascript和插件，并从头开始编写它们。虽然在成功迁移到CRM 2011之后Rollup 12可能会使所有脚本和插件正常工作，但通常可以使用CRM 2016的一些新功能（不仅仅是业务规则，我个人不喜欢，而主要是计算字段或汇总字段）来实现CRM 4.0中的大多数逻辑，因此没有必要将所有这些内容保留在某些JavaScript或插件中。如果系统起源是CRM 2011，那么我只会审计可以简化的功能，但通常不会重写整个功能，只需进行一些调整。如果脚本包含OrganizationData服务调用，我通常会重写它们以使用webAPI - OrganizationData即将从CRM中删除，因此这是一个好事情。

当然，在将组织导入到目标环境后，我会应用所有修改过的自定义内容（这些内容是在另一个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决定删除或弃用此服务，则您的应用程序将仍然正常工作。

- Pawel Gradecki

Answer 2

由于问题非常广泛，答案精确到位，不会深入探讨主题。

从CRM 20XX升级至20YY

---

虽然你可以进行“原地升级”（现有的CRM服务器+现有的SQL数据库），这本质上几乎就像应用了累积更新一样。或者提供一个新的服务器并使用现有的SQL服务器，但最好且是微软推荐的升级方式是进行迁移升级（新的CRM服务器+新的SQL服务器）。

迁移的步骤（简述）：

1. 提供一个带有新的SQL Server实例和SSRS实例（如适用）的新CRM实例。
2. 应用任何产品更新/补丁程序/累积更新。 备份现有的CRM数据库。
3. 将数据库还原到提供的新SQL Server实例中。
4. 使用部署管理器，并启动导入组织过程，指向还原的数据库，这将开始升级过程。

较长的故事将涉及使用SDK的最新版本升级插件（这将涉及取消注册、升级并重新注册所有插件和步骤），设置身份验证、SPN等。 我建议认真阅读上面链接的文章。

请注意，升级必须是逐步的（例如2011-2013-2015-2016，如果有适用的CUs，则在中间进行）。

从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.在线独有的功能（尽管Microsoft通常也会将它们推出到本地安装中，但它们的速度要比在线实例慢得多，通常需要3-6个月）。一些功能，如内部视图和社交侦听，目前仅在线独有。

Dynamics 365：

---

Dynamics 365是ERP（GP，NAV，AX），Dynamics CRM和一些集成扩展工具（如Parature）的组合。从CRM的角度来看，它与CRM 2016 online没有什么不同。只是后端数据结构可能会更加统一化。虽然还有更多细节有待公布，但从功能角度来看，它不会是一个全新的产品。他们可能会推出一些新功能，就像每个主要版本发布时一样，但我们所知道的CRM仍然会是主导。

- dynamicallyCRM

---

谢谢您的回答。除此之外，我稍后会考虑一下，我想澄清我的第三个问题，也许我没有准确表达我想知道的：这个问题不是关于在线和OnPremises之间的区别，而是关于CRM v2016和CRM v365之间的区别（有时我看到Microsoft提供有关365的信息，有时写成2016，但因为所有这两个功能都可以安装在本地，我认为它们不同，只是在许可方法上有所不同）。 - Arsinclair

@R.Matveev，我已经更新了答案，Dynamics 365不会改变我们所知道的CRM。只是微软将不同的产品集中在一个平台下（更统一的服务）。 - dynamicallyCRM

Answer 3

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

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

在研究了一些解决方案后，我得出以下结论：微软推荐的方法很难实现，耗时且完全不降低风险。请注意，在我的情况下，我们从On Premise迁移到Online，这比从On Premise到On Premise更难实现。

在我们的情况下，我们选择了旧数据库与新数据库的映射，并通过我们的集成商配置的ETL作业将所有内容迁移到CRM 2016 Online。我认为这是最好的方法，因为我们对发生的一切都有完全的掌控权，如果有字段丢失（例如，潜在客户的传真未被迁移），您可以轻松地迁移该字段。

如果您选择2011 ==> 2013 ==> 2015 ==> 2016路线，您需要三倍的工作量，因为您需要覆盖每个版本之间的差距（例如，在2011年的潜在客户中有4个电话字段，而在2016年只有3个），并且必须三次提出解决方案而不是一次。

CRM 2016和CRM 365之间的区别（On Premises，两者都是）

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

- Loic O.

---

在我的情况下，由于我们已经进行了升级，我们首先在CRM 2011上更新了CRM 2013。几乎所有的数据都很完美。 然后从2013迁移到2015和2016时遇到了一些问题，所以我们像你们一样：为我们感兴趣的数据库中的表创建映射，然后只需安装2016并运行我们的脚本即可移动数据。从2011迁移到2013，然后创建自定义脚本比直接从2011迁移到2016并创建迁移数据脚本要简单得多。 - Arsinclair

我可以问一下你是如何设置CRM 2013环境的吗？据我所见，许可证已不再分发？ - Loic O.

您可以使用试用许可证密钥来设置新环境或升级现有环境以迁移数据。试用密钥提供90天的使用期限（据我所记）。 - Arsinclair

Answer 4

迁移计划：

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

1. 我注销并删除了以下自定义内容：JavaScript库、HTML和Silverlight（XAP）Web资源、插件、解决方案、工作流程。
2. 然后，我逐步升级了我的数据库。我有3个安装了不同CRM版本的VM：2013年、2015年和2016年。当我最终将我的组织导入CRM 2016并进行检查时，所有数据都准确更新。
3. 然后我重构和更新了我的自定义内容（在步骤1中删除的内容）。最后我在分段环境中对它们进行了测试。

---

自定义内容升级怎么样：

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

---

现在是悬赏问题：

使用xrmservicecontext和organisationservice的工作并没有显著改变。

确保您没有引用CRM 4 DLL，然后只需用它们的2016版本替换所有CRM SDK引用（我建议使用NuGet软件包而不是直接引用程序集）。您的代码应该可以编译而不出错。

- Arsinclair