由于自己也遇到过类似问题，所以，看到这篇文章的时候 就更为观注，其实文章也没写什么，只是把自己的遇到的问题列了一下，但，能够引起共鸣的就是好文章 。
先贴原文，然后再把我的事情说一下：
项目已经进入数据割接测试一轮尾声，记得刚刚进入数据割接测试的阶段，大家都很茫然，让我们想起了当时数据准备阶段，这一幕又重现了，数据准备是因为数据 及其复杂，业务复杂，大家对其他人负责的业务不熟悉，导致数据准备成为一块绊脚石，然而开发人员都很忙，没有时间一起配合准备。而数据割接测试也同样面临 着类似问题，一方面业务及其复杂，新老系统的设计逻辑和数据结构有很大的差异。而我们大部分人对老系统不熟悉，参与割接的开发人员对新系统不熟悉，导致割 接测试困难重重。
刚开始我们采用的是把老系统线上的数据割接到新系统，然后我们选择几种典型业务按一定条件准备了一些用户，在新老系统中对比这些用户的数据。发现这这些用 户的记录不熟悉，用户的数据又比较乱，不是登录不了，就是密码不对，要不就是没有用户信息，要不就是不能发布宝贝，还要去修改相应的用户信息等等，这样准 备数据一天都快过去了进度很慢。后来大家提出用自己平时用的用户计划好场景，到日常中去构造一些数据，造好后再把这些用户给割接的人，让他们把相应的用户 数据增量割接过来。然后再用这些用户在新系统中做交易，看数据是否正确。另外备用一两个用户，在新系统中做同样的数据，进行比较。有些没办法构造的场景才 选用哪些已有的用户数据去查看。即自己构造的数据和上线上的数据互相弥补
这样做有几点好处：
首先自己构造的数据自己清楚，不用再去找这些用户数据。
其次自己平时用的用户，用户信息都是全的，能登录，能发宝贝，能做交易，能订购，不用再去修修补补，那怕是要修改，修改的地方也少点。
虽然这样一来有点进展，但是还是遇到了很大的麻烦，有很多数据割接过来完全错误，因为新老系统的数据结构很大的差异的问题，很多逻辑不对。而项目中的开发 忙于项目，完全不重视数据割接，后来我们建议新老系统开发人员和测试人员一起配合测试数据割接测试，保证数据的正确性。
针对以上出现的问题，个人觉得首先要保证迁移脚本的正确性，那最好是新老系统的开发人员配合编写脚本。万一项目中开发人员没时间，审核的时候要新老系统的开发人员要一起慎重审核脚本的逻辑。否则不能保证脚本的正确性，那更谈不上保证数据的正确性。
----以上为转贴，来源于：http://rdc.taobao.com/blog/qa/?p=4515
以前在XX公司的时候也遇到过，或者说，任何一个公司在新旧系统更换的时候，估计都会遇到吧？一般在这种情况下，最重要的是保留用户数据，毕竟如果没有用户，那网站也就没有存在的必要了。其次就是用户相关的数据，比如资料信息、历史、或者各种各样的操作。或许你会认为没有什么必要，但有的用户就喜欢翻旧事。前段时间在某群内看到有人把01、02年的贴子翻出来炫耀，以证明自己在某网站的年代长远。所以说，用户是奇怪的。
如果是电子商务的话，还得保证以前的订单和订单相关资料需要完全正确，否则，对谁来说都是一个损失。就象文章最后一段话，其实很多时候都是开发新系统的人在写迁移脚本，而这些人对于老系统并不熟悉，到最后，数据其实是模凌两可的，看上去正常就是皆大欢喜的事情了。其实也不是原始开发人员不做这些事，要知道，IT公司，跳槽情况非常常见，原始开发人员说不定几年前就跳槽了，越是老的公司，在初期的代码就越乱，越往后越感觉无法整合。迷惘中的新开发人员也只能跟着感觉走了。
HOHO