迁移遗留数据很困难.

许多组织都有旧的、复杂的内部部署业务CRM系统. 今天, 有很多云SaaS替代方案, which come with m任何 benefits; pay as you go and to pay only for what you use. 因此，他们决定迁移到新的系统.

没有人想把有价值的客户数据留在旧系统中，然后从一个空的新系统开始, 所以我们需要迁移这些数据. 不幸的是，数据迁移并不是一项简单的任务，因为 大约50%的部署工作 被数据迁移活动消耗. 根据 Gartner， Salesforce是云CRM解决方案的领导者. 因此，数据迁移是Salesforce部署的一个主要主题.

So, 我们如何确保将遗留数据成功地过渡到一个闪亮的新系统，并确保我们将保留其所有历史? 在本文中，我提供了成功迁移数据的10个技巧. 前五个技巧适用于任何数据迁移，无论使用何种技术.

一般数据迁移

1. 使迁移成为一个单独的项目

在软件部署检查表中, 数据迁移不是一个“导出和导入”项目，由一个聪明的“按下一个按钮”数据迁移工具处理，该工具为目标系统预定义了映射.

数据迁移是一项复杂的活动，需要单独的项目、计划、方法、预算和团队. 必须在项目开始时创建实体级范围和计划, 确保没有意外, 比如“哦, 我们忘记加载那些客户的访问报告了, 谁来做呢??在截止日期前两周.

数据迁移方法定义了我们是否将一次加载数据(也称为一次加载) 大爆炸)，或者我们是否会每周加载小批量.

然而，这不是一个容易的决定. 该方法必须与所有业务和技术涉众达成一致并进行沟通，以便每个人都知道何时以及哪些数据将出现在新系统中. 这也适用于系统中断.

2. 估计现实

不要低估数据迁移的复杂性. 许多耗时的任务伴随着这个过程，这些任务在项目开始时可能是不可见的.

例如, 加载特定的数据集用于训练目的与一堆真实的数据, 但是敏感的东西被混淆了, 因此，培训活动不会产生电子邮件通知客户.

估计的基本因素是要从源系统转移到目标系统的字段数.

每个领域在项目的不同阶段都需要一定的时间, 包括对这个领域的理解, 将源字段映射到目标字段, 配置或构建转换, 执行测试, 测量现场数据质量, 等等......。.

使用巧妙的工具, 比如Jitterbit, Informatica云数据向导, 海星ETL, 迈达斯, 诸如此类, 可以减少这个时间, 尤其是在构建阶段.

特别是, 理解源数据——任何迁移项目中最关键的任务——不能由工具自动化, 但需要分析人员花时间逐一浏览字段列表.

对总体工作量最简单的估计是从遗留系统转移的每个领域一个人一天.

一个例外是在相同的源模式和目标模式之间进行数据复制，而无需进一步转换——有时称为1:1迁移——我们可以根据要复制的表的数量进行估计.

详细的估算是一门独立的艺术.

3. 检查数据质量

不要高估源数据的质量, 即使遗留系统没有报告数据质量问题.

新系统有新的规则，遗留数据可能会违反这些规则. 这里有一个简单的例子. 在新系统中，联系邮箱可以是强制性的, 但是一个20年的传统系统可能有不同的观点.

历史数据中可能隐藏着地雷，这些地雷很长时间没有被触及，但在转移到新系统时可能会被激活. 例如, 使用不再存在的欧洲货币的旧数据需要转换为欧元, 否则, 货币必须添加到新系统中.

数据质量显著影响工作效率, 简单的规则是:我们在历史上走得越远, 我们会发现更大的混乱. 因此，及早决定如何做至关重要 多 我们想把历史转移到新系统中.

4. 吸引商务人士

业务人员是唯一真正了解数据的人，因此他们可以决定哪些数据可以丢弃，哪些数据可以保留.

在映射过程中，让业务团队中的某个人参与进来是很重要的, 以及将来的回溯, 记录映射决策及其原因是有用的.

因为一张图片胜过千言万语, 将测试批装载到新系统中, 让业务团队来处理它.

