Все зависит от того как приложение написано. Если в него жестко зашита зависимость от определенной СУБД, то тогда проще приложение заново написать. Особенно если значительная часть бизнес-логики в базе (ХП) и логика собственно приложения более-менее тривиальна.

Я всвое время работал над системой которая жила под Информиксом, Ораклом, DB2. И все пучком. Просто логика была сконцентрирована в middle tier, и вся логика сильно зависимая от БД была выделена в отдельный модуль. Картинка такая:

(1) Интерфейс -> (2) Логика приложения независимая от БД -> (3) API - интерфейс модуля логики зависимой от БД -> (4) модуль зависимый от БД -> (5) собственно БД

Соответственно версии продукта под разные СУБД отличались друг от друга (4) и (5). С интерфейсом (3) пришлось основательно помучаться. Зато система одинаково хорошо работает с разными СУБД, так как с каждой СУБД она общается с помощью кода специально оптимизированного под нее.

Модуль (4) переписывается на 100%. Печально, но факт. Теоретически можно разделить его на переносимую часть и непереносимую часть (специфичную к СУБД). Обычно это неоправдвнно, так как из-за существенных различий в семантике обработке транзакций непереносимая часть получается процентов 70-80. А городить огород с тестированием переносимости из-за 20% кода неоправданно.

Самое главное - разработать грамотный API модуля который в базу лезет. И сконцентрировать бизнес-логику с левой стороны этого интерфейса, а детали разработки связанные со спецификой СУБД - с правой стороны. Сказать это легко, а вот исполнить - сложнее. В случае простейшего приложения за API вполне сойдет ODBC/JDBC а за модуль (4) хранимые процедуры. В случае нетривиального приложения это не сработает - вылезут различия в реализации ODBC/JDBC и и реализации возврата данных из ХП.