Александр, есть идея по достаточно большому блоку работы. Это проверка на совместимость между версиями FB.
При переходе, например, с FB 2.5 на FB 3.0 есть проблемы совместимости, описанные в релиз-нотах. В основном это новые ключевые слова, которые нельзя использовать в качестве имен переменных и т.д. И чтобы найти такие проблемные ХП и триггеры, надо либо писать средства поиска таковых (причем заранее найти эти новые ключевые слова в релиз-нотах), либо ресторить базу под 3.0, перекомпилировать ХП с триггерами, смотреть, где ошибки, менять метаданные, после чего снова повторять процесс.
Так же сегодня выяснилось, что FB 2.5 позволяет декларировать имена переменных длиной более 31 символ, которые не принимает 3.0.
Было бы очень удобно для всех пользователей (так как все рано или поздно мигрируют на более новый сервер), если бы IBE на этапе компиляции ХП/триггера или отдельной проверкой сообщал бы о будущей проблеме при переходе на указанную версию сервера (в идеале - просто последнюю для IBExpert'а).

Ivan_PisarevskyКак по мне так тотальная перекомпиляция понадежней будет.
Более того, я миграцию хочу сделать через сохранение метаданных в скрипт и накатку на чистую базу, после чего переносить сами данные. Но перед этим да, надо перекомпилить, чтобы потом не было обломов при накате скриптов.

IBExpertМне одному кажется, что куда проще и правильнее запустить на выполнение скрипт создания БД под новым сервером, постепенно выкусывая из него "голову", выполнившуюся без ошибок, и внося нужные исправления в "хвост"?
Минус - энное количество итераций. Отсутствие предварительной прогонки лишь увеличит время подготовки к миграции.

IBExpertДля этого давно есть анализатор PSQL в меню Tools. [...] Часть проблем, если они есть, он отловит. Но только часть.
Да, есть еще имена полей в таблицах, которые стали зарезервированными словами (у нас вот было ROW и OFFSET).

На всякий случай еще раз уточню - без таких проверок можно обойтись. Они нужны только для облегчения перехода на новую версию как:
1. Превентивная мера. Например, уже сейчас сообщать, что нельзя использовать слово DECFLOAT, т.к. оно станет ключевым в FB 4.0. И лучше об этом узнать сегодня на этапе разработки, а не через год, когда база в продакшене. У нас вот программист полгода назад создал таблицу с полем ROW. Сейчас пришлось переименовывать его. А если бы IBE сразу сказал ему про будущую проблему, он бы назвал поле как-нибудь по-другому. Или я вот сделал ХП с переменной в 32 символа. Я даже не в курсе был, что там такая длина. А при миграции - отлуп от сервера. И что самое интересное, при компиляции в 3.0 IBE сразу предупреждает о слишком большой длине переменной. То есть он в курсе про это. Так скажите мне об этом сейчас, не надо оттягивать.
2. Тест на наличие точных проблем при переходе на новую версию - мне приходится делать b/r базы, перекомпилировать ХП, исправлять в девелоперской базе, потом снова b/r, прогон компиляции и т.д. Просто сразу скажите, что точно сервер не примет, а дальше уже в рабочем порядке.

В общем, надо проверять:
1. Хранимые процедуры.
2. Триггеры.
3. Таблицы.
4. UDF (может появиться встроенная функция с таким же именем).

А манипуляции с версией сервера - это можно использовать, но вещь неочевидная.