数据迁移-危险还是必要？

我公司的软件开发部门面临着这样一个问题，即数据迁移被认为具有潜在的危险，特别是对我的经理们而言。

背景是我们的客户正在使用大量质量较差的数据。这样做的原因只是部分地涉及到我们的软件质量，而是数据的历史：他们中的大多数已经从原有系统迁移，引起的（主要是企业）的一些错误不一致的数据记录或misentries通过对事故客户方（我们的软件允许的错误）。

我的经理最重要的反对意见是，错误的数据可能会变成更差的数据，数据问题可能使客户的某些经理醒来，而客户方面的某些流程可能不再起作用，因为他们的流程在某种程度上适应了我们的系统。

就个人而言，我认为数据迁移是软件开发的组成部分，并且可以看到数据迁移对数据的重构是对代码的理解。我认为，数据迁移对于创建不断发展的软件至关重要。没有它，我们将不得不创建痛苦的软件，该软件在某种程度上可以解决不良的数据结构。

我在问你：

• 您对数据迁移有何想法，尤其是对于现实生活中的情况，而不仅仅是从开发人员的角度来看？
• 您对我的经理意见有异议吗？
• 贵公司如何应对数据迁移及其带来的困难？
• 还有其他有趣的想法属于这个主题吗？

数据迁移是我的生计，数据清理确实是一个非常重要的事情。我们使用的一种确实迁移100％客户数据的策略是渐近数据清洗预迁移工具。

1. 这意味着要开发数十个数据完整性检查（主要是sql查询）。

2. 与客户交换清洁工具（由于这是他的数据，因此我们设计了修补实用程序，由他验证并执行它们）。

3. 通过迭代完善工具，并尽快达到KPI支持的可测量质量。

4. 迁移后检查数据一致性。这有助于在D日做出GO / NOGO决策。

最后，数据迁移是一项非常有益的工作，必须在3到5年后进行。

1. 它可以增强平台支持业务的能力。

2. 它可以简化数据库。

3. 它为下一代业务工具（ESB / EAI，门户，自助式平台，报告和数据挖掘，为您命名）准备了IT平台。

4. 它重组了多年以来积累的平台之间的DIY数据流，这种快速而肮脏的“临时”方式可以满足“紧急需求”。

5. 最重要的是，它使IT生产团队能够更好地了解其平台并培养“可以做”的态度。这些好处很难衡量，但是当您认识很多客户时，这种考虑就变得很明显。避开迁移的公司仍处于下一层，大胆的领先。

这有点像房子的地下室里堆满了木材。一天早晨，您必须将所有东西都拿出来，只放回您需要的东西，其余的扔掉。之后，您可以再次使用地下室;-)

另一个基本考虑因素是，如今，客户期望始终在变化，就像“客户总是要求更高”一样。因此，在寻找这些新趋势的过程中，总是会有相当一部分的给定公司的竞争对手关注这些明显的趋势，以增加其市场份额。他们这样做的方式是通过调整其产品以适应趋势，甚至驱动趋势，这需要不断进行业务重组。如果您的IT平台过于僵化，将不利于您自己配偶或先行于市场趋势，最终维护自己的市场份额。换句话说，在不断变化的市场中，惯性是不相干的秘诀。

相比之下，将数据迁移到较新的系统将推出更现代，功能更广泛的生产力工具，使最好的新技术对员工更具吸引力，这反过来将有助于支持甚至领导公司的内部创新流程，从而确保或增加其相对市场份额。

以上考虑实际上仅回答了标题为“数据迁移-危险或必要”的一半问题。是的，数据迁移是必不可少的，但是它们也很危险吗？因此，IT中的许多事情都是危险的。根据定义，任何风险很高的事情都是危险的。特别是如果您不认真对待此事。但这实际上是 IT中最常见的模式。不重视数据中心或高可用性或容灾能力是很危险的。
这是否意味着当今的公司应该退出当今信息技术领域的这些支柱？当然不是！

为了开玩笑地说，您可以说“如果不使用专业人士制造的飞机，飞行是危险的”。数据迁移也是如此。由专业人员执行和执行，这比在设计合理且操作良好的飞机上飞行更危险。与陆地运输方式相比，ROI所占比例相同。
当委托给专业人员时，大多数迁移都可以很好地控制成功，并且失败+放弃率极低。

应该让您的经理问自己：“尽管大多数公司都成功地进行了数据迁移项目，但是，这将使我们的公司如此与众不同，以至于它会遭受失败？如果没有一家，它会表现得很好吗？”

对于成功完成数据迁移项目的数据清理的重要性以及进行数据迁移的基本原理，Alain给出了很好的答案。我只想针对您的经理的特定关注。

在我看来，这不是是否进行数据迁移的问题，而是有关何时进行数据迁移的问题。您的经理绝对有道理地说，您的数据已不再是您的数据了，最终客户已经围绕它建立了程序。但是这种状态将来不会改变。迟早的数据质量差将成为降低业务速度的必然因素，并且您将被迫进行迁移。在压力和紧迫的期限内执行此操作可能会导致决策不理想。此外，请考虑一下您现在拥有的专业知识，以及从现在起的2-3年内将拥有的专业知识。如果了解您数据的人将离开公司怎么办？您确定所拥有的文件足够吗？

