dJabber,

Наладить процесс разработки.

Вы в БД разработчиков наверняка будете производить значительно больше действий, чем потом потребуется для изменения продуктивной базы (не говоря про обычно существующую цепочку Dev -> Test -> UAT -> Prod с тестированием на каждой из стадий).

В общем случае - делать изменения структуры БД/наполнения справочников _только_ через SQL скрипты с последовательным складыванием их в любую Version Control систему (файловая система, SVN, Git, ...).
Потом формировать поставки фильтруя полученный упорядоченный набор этих скриптов, иногда производя ручной merge (чтобы не было CREATE TABLE и следом серия бессмысленных ALTER TABLE ADD COLUMN).
Формированием поставки должен заниматься кто-то конкретный. Это должна быть чья-то ответственность.

Если система у вас уже вышла в продуктивное использование, то структура БД должна уже в достаточной степени стабилизироваться, чтобы всё это было подконтрольно.

Любое автоматическое дублирование действий с Dev на Prod рано или поздно прибьёт вам продуктивные данные.

PS С использованием HADR target БД будет в лучшем случае read only.
Скорее уж Q-репликация тогда бы подошла. Но! даже в ручном режиме не все изменения накатываются гладко (например, после некоторых изменений в структуре таблиц требуется оффлайновый REORG).