迁移遗留数据而不搞砸

迁移遗留数据很困难。

许多组织拥有陈旧而复杂的本地业务 CRM 系统。 今天，有很多云 SaaS 替代方案，它们带来了很多好处； 随用随付，只为您使用的东西付费。 因此，他们决定迁移到新系统。

没有人愿意将有关客户的宝贵数据留在旧系统中并从空的新系统开始，因此我们需要迁移这些数据。 不幸的是，数据迁移并非易事，因为数据迁移活动消耗了大约 50% 的部署工作。 据 Gartner 称，Salesforce 是云 CRM 解决方案的领导者。 因此，数据迁移是 Salesforce 部署的一个主要话题。

那么，我们如何确保将遗留数据成功转换为闪亮的新系统，并确保我们将保留其所有历史记录？ 在本文中，我提供了成功进行数据迁移的 10 个技巧。 前五个技巧适用于任何数据迁移，无论使用何种技术。

一般数据迁移

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

在软件部署清单中，数据迁移不是由智能的“一键式”数据迁移工具处理的“导出和导入”项目，该工具已为目标系统预定义映射。

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

数据迁移方法定义了我们是一次性加载数据（也称为大爆炸），还是每周加载小批量数据。

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

2. 实际估计

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

例如，为训练目的加载特定数据集，其中包含大量真实数据，但敏感项目被混淆，因此训练活动不会向客户生成电子邮件通知。

估计的基本因素是要从源系统传输到目标系统的字段数。

每个字段在项目的不同阶段都需要一些时间，包括了解字段、将源字段映射到目标字段、配置或构建转换、执行测试、测量字段的数据质量等。

使用智能工具，例如 Jitterbit、Informatica Cloud Data Wizard、Starfish ETL、Midas 等，可以减少此时间，尤其是在构建阶段。

特别是，了解源数据——任何迁移项目中最关键的任务——不能通过工具自动化，而是需要分析师花时间逐个浏览字段列表。

对整体工作量的最简单估计是从遗留系统转移的每个领域需要一个人日。

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

详细的估算本身就是一门艺术。

3.检查数据质量

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

新系统有新规则，旧数据可能会违反这些规则。 这是一个简单的例子。 在新系统中，联系电子邮件可能是强制性的，但 20 年历史的旧系统可能有不同的观点。

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

数据质量显着影响工作量，简单的规则是：我们走得越远，我们就会发现更大的混乱。 因此，尽早决定我们希望将多少历史转移到新系统中至关重要。

4. 吸引商务人士

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

在映射练习中让业务团队中的某个人参与非常重要，对于未来的回溯，记录映射决策及其原因很有用。

既然一张图值一千多字，那就在新系统中加载一个测试批次，让业务团队来玩。

即使数据迁移映射得到业务团队的审核和批准，一旦数据显示在新系统的 UI 中，也会出现意外。

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

未能聘请通常非常忙碌的主题专家是新系统上线后出现问题的最常见原因。

5.瞄准自动化迁移解决方案

数据迁移通常被视为一次性活动，开发人员最终往往会得到充满手动操作的解决方案，希望只执行一次。 但是有很多理由可以避免这种方法。

• 如果迁移分为多个波，我们必须多次重复相同的操作。
• 通常，每一波至少有 3 次迁移运行：用于测试数据迁移性能和功能的试运行，用于测试整个数据集和执行业务测试的完整数据验证负载，当然还有生产负载。 运行次数随着数据质量差而增加。 提高数据质量是一个迭代过程，因此我们需要多次迭代才能达到预期的成功率。

因此，即使迁移本质上是一次性活动，手动操作也会显着减慢您的操作。

Salesforce 数据迁移

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

6. 为长时间的负载做准备

从内部部署迁移到云解决方案时，性能是（如果不是最大的话）权衡之一——不排除 Salesforce。

本地系统通常允许将数据直接加载到底层数据库中，并且借助良好的硬件，我们可以轻松地达到每小时数百万条记录。

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

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

因此，负载性能可能是每小时数千个帐户。

它可以更少，也可以更多，具体取决于字段、验证和触发器的数量。 但它比直接加载数据库要慢几个等级。

还必须考虑性能下降，这取决于 Salesforce 中的数据量。

它是由用于检查外键、唯一字段和重复规则评估的底层 RDBMS (Oracle) 中的索引引起的。 基本公式是每 10 级减速大约 50%，这是由 O(logN) 排序和 B 树操作中的时间复杂度部分引起的。

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

其中之一是将批量 API 限制设置为 24 小时滚动窗口中的 5,000 个批次，每批次最多 10,000 条记录。

因此，理论上的最大值是 24 小时内加载 5000 万条记录。

在实际项目中，由于使用自定义触发器等有限的批处理大小，最大值要低得多。

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

即使对于中等规模的数据集（从 100,000 到 100 万个账户），大爆炸方法也是不可能的，因此我们必须将数据拆分为更小的迁移波。

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

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

此外，冗长的负载可能意味着我们无法在系统中断期间执行迁移。

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

但对于像可口可乐这样业务遍布全球的公司来说，这是不可能的。 一旦我们在系统中有美国、日本和欧洲，我们就会跨越所有时区，所以星期六是唯一不影响用户的中断选项。

这可能还不够，因此，我们必须在用户使用系统时在线加载。

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

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

• 不应将日期字段与实际系统日期进行比较，因为这会禁用历史数据的加载。 例如，验证必须允许输入迁移数据的过去帐户开始日期。
• 强制字段，可能不会填充历史数据，必须作为非强制实施，但验证对用户敏感，因此允许来自迁移的数据为空值，但拒绝来自普通用户通过 GUI 提供的空值.
• 触发器，尤其是那些向集成发送新记录的触发器，必须能够为数据迁移用户打开/关闭，以防止迁移数据淹没集成。

另一个技巧是在每个迁移对象中使用字段 Legacy ID 或 Migration ID。 有两个原因。 第一个很明显：保留旧系统的ID以进行回溯； 在数据进入新系统后，人们可能仍希望使用旧 ID 搜索他们的帐户，这些旧 ID 可以在电子邮件、文档和错误跟踪系统等地方找到。 坏习惯？ 可能是。 但是，如果您保留他们的旧 ID，用户会感谢您。 第二个原因是技术性的，因为 Salesforce 不接受为新记录明确提供的 ID（与 Microsoft Dynamics 不同），而是在加载期间生成它们。 当我们想要加载子对象时会出现问题，因为我们必须为它们分配父对象的 ID。 由于我们只有在加载后才能知道这些 ID，所以这是徒劳的。

让我们使用 Accounts 和他们的 Contacts，例如：

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

我们可以通过加载具有存储在特殊外部字段中的 Legacy ID 的帐户来更简单地做到这一点。 该字段可以用作父级引用，因此在加载联系人时，我们只需使用 Account Legacy ID 作为指向父级 Account 的指针：

1. 为客户生成数据，包括旧版 ID。
2. 为联系人生成数据，包括 Account Legacy ID。
3. 将客户加载到 Salesforce。
4. 在 Salesforce 中加载联系人，使用 Account Legacy ID 作为父参考。

这里的好处是我们将生成阶段和加载阶段分开，这允许更好的并行性，减少中断时间等等。

8. 了解 Salesforce 的特定功能

与任何系统一样，Salesforce 有很多我们应该注意的棘手部分，以避免在数据迁移过程中出现令人不快的意外。 这里有几个例子：

• 对活动用户的一些更改会自动为用户电子邮件生成电子邮件通知。 因此，如果我们想玩用户数据，我们需要先停用用户，并在更改完成后激活。 在测试环境中，我们会打乱用户电子邮件，以便根本不会触发通知。 由于活跃用户使用昂贵的许可证，我们无法让所有用户在所有测试环境中都活跃。 我们必须管理活跃用户的子集，例如，仅激活培训环境中的用户。
• 对于某些标准对象（例如客户或案例），非活动用户只能在授予系统权限“使用非活动所有者更新记录”后分配，但可以将它们分配给例如联系人和所有自定义对象。
• 当联系人被停用时，所有退出字段都会静默打开。
• 加载重复的客户团队成员或客户共享对象时，现有记录将被静默覆盖。 但是，当加载重复的商机合作伙伴时，只会添加记录，从而导致重复。
• 系统字段，例如Created Date 、 Created By ID 、 Last Modified Date 、 Last Modified By ID ，只有在授予新的系统权限“创建记录时设置审计字段”后才能显式写入。
• 字段历史值更改根本无法迁移。
• 知识文章的所有者不能在加载期间指定，但可以稍后更新。
• 棘手的部分是将内容（文档、附件）存储到 Salesforce 中。 有多种方法可以做到这一点（使用附件、文件、Feed 附件、文档），每种方法都有其优点和缺点，包括不同的文件大小限制。
• 选项列表字段强制用户选择一个允许的值，例如，一种帐户。 但是，当使用 Salesforce API（或任何基于它的工具，例如 Apex Data Loader 或 Informatica Salesforce 连接器）加载数据时，任何值都会传递。

清单还在继续，但底线是：熟悉系统，在做出假设之前了解它可以做什么和不能做什么。 不要假设标准行为，尤其是对于核心对象。 始终研究和测试。

9. 不要将 Salesforce 用作数据迁移平台

使用 Salesforce 作为构建数据迁移解决方案的平台非常诱人，尤其是对于 Salesforce 开发人员而言。 数据迁移解决方案的技术与 Salesforce 应用程序定制的技术、相同的 GUI、相同的 Apex 编程语言、相同的基础架构相同。 Salesforce 具有可以充当表格的对象，以及一种 SQL 语言，即 Salesforce 对象查询语言 (SOQL)。 但是，请不要使用它； 这将是一个基本的架构缺陷。

Salesforce 是一款出色的 SaaS 应用程序，具有许多不错的功能，例如高级协作和丰富的自定义功能，但数据的海量处理不是其中之一。 三个最重要的原因是：

• 性能——Salesforce 中的数据处理比 RDBMS 慢几个等级。
• 缺乏分析功能——Salesforce SOQL 不支持 Apex 语言必须支持的复杂查询和分析功能，并且会进一步降低性能。
• 架构* – 将数据迁移平台放在特定的 Salesforce 环境中不是很方便。 通常，我们有多个用于特定目的的环境，通常是临时创建的，以便我们可以将大量时间用于代码同步。 此外，您还将依赖特定 Salesforce 环境的连接性和可用性。

相反，使用 RDBMS 或 ETL 平台在单独的实例（可以是云或本地）中构建数据迁移解决方案。 将其与源系统连接并定位您想要的 Salesforce 环境，将您需要的数据移动到您的暂存区域并在那里进行处理。 这将允许您：

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

10. 监督 Salesforce 元数据

在项目开始时，我们通常会获取 Salesforce 字段列表并开始映射练习。 在项目期间，经常会发生应用程序开发团队向 Salesforce 添加新字段，或者更改某些字段属性的情况。 我们可以要求应用程序团队将每次数据模型更改通知数据迁移团队，但并不总是有效。 为了安全起见，我们需要对所有数据模型的更改进行监督。

执行此操作的常用方法是定期将与迁移相关的元数据从 Salesforce 下载到某个元数据存储库中。 一旦有了这个，我们不仅可以检测数据模型的变化，还可以比较两个 Salesforce 环境的数据模型。

要下载哪些元数据：

• 带有标签和技术名称以及属性的对象列表，例如creatable或updatable 。
• 具有属性的字段列表（最好获取所有属性）。
• 选项列表字段的选项列表值列表。 我们将需要它们映射或验证输入数据的正确值。
• 验证列表，以确保新验证不会对迁移的数据造成问题。

如何从 Salesforce 下载元数据？ 好吧，没有标准的元数据方法，但有多种选择：

• 生成企业 WSDL——在 Salesforce Web 应用程序中导航到Setup / API菜单并下载强类型企业 WSDL，它描述了 Salesforce 中的所有对象和字段（但不是选项列表值或验证）。
• 直接或使用 Java 或 C# 包装器调用 Salesforce describeSObjects Web 服务（请参阅 Salesforce API）。 这样，您就可以获得所需的内容，这是导出元数据的推荐方式。
• 使用互联网上提供的众多替代工具中的任何一种。

准备下一次数据迁移

Salesforce 等云解决方案可立即准备就绪。 如果您对内置功能感到满意，只需登录并使用它。 但是，与任何其他云 CRM 解决方案一样，Salesforce 给数据迁移主题带来了需要注意的特定问题，特别是在性能和​​资源限制方面。

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

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