也许现在没有必要进行迁移，但是您的经理至少需要对何时进行精确迁移有一个愿景。

我曾在一家保险公司工作，参与核心系统的数据迁移。好吧，总共有4次。所以，这是我的评论：

在我的情况下，数据迁移是必须的，因为根据法规，我们必须将数据保留至少10年，并且我们无法长期支持双系统。另一个原因是用户希望他们可以继续使用新应用程序。如果他们找不到他们工作的项目，则您的应用程序很糟糕，如果数据不正确，则情况甚至更糟。

好吧，数据迁移是一个可怕的野兽，它是真实的，所以面对它。这是有风险的，但是可以通过更早，更仔细地解决它，将其最小化。作为指导，在数据迁移中应考虑四个大过程：

1. 数据映射。母版（及其组合）到新系统的地图
2. 数据清理。数据中的异常映射，即，其组合在新系统上被视为无效的数据。如果可能，请处理业务以排除无法映射的数据并可能破坏新系统，并准备解决方法
3. 实际数据迁移。有许多执行数据迁移的策略。例如：大爆炸，增量
4. 报告合并。两个系统应并行运行，如何生成正确且一致的报告

精心策划的活动，狗屎发生！一个特别工作组应准备好处理与移民有关的问题。

1）您对数据迁移有何想法，尤其是对于现实生活中的情况，而不仅限于开发人员的观点？：

迁移是系统开发的重要组成部分。如果您部分或全部替换旧系统，则无论管理层是否愿意，迁移都是生活中不可或缺的事实。如果现有数据不正确，它将严重影响您的新系统。因此，拥有一个良好的迁移策略非常重要。

2）您对我的经理意见有异议吗？

是的，迁移是有风险的，但这也是生活中的事实，因此，应对它。并尽早处理。

3）贵公司如何处理数据迁移及其带来的困难？

我的公司已经-随着成功的增加，使客户积极地参与了迁移过程。我们在项目的开始阶段就尽力审查现有数据，并鼓励客户在开始迁移之前提高数据质量。有时我们实际上需要它。

4：属于该主题的其他有趣的想法

我的建议是将迁移过程分为两个步骤：转换和数据清理。转换非常简单-将旧系统对象映射到新系统。另一方面，数据清理可能是一件非常棘手的事情（如上所述）。尽可能让客户参与其中，并尽早启动流程。请记住，不良数据会严重影响您的新系统-有时完全是毫无道理的。当新系统无法正常工作时，客户很少会指责似乎在旧系统中正常工作的数据。

如果您计划迁移的数据当前不正确，则无论是否进行迁移，都需要对其进行修复。坏数据=无用数据。

迁移是有风险的，这是事实。但是每个主要的IT项目也是如此。有很多方法可以降低风险，因此一定要在迁移中预先计划好它们。

首先，您应该始终有办法回到现在的系统。第二次迁移应在仅为迁移而设置的测试服务器上进行。不能先进行测试就进行迁移是愚蠢的。第三，所有用于迁移的代码都应在源代码控制中。

第四，在开始迁移之前，您需要需求和测试计划。您需要知道，如果旧系统中有1,293,687条记录，那么新系统中也有相同记录，或者您知道它们去了哪里（也许到了异常表中）。如果要规范化非规范化方案，则需要在开始之前计算最终应存储多少条记录，然后进行检查。您需要说明从一个系统到另一个系统的映射是什么的文档。这将帮助您的质量检查人员检查数据是否正确。

您需要确定如何处理当前的不良数据。可以清除的内容，在必填字段中需要显示“未知”的值，应该扔到异常表中的内容，需要一组用户手动干预的内容（确定这两个人是否是真正的重复者或例如，该实践中是否有两位医生的名字相同，并且如果这是重复的，则当两个记录不同时可以选择哪些数据，等等。

成功迁移的关键是计划。我发现计划（包括编写测试用例和单元测试）通常比实际开发花费更多的时间。

成功进行数据迁移的下一个关键是质量保证。这不是在发布前一天就交给质量检查小组的项目。当质量检查人员说存在问题时，这不是要启动的项目。

成功迁移的另一个关键是在原始系统仍在运行时部署大多数数据并对其进行测试。如果要移动大量记录，这可能会很耗时，并且会发生新的更改。因此，在迁移开始之后，您的流程也必须能够提取数据更改。例如，SQL Server具有一个名为“更改数据捕获”的功能，可以对此提供帮助。您可以备份原始系统并同时打开更改数据捕获。然后，您可以将备份重新分配到迁移服务器，测试迁移，获取大部分已加载的数据，然后只需加载已更改的记录。迁移最终记录时，请关闭源系统，直到迁移完成。这是提前迁移大多数记录的原因之一，因此应用程序停机的时间最少。选择好您的迁移时间，不要在他们应该处理薪水或发出W2的那一天关闭薪水系统。并在使用时间少的时候做到这一点。如果您有多个客户端，则可以考虑先迁移一个，然后再进行其他操作，确保一切都很好。如果有问题，回滚一个客户的数据要比10000容易得多。但是，如果要这样做，请仔细计划。如果有问题，则s的数据大于10000。但是，如果要这样做，请仔细计划。如果有问题，则s的数据大于10000。但是，如果要这样做，请仔细计划。

