迁移旧数据而不用担心

本文概述

• 一般数据迁移
• Salesforce数据迁移
• 10.监督Salesforce元数据
• 准备下一次数据迁移

迁移旧数据非常困难。

许多组织都有旧的, 复杂的本地业务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.旨在实现自动迁移解决方案

数据迁移通常被视为一次性活动, 并且开发人员倾向于最终获得充满手动操作的解决方案, 希望仅执行一次。但是有很多理由避免使用这种方法。

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

因此, 即使迁移本质上是一次性的活动, 执行手动操作也会大大减慢你的操作速度。

Salesforce数据迁移

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

6.准备长时间的负荷

从本地部署到云解决方案时, 性能是(即使不是最大的)折衷之一-不排除Salesforce。

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

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

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

结果, 负载性能可以达到每小时数千个帐户。

取决于事物, 例如字段数, 验证和触发器, 它可以更少也可以更多。但这比直接数据库加载要慢几个等级。

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

它是由基础RDBMS(Oracle)中用于检查外键, 唯一字段和评估复制规则的索引引起的。基本公式是每10年级降低约50％的速度, 这是由O(logN)排序和B树操作中的时间复杂度部分引起的。

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

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

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

在实际的项目中, 由于使用(例如)自定义触发器时, 批次数量有限, 最大值要低得多。

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

即使对于中型数据集(从100, 000个帐户到100万个帐户), 大爆炸方法也不可行, 因此我们必须将数据分成较小的迁移波。

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

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

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

如果所有用户都位于一个国家/地区, 我们可以在夜间利用八小时的停机时间。

但是, 对于可口可乐这样在世界各地开展业务的公司而言, 这是不可能的。系统中包含美国, 日本和欧洲后, 我们将覆盖所有时区, 因此星期六是唯一不会影响用户的中断选项。

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

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

诸如验证和触发器之类的应用程序组件应该能够处理数据迁移活动。如果系统必须在线, 则在迁移负载时强制禁用验证是不可行的。相反, 我们必须为数据迁移用户执行的更改实施不同的逻辑验证。

• 日期字段不应与实际系统日期进行比较, 因为这会禁止加载历史数据。例如, 验证必须允许输入迁移数据的过去帐户开始日期。
• 强制字段(可能未填充历史数据)必须实现为非强制性, 但必须对用户敏感, 验证有效, 因此允许来自迁移的数据为空值, 但拒绝来自常规用户通过GUI来的空值。
• 触发器, 尤其是那些向集成发送新记录的触发器, 必须能够为数据迁移用户打开/关闭, 以防止集成中充斥着迁移的数据。

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

让我们使用”帐户”及其”联系人”, 例如：

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

我们可以通过将帐户的旧版ID加载到特殊外部字段中来加载帐户, 从而更轻松地完成此操作。该字段可以用作父级引用, 因此在加载”联系人”时, 我们仅使用Account Legacy ID作为指向父级Account的指针：

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

这里的好处是, 我们已经将生成阶段和加载阶段分开了, 这可以实现更好的并行性, 减少中断时间, 等等。

8.注意Salesforce的特定功能

像任何系统一样, Salesforce有很多棘手的部分, 我们应该注意这些部分, 以避免在数据迁移期间出现令人不快的意外情况。以下是一些示例：

• 对活动用户的一些更改会自动为用户电子邮件生成电子邮件通知。因此, 如果要使用用户数据, 则需要先停用用户, 然后在更改完成后激活。在测试环境中, 我们对用户电子邮件进行加扰, 以便根本不会触发通知。由于活动用户消耗昂贵的许可证, 因此我们无法让所有用户在所有测试环境中均处于活动状态。例如, 我们必须管理活动用户的子集, 以仅激活培训环境中的用户。
• 对于某些标准对象(例如客户或案例), 只有在授予系统权限”使用不活动的所有者更新记录”之后才能分配不活动的用户, 但是可以将其分配给例如联系人和所有自定义对象。
• 停用”联系人”后, 所有”退出”字段均会静默打开。
• 加载重复的客户团队成员或客户共享对象时, 现有记录将被静默覆盖。但是, 在加载重复的机会合作伙伴时, 仅添加记录即可重复。
• 只有在授予新的系统权限”创建记录时设置审核字段”之后, 才能显式写入系统字段, 例如创建日期, 创建者ID, 上次修改日期, 上次修改者ID。
• 字段历史值的更改根本无法迁移。
• 加载期间无法指定知识文章的所有者, 但以后可以更新。
• 棘手的部分是将内容(文档, 附件)存储到Salesforce中。有多种方法(使用附件, 文件, 提要附件, 文档), 每种方法各有利弊, 包括不同的文件大小限制。
• “选择列表”字段会强制用户选择允许的值之一, 例如帐户类型。但是, 当使用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环境的数据模型。

要下载什么元数据：

• 带有标签, 技术名称和属性(例如可创建或可更新)的对象列表。
• 具有其属性的字段列表(最好获取所有属性)。
• 选取列表字段的选取列表值的列表。我们将需要它们映射或验证输入数据以获取正确的值。
• 验证列表, 以确保新的验证不会对迁移的数据造成问题。

如何从Salesforce下载元数据？嗯, 没有标准的元数据方法, 但是有多个选项：

• 生成企业WSDL –在Salesforce Web应用程序中, 导航到”设置/ API”菜单, 并下载强类型的企业WSDL, 该WSDL描述了Salesforce中的所有对象和字段(但不包括选择列表值或验证)。
• 直接或通过使用Java或C＃包装器(咨询Salesforce API), 调用Salesforce describeSObjects Web服务。这样, 你将获得所需的内容, 这是导出元数据的推荐方法。
• 使用互联网上可用的众多替代工具中的任何一种。

准备下一次数据迁移

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

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

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

相关：陷入关系数据库的数据分析师的HDFS教程