即使数据迁移映射是由业务团队审查和批准的, 一旦数据出现在新系统的UI中，惊喜就会出现.

“哦，现在我明白了，我们必须稍微改变一下，”成为一个常见的短语.

未能聘请相关领域的专家, 谁通常是很忙的人, 新系统上线后最常见的问题是什么.

5. 以自动迁移解决方案为目标

数据迁移通常被视为一次性活动，并且 开发人员 往往以充满手动操作的解决方案而告终，希望只执行一次. 但有很多理由避免这种做法.

• 如果迁移被分成多个波，我们必须多次重复相同的操作.
• 通常, 每一波至少有三次迁移运行:一次测试数据迁移的性能和功能的演练, 完整的数据验证负载，以测试整个数据集并执行业务测试, 当然, 生产负荷. 运行次数随着数据质量的降低而增加. 提高数据质量是一个迭代过程, 所以我们需要多次迭代来达到期望的成功率.

因此, 即使迁移本质上是一次性活动, 手动操作会显著降低操作速度.

Salesforce数据迁移

接下来，我们将介绍成功迁移Salesforce的五个技巧. 请记住，这些技巧可能也适用于其他云解决方案.

6. 为长时间的负荷做好准备

性能是, 如果不是最大的, 从内部部署到云解决方案的权衡——Salesforce也不例外.

内部部署系统通常允许直接将数据加载到底层数据库中, 有了好的硬件, 我们每小时可以轻松达到数百万条记录.

但是，不是在云端. 在云中，我们受到几个因素的严重限制.

• 网络延迟-数据通过互联网传输.
• Salesforce应用层——数据通过厚层移动 API多租户层 直到它们进入Oracle数据库.
• Salesforce中的自定义代码-自定义验证, 触发器, 工作流, 重复检测规则, 等等——其中许多禁用并行或批量负载.

因此，负载性能可以达到每小时数千个帐户.

可以更少, 或者更多, 视情况而定, 比如字段的数量, 验证和触发器. 但它比直接加载数据库要慢好几级.

性能下降, 这取决于Salesforce的数据量, 还必须考虑.

它是由用于检查外键的底层RDBMS (Oracle)中的索引引起的, 独特的领域, 以及对复制规则的评估. 最基本的公式是每10年级大约有50%的减速, 由排序和b树操作的时间复杂度部分O(logN)引起.

此外，Salesforce有许多资源使用限制.

其中之一是 批量API限制设置 在24小时滚动窗口内最多可查询5,000个批次，每个批次最多可查询10,000条记录.

理论上的最大值是在24小时内加载5000万条记录.

在一个真实的项目中, 由于使用时的批量大小有限，最大值要低得多, 例如, 自定义触发器.

这对数据迁移方法有很大的影响.

即使对于中等规模的数据集(从100,000至100万账户), 大爆炸理论是不可能的, 因此，我们必须将数据分成更小的迁移波.

这, 当然, 会影响整个部署过程，并增加迁移的复杂性，因为我们将向已经由以前的迁移和用户输入的数据填充的系统中添加数据增量.

我们还必须在迁移转换和验证中考虑这些现有数据.

此外，长时间的加载可能意味着我们无法在系统停机期间执行迁移.

如果所有用户都位于一个国家，我们可以利用夜间8小时的中断.

但对于像可口可乐这样业务遍布全球的公司来说，这是不可能的. 一旦我们有了U.S., 日本, 和欧洲在这个体系中, 我们跨越所有时区, 所以周六是唯一不影响用户的停机选项.

这可能还不够，所以，我们必须装子弹 同时在线，当用户使用系统时.

7. 在应用程序开发中尊重迁移需求

应用程序组件, 例如验证和触发器, 应该能够处理数据迁移活动. 如果系统必须在线，则不能在迁移加载时硬禁用验证. 而不是, 我们必须在验证由数据迁移用户执行的更改时实现不同的逻辑.