如果迁移涉及新的用户界面，请让实际用户使用它作为迁移测试的一部分。然后在上线之前培训其他用户（但上线不到一周，否则他们会忘记）。让参与测试的用户帮助设计培训，他们知道他们有什么问题，人们需要以什么顺序知道什么。获取他们的输入，将其设为必填字段，因为您认为如果用户在输入记录时通常没有该数据，那将无济于事。他们只会将垃圾放入新要求的字段中，因为否则将无法获取数据。

查看当前数据出了什么问题，可以在应用程序中添加外键，约束，触发器，业务规则，默认值等，以免将来造成不良后果吗？当您清除不良数据时，还需要创建一种方法来避免将来出现类似的不良数据。分析为什么分配不良数据并修复设计中的漏洞。

数据迁移是必需的。没有数据迁移，您通常无法前进。我使用所需历史记录的许多系统只能从以前的系统中获得。迁移是唯一可行的方法。数据质量通常是一个问题。通常，这应该在现有系统中处理。这可能需要更改数据以恢复质量。

我使用过的其他系统取决于其他系统的数据。这是一个不同但重要的问题。在某些情况下，数据可以完全替换。通过将新数据中包含的更改合并到现有集中，可以更好地处理其他情况。这些迁移类型应包括对传入提要的有效性检查。

验证和清除现有数据的能力可能是系统的重要功能。这与迁移无关。通常存在修改系统控制范围之外的数据的机制。这可能导致数据无效。其他数据问题是由应用程序中的错误引起的。定期运行验证例程可以帮助识别问题并允许在迁移之前清除数据。如前所述，尽早清除数据可以使迁移更加容易。

某些验证是时间敏感的，不应应用于未修改的数据。这对于已淘汰编码的编码值很常见。应该可以在不触发验证错误的情况下更改记录中的其他字段。这可能会使更新验证更加复杂，因为它需要在验证之前确定哪些字段已更改。跨场验证也可能更复杂。在这种情况下，将某些记录视为只读的功能会有所帮助，因为可以避免进行验证。

在我工作的一个I系统上，新系统被客户部分拒绝。他们拒绝允许使用新的数据输入模块。但是，他们希望从新系统进行批处理。解决方案是在批处理运行之前每晚迁移数据。

这是必要的邪恶。我一直在两端，这些都是使问题复杂化的其他一些问题。

1. 特别是在企业中，当公司使用新系统时，他们希望它能够完成旧系统所做的所有工作。他们不审查他们的程序。他们不知所措，只想继续做同样的事情。这对他们是安全的。
2. 他们无需花时间学习新系统或雇用具有专业知识的人员。
3. 他们希望自定义新系统以适应＃1或处理其业务的一些新方面。新系统X定制X转换后的数据=复合的复杂性
4. 没有足够的时间用于测试。
5. 客户讨厌并行运行/做两次事情。不能责怪用户，因为他们没有其他时间履行职责，因为他们的所有其他职责都被全力以赴。

如果您的经理可以通过不转换数据来弥补销售损失的合理性，则可以为他们提供更多的权力。告诉您的客户所有数据转换都失败了，因为别人总是会告诉他们这样做（通常是您的竞争）。

您对数据迁移有何想法，尤其是对于现实生活中的情况，而不仅仅是从开发人员的角度来看？

软件必须定期升级。为了确保保存迁移，您需要备份和测试。

您对我的经理意见有异议吗？

他是有风险的，这是正确的。但是您可以调整技术以降低风险。

贵公司如何应对数据迁移及其带来的困难？

我们有每日备份，增量备份，每次部署到生产之前的备份。如果发生任何不良情况，至少可以让您回滚。

我们有测试环境，自动化测试和每日构建服务器。还要进行烟雾测试程序，以确保主要操作和功能正常运行。我们邀请开发人员，质量检查人员和用户来测试构建（已迁移数据）。

我们正在使用ruby on rails，它提供了数据迁移，升级和回滚的版本控制。这使我们的生活更轻松。

我们正在使用capistrano执行代码更新和数据迁移。确保迁移自动化和简单是确保生产系统正常工作的关键之一。

还有其他有趣的想法属于这个主题吗？

关于我的数据迁移的另一个问题是代码升级和数据迁移的一致性。以我为例，我们再次使用自动化的方式来处理该问题。并随时准备回滚。

手动执行数据迁移可能会使数据库变成未知状态。并且很难比较不同服务器环境之间的数据迁移版本。

希望能帮助到你。

我们不会浪费时间尝试从旧的旧系统迁移数据，因为时间，投资和风险都太高了。我们只是采用更新的系统而已，并在必要时进行集成。

每个企业都有必须支持的某种形式的遗留系统，这只是正常的经营成本。

考虑到迁移的成本，您的经理希望实现的回报最好很高。