做信创数据库替代，大部分用户会选择先易后难，先通过比较容易实现的系统的替代工作摸索替代工作路线，积累相关经验，这是一种比较稳妥的替代策略。

不过这种策略也有其局限性，首先是需要的时间会比较长。前期的探索需要较长时间来积累足够的经验。甚至有些时候，小型的，比较简单的小系统替代得很多了，解决大型关键系统替代所需的技术积累还没有完成。等到替代比较难的关键核心系统的时候，依然还像是在黑暗中摸索。最坏的情况是，很可能发现前面替代一些小系统所选择的数据库根本无法完成对核心系统的替代。另外因为前期探索方案所花的时间过长，留给较难的核心系统替代的时间已经很有限了，有时候就必须硬上了，这给核心系统替代带来巨大的不确定性。

基于上述考虑，有些企业在策略选择上选择先难后易，先核心后外围的策略。留下足够的时间进行核心攻关，一旦解决了较难的核心系统的问题，那么那些相对简单，重要性不是很高的小系统搞起来就比较容易了。另一方面，迁移复杂的关键系统所积累的经验，可能才是最为全面的。中国移动、太平洋保险等企业就是采用了这个数据库国产化替代策略。

这么看来，似乎先难后易是更好的选择，实际上也不尽然。每个企业都有自己的独特情况，技术能力、能够获得的资金支持和外部技术支持也相差甚大，因此不能一概而论。选择先难后易策略的企业首先要有能力进行相对靠谱的数据库选型，如果在选型阶段就选错了产品，那么后面的攻关就会面临死磕一个无法攻破的城堡的进退两难的境地。其次是企业必须拥有强大的技术能力，在对某个数据库比较陌生，几乎0经验的情况下攻克各种技术难题，光依靠原厂的支持是完全不够的，必须自身拥有强大的技术能力，亦或是有强大的第三方专家作为外援支撑。如果你一直觉得数据库原厂是给你兜底的，自己不构建一个能够为这件事兜底的研发与技术支撑体系，那么失败就是注定的。

如果系统是重建的，那么难度会降低很多，因为系统开发过程中，开发团队可以避开数据库本身的缺陷。如果我们干的是一个系统迁移的项目，那么其难度会倍增。因为我们不太确定迁移过来的代码中还有什么坑，在前期测试阶段虽然我们已经解决了很多问题，不过有些问题在前期测试时候不一定能够被发现，系统上线后发现一些极难解决的大问题也是很可能的。

遇到这些问题的时候，放弃原有的方案是不可能的，因为这是一条不能回头的路。要么快速找到解决方案让系统恢复正常，要么就会面临巨大的危机。此时对于技术团队的要求就很高了，他们必须有能力在几个小时内找到解决问题的办法，指望原厂出补丁来解决问题是不可能的。

这种情况下，双轨制运行机制就十分重要了。对于十分关键的核心系统迁移改造，一般会采用双轨制，也就是说国产数据库的数据会被全量复制回Oracle，如果主系统故障，则可以切回Oracle，让业务尽快恢复。随后我们有更多的时间去排查问题，寻找解决问题的办法。这种方法在某移动公司核心系统上线时就被成功使用了。