为解决迁移中 “应用兼容性问题” 对业务逻辑、应用代码的改造，有哪几种方案可供选择？

应用程序在从 Oracle、DB2 迁移至 MySQL、PG时，由于传统数据库与应用的耦合度较高，大部分业务逻辑或多或少的使用了数据库的独特特性来实现，这大大增加了迁移过程中解决兼容性进行的代码改造工作量。
例如：
1）SQL语法的兼容性改造
2）PL/SQL对象（存储过程、自定义函数）的迁移改造
3）引用内置函数、内置变量、Oracle数据字典的代码改造
4）DB2、Oracle 时态表涉及的应用逻辑改写
等等 。。。

为了实现应用代码的改造，我知道的有 “双核心方案”、“中间件路由方案”。

“双核心方案”：
张家港行 Oracle、sybase 迁移至 TDSQL的方案：
     同时开发两套新核心业务系统，一套基于国外某商用数据库，而另外一套则基于分布式数据库，然后进行“内部赛马”，然后分别对两个系统的稳定性、性能进行对比测试，根据测试结果再决定使用哪套。经过整整一年的改造，无论是从性能成本，还是易用性，分布式数据库都表现出明显优势，进而最终新核心系统采用了分布式数据库，而之前采用集中式数据库的核心系统则保留为备用系统。

“中间件路由方案”：
苏宁易购 DB2 迁移 MySQL 方案：

苏宁的方案：在业务层与数据库层增加一个中间件路由模块，根据路由关键字判断使用 DB2 数据库的连接，还是使用 MySQL 数据库连接。他们使用的中间件是基于 MyCat。根据业务需求，在开源 MyCat 基础上做了定制开发（例如具体的分库分表算法实现等）。路由规则通过配置文件 +SQL 解析实现。

各位专家，还有哪几种方案可供选择？并且他们各有什么优缺点，代码改造量 和 改造难度如何？还请各位不吝赐教！在此谢过！