• 日期字段不应该与实际的系统日期进行比较，因为那样会禁用历史数据的加载. 例如，验证必须允许输入迁移数据的过去帐户开始日期.
• 必填字段, 哪些可能没有填充历史数据, 必须非强制性执行, 但是对用户来说验证是敏感的, 从而允许来自迁移的数据为空值, 但是拒绝普通用户通过GUI输入的空值.
• 触发器, 特别是那些发送新记录到集成的人, 必须能够为数据迁移用户打开/关闭，以防止被迁移的数据淹没集成.

另一个技巧是在每个迁移对象中使用字段Legacy ID或Migration ID. 这有两个原因. The first is obvious: To keep the ID from the old system for backtracking; after the data is in the new system, 人们可能仍然想用旧的id来搜索他们的账户, 可以在电子邮件中找到, 文档, bug跟踪系统. 坏习惯? 也许. 但如果你保留了他们的旧id，用户会感谢你的. 第二个原因是技术上的，来自Salesforce不接受新记录显式提供的id(与Microsoft Dynamics不同)，而是在加载期间生成它们. 当我们想要加载子对象时，问题就出现了，因为我们必须为它们分配父对象的id. 因为我们只有在加载后才能知道这些id，所以这是徒劳的.

让我们使用帐户和他们的联系人，例如:

1. 为帐户生成数据.
2. 将Accounts加载到Salesforce中，并接收生成的id.
3. 在联系人数据中加入新的帐户id.
4. 为联系人生成数据.
5. 在Salesforce中加载联系人.

我们可以更简单地通过加载帐户及其存储在特殊外部字段中的遗留id来实现这一点. 该字段可以用作父引用, 所以当加载触点时, 我们简单地使用Account Legacy ID作为指向父帐户的指针:

1. 为account生成数据，包括Legacy ID.
2. 为联系人生成数据，包括Account Legacy ID.
3. 将帐户加载到Salesforce.
4. 在Salesforce中加载联系人，使用Account Legacy ID作为父引用.

这里的好处是我们将生成阶段和加载阶段分开了, 哪一种能提供更好的并行性, 减少停机时间, 等等......。.

8. 了解Salesforce的特定功能

像任何系统一样, Salesforce有很多棘手的部分，我们应该意识到这一点，以避免在数据迁移过程中出现令人不快的意外. 以下是一些例子:

• 活动用户的一些更改会自动生成电子邮件通知到用户的电子邮件. 因此, 如果我们想处理用户数据, 我们需要先停用用户，并在完成更改后激活. 在测试环境中，我们打乱用户的电子邮件，这样通知就不会被触发. 因为活跃用户消耗昂贵的许可证, 我们不可能让所有的用户在所有的测试环境中都处于活动状态. 我们必须管理活跃用户的子集, 例如, 在训练环境中激活它们.
• 不活跃用户, 用于一些标准对象，如Account或Case, 只有在授予系统权限“更新不活跃所有者的记录?,但它们是可以分配的, 例如, 到联系人和所有自定义对象.
• 当联系人被取消激活时，所有选择退出字段都被默默地打开.
• 加载重复的帐户团队成员或帐户共享对象时, 现有记录将被静默覆盖. 然而, 加载重复的机会伙伴时, 只是简单地添加记录，从而产生一个副本.
• 系统字段，如 创建日期, 由ID创建, 最后修改日期, 最后修改ID, “在记录创建时设置审计字段?.”
• 字段的历史值更改根本不能迁移.
• 在加载期间不能指定知识文章的所有者，但可以稍后更新.
• 棘手的部分是将内容(文档、附件)存储到Salesforce中. 有多种方法可以做到(使用附件), 文件, 饲料附件, 文档), 每种方法都有利弊, 包括不同的文件大小限制.
• Picklist字段强制用户选择允许的值之一，例如，帐户类型. 但是在加载数据时使用 Salesforce API (或在其上构建的任何工具，例如 顶点数据加载器 or Informatica Salesforce连接器), 任何 价值会传递.

这样的例子不胜枚举, 但最重要的是:熟悉这个系统, 在你做出假设之前，了解它能做什么，不能做什么. 不要假设标准行为，特别是对于核心对象. 经常研究和测试.

9. 不使用Salesforce作为数据迁移平台

使用Salesforce作为构建数据迁移解决方案的平台是非常诱人的, 特别是对于Salesforce开发人员. 用于数据迁移解决方案的技术与用于Salesforce应用程序定制的技术相同, 相同的GUI, 相同的 顶点编程语言，同样的基础设施. Salesforce有可以充当表的对象，还有一种SQL语言， Salesforce对象查询语言(SOQL). 然而, please do not use it; it would be a fundamental architectural flaw.

Salesforce是一个优秀的SaaS应用程序，有很多很好的特性, 例如高级协作和丰富的定制, 但大规模数据处理并不在其中. 三个最重要的原因是:

• 表演。 -在Salesforce中处理数据比在RDBMS中慢几个等级.
• 缺乏分析功能 - Salesforce SOQL不支持复杂的查询和分析功能 顶点 语言，并且会进一步降低性能.
• 体系结构* -将数据迁移平台放在特定的Salesforce环境中不是很方便. 通常, 我们有多种环境用于特定目的, 通常是特别创建的，这样我们就可以在代码同步上投入大量时间. +, 您还将依赖于特定Salesforce环境的连接性和可用性.

而不是, 使用RDBMS或ETL平台在单独的实例(可以是云或本地)中构建数据迁移解决方案. 将其与源系统连接，并以所需的Salesforce环境为目标, 将需要的数据移到临时区域并在那里进行处理. 这将允许您:

• 充分利用SQL语言或ETL特性的全部功能和能力.
• 将所有代码和数据放在一个地方，以便可以跨所有系统运行分析.
  • 例如, 您可以将来自最新测试Salesforce环境的最新配置与来自生产Salesforce环境的实际数据结合起来.
• 您不那么依赖于源系统和目标系统的技术，并且您可以在下一个项目中重用您的解决方案.

10. 监督Salesforce元数据

在项目开始时，我们通常获取Salesforce字段列表并开始映射练习. 项目期间, 应用程序开发团队经常将新字段添加到Salesforce中, 或者某些字段属性发生了变化. 我们可以要求应用程序团队将每次数据模型更改通知数据迁移团队, 但并不总是有效. 为了安全起见，我们需要将所有数据模型更改置于监督之下.

一种常见的方法是下载, 定期地, 将相关元数据从Salesforce迁移到某个元数据存储库. 一旦我们有了这个, 我们不仅可以检测数据模型中的变化, 但我们也可以比较两个Salesforce环境的数据模型.

下载什么元数据:

• 一个对象列表，包含它们的标签和技术名称以及属性，例如 创造性的 or 可更新的.
• 带有属性的字段列表(最好获得所有字段).
• picklist字段的picklist值列表. 我们将需要它们映射或验证输入数据的正确值.
• 验证列表，以确保新的验证不会对迁移的数据造成问题.

如何从Salesforce下载元数据? 嗯，没有标准的元数据方法，但有多种选择:

• 生成企业WSDL -在Salesforce web应用程序中导航到 设置/ API 菜单并下载强类型企业WSDL, 描述Salesforce中的所有对象和字段(但不包括选择列表值和验证).
• 电话销售团队 describeSObjects web服务，直接或通过使用Java或c#包装器(参见 Salesforce API). 这样，您就得到了所需的内容，这也是导出元数据的推荐方法.
• 使用互联网上众多可用的替代工具中的任何一个.

为下一次数据迁移做准备

云解决方案，如Salesforce，马上就准备好了. 如果您对内置功能感到满意，只需登录并使用它. 然而, Salesforce, 像任何其他云CRM解决方案一样, 为数据迁移主题带来需要注意的特定问题, 特别是, 关于性能和资源限制.

将遗留数据迁移到新系统中总是一个过程, 有时是隐藏在过去几年数据中的历史之旅. 在本文中, 基于十几个迁移项目, 关于如何迁移遗留数据并成功避免大多数陷阱，我给出了10个技巧.

关键是要理解数据揭示了什么. 因此，在开始数据迁移之前，请确保您的 Salesforce开发团队 是否为数据可能存在的潜在问题做好了充分准备.