填充完新CRM应用程序的实际生产数据迁移通常发生在晚上或是周末，以便最大限度地减少对用户的影响。理想情况下，用户社区停止使用旧应用程序的时间是星期五的下午5点，而当地他们下周一早上 重新开始工作时，他们就开始使用新CRM应用程序了，而且会发现他们的数据已经全部完成迁移；他们可以专注于加快使用新应用程序，而无需费心输入数据了。

      在这种“理想的”数据迁移模式中，周五的下午5点成为旧应用程序的“终止点”。如果可能的话，整个应用程序将在此时被转换为“只读”模式，并提取数据准备迁移。迁移过程与伪迁移流程的步骤相同。还需要进行查询和点测试，以确保迁移过程的成功完成。

      你可能已经想到，许多CRM数据迁移工作并不遵循在这种简单的模式，你自己特定的迁移工作将会有自己的日程安排和程序。

      1、数据迁移的日程安排

      除了表示数据迁移过程的最终测试和确定流程是否可以继续进行，伪迁移还提供了一个至关重要的信息，即迁移过程所花的时间。

      理想情况下，迁移过程应该在一个标准的休息时间段内完成，如一个晚上或一个周末。否则的话，公司得停工一段时间，以提供足够的时间来执行迁移。如果公司无法停工，数据迁移工作通常就被分割成几个部分，以使得用户在不停工的情况下去仍然可以高效地工作。例如，对于实际的数据迁移，一种方法是只迁移去年的数据，然后在每次连续的非工作时间逐步迁移更老的数据，直至完成全部数据迁移，而不是一次性迁移客户5年的全部活动数据。

      2、脚本

     为了成功地完成迁移，数据迁移计划中就要包含开发详细的脚本或一系列按照精确的顺序执行的任务。脚本是在数据迁移过程的技术开发阶段创建和完善的，并且通过伪迁移进行验证。为了发挥伪迁移的价值，实际的数据迁移必须与伪迁移使用相同的脚本并用相同的方式执行。

     数据迁移总结和主要教训

     以下是主要教训

     数据迁移是大多数CRM项目的重要组成部分，它可能有极大的价值，但是，除非它被证实能够产生足够的业务价值，否则不应该纳入迁移过程中。它可能难度大、成本高而且不精确。

     你可能听过一个关于数据迁移的常用说法：“进来的是垃圾，出去的也是垃圾。”数据迁移无法神奇地清理和标准化数据，也无法防止数据的重复；如果源应用程序在质量问题，数据迁移会将这些问题原封不动地移入CRM应用程序中。

     不要将测试数据迁移的工作外包给咨询合作伙伴；他们不了解数据及其上下文环境，也不清楚源应用程序，当情况“看起来不对”时，他们无法轻易地识别问题。因此要确保你的团队参与其中。