我计划将我的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:
从2011年升级到2016年CRM的最佳方式，最佳实践 . 将数据从2011年迁移到清洁2016 CRM的最佳方式 . CRM 2016和CRM 365之间的区别（内部，两者）
非常感谢您即将到来的答案 .
4 回答
由于问题非常广泛，答案是准确的，并没有深入研究 .
从CRM 20XX升级到20YY
虽然您可以进行就地升级（现有CRM服务器现有的SQL数据库），这实际上几乎就像您应用累积更新，或者配置新服务器并使用现有SQL服务器，最好和Microsoft建议升级的方法是去做一个Migration Upgrade（新的CRM服务器新的SQL服务器） .
迁移步骤（短篇小说）：
使用新的SQL Server实例和SSRS实例（如果适用）设置新的CRM实例
应用任何产品更新/汇总/累积更新 . 备份现有的CRM数据库 .
将数据库还原到已配置的新SQL Server实例 .
使用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之间的区别
除了整个 Cloud ，两者之间的许可模式差异，仍然有一些在线独占的功能（至少目前或直到下一个本地更新） .
根据我与在线和本地客户合作的经验，在两者之间进行选择基本上归结为：
前期成本，持续维护 .
现有的基础设施（如果一家公司已经在办公室365的 Cloud 端，他们很可能最终会在线上使用CRM） .
控制升级，数据库 . On-Prem客户通常喜欢更多地控制数据库，服务器，何时更新/升级 .
Features仅在线（尽管微软确实将大部分内容推广到内部部署安装，但它们往往比在线实例慢得多，通常为3-6个月） . 内部视图和社交聆听等一些功能目前在线独家 .
动力学365：
Dynamics 365是ERP（GP，NAV，AX），Dynamics CRM和一些集成扩展工具（如Parature）的组合 . 从CRM的角度来看，它将会是与CRM 2016在线没有什么不同 . 只是后端数据结构可能会更适合所有型号 . 虽然还有更多细节尚未公布，但从功能的角度来看，它不会是一个全新的产品 . 他们可能会提出一些新的功能，就像他们对每个主要版本一样，但我们所知道的CRM仍将是主要的相同 .
我做了很多从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字段）
我一直使用的简化流程就是这样
创建没有正确状态码（使用默认值）和查找值的所有记录（因为很可能您没有相关记录） . 如果它在线，那么请关注以后无法更改的特殊字段 - createdon，createdby
更新所有记录的所有查找（因为在1.之后您拥有CRM中的所有记录）
更新所有状态，如果它是内部部署，则运行复制值的所有自定义脚本
应用自定义项
3）已经给出了相当好的答案，Dynamics365只是CRM 2016的更新（这就是为什么它的版本8.2而不是9.0），所以从CRM的角度来看，没有太多的变化 . 在升级过程中可以考虑的最大变化是可编辑的网格 - 准备一个可编辑的视图非常容易（虽然它有缺点，如没有内联记录创建），这可以简化一些场景（或将允许你放弃一些自定义解决方案） . 业务流程处理得更好，因为它们有单独的数据库表，其中保留了有关流程状态的所有重要信息（这也引入了对此流程的新SDK访问）其他东西只是化妆品，主要是针对业务人员，而不是开发人员 .
4）关于赏金问题 - 所有应用程序仍然可以使用普通的Organization.svc（通过获取IOrganizationService对象），这是CRM的SOAP endpoints . 暂时没有计划删除此 endpoints ，因此我无法看到重写此应用程序以使用webAPI的任何优势（当然's possible). XrmServiceContext is simply a wrapper over the IOrganizationService, which allows you to use it in more 1507593 way - certainly useful for retrieving data, but I don' t喜欢它，因为它涉及所有其他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 endpoints ，因此如果Microsoft决定删除或弃用此服务，您的应用程序将仍然可以正常工作 .
Best way to migrate data from 2011 to clean 2016 CRM.
几个月前，我和我正在管理的项目（本周末交付）处于同样的位置 .
在仔细研究了这个解决方案之后，我得出了以下结论：微软推荐的方式难以实现，耗时并且不会降低风险 . 请注意，在我的情况下，我们从On Premise迁移到Online，这比On Premise to On Premise更难实现 .
在我们的案例中，我们选择了旧数据库与新数据库的映射，并通过我们的集成商配置的ETL作业将所有内容迁移到CRM 2016 Online . 我相信这是最好的方法，因为我们可以完全控制正在发生的事情，如果缺少某个字段（例如，导致传真没有迁移），您可以轻松迁移该字段 .
如果您参加2011年==> 2013 ==> 2015 ==> 2016年的道路，您将拥有三重工作，因为您必须涵盖版本之间的每个差距（例如，2011年有一个领先的电话有4个字段并且在2016年只有3个）并且将不得不提出三次解决方案而不是一次 .
Difference between CRM 2016 and CRM 365 (On premises, both)
没有CRM . 除非我'm mistaken, the 365 version with Server Side Synchronization will allow you to use the 365 plugin for Outlook which has many more functionalities than the other version (which is pretty much similar to the 2011 one). Edit: I was mistaken. Dynamics 365 is the new name of CRM 2016 (following Microsoft'的新365品牌也适用于Dynamics AX） . 您的系统应该已经更新，除了名称更改（以及全新的Outlook附加组件，我还需要从管理界面手动升级您的解决方案，如"Field Service"） .
Migration plan:
由于问题被提名为赏金，我将分享我在2011年至2016年升级期间所采取的步骤（虽然我不是官方消息来源，但可能会有所帮助） .
我已经取消注册并删除了以下自定义项：javascript库，html和silverlight（xap）网络资源，插件，解决方案，工作流程 .
然后，我逐步升级了我的数据库 . 我有3个安装了不同CRM版本的虚拟机：2013年，2015年和2016年 . 当我最终将我的组织导入CRM 2016并完成检查时 - 所有数据都得到了准确更新 .
然后我重构并更新了我的自定义（在步骤1中删除了什么） . 毕竟我在临时环境中测试了它们 .
What about customizations upgrade:
80％的js代码被2013年引入的新功能 - 业务规则所取代 . 它们有助于字段级安全性：如果需要，我们可以根据特定条件或另一个字段的状态隐藏/禁用字段 .
.net自定义：工作流活动，插件，自定义应用程序保持不变 . 2016年支持2011版的所有代码（但不支持CRM 4代码） .
50％的工作流程作为插件实现，作为更快速和强大的解决方案 .
Now to the question of the bounty:
使用xrmservicecontext和organisationservice没有显着变化 .
确保您没有对CRM 4 dll的引用，然后将其所有CRM SDK引用替换为其2016版本（我建议使用nuget软件包而不是直接汇编引用） . 您的代码应该编译没有错误 .