Это больно, но первый большой вопрос: вам действительно нужно сделать эту реархитектуру? Если проект базы данных более или менее нормален, можете ли вы вместо этого спроектировать новый материал и оставить старый в покое? Каждый рефлекс жаждет навести порядок, но с точки зрения бизнес-пользователя, какой уровень инвестиций необходим и каков окупаемость?
Вы уже определили итеративное изменение как подход. Для того, чтобы это работало, это означает, что в системе есть некоторый уровень детализации, который позволяет вам изменять некоторые части, не затрагивая другие. Предположительно, ваша идея заключается в том, чтобы придать какую-то новую ценность для бизнеса и одновременно очистить некоторую часть приложения - эффективно амортизировать стоимость изменений по многим ценным результатам, «налог на сбор мусора» при доставке новых материалов. Это "налог" приемлем?
Так что я думаю, что допущение гранулярности - это то, что вам нужно проверить. Определите маленький кусочек. Попытка рефакторинга. Считаете ли вы, что это такое изолированное изменение, как вы надеетесь? Была ли цена, как вы ожидали? и главное ... какие минусы есть? Есть вероятность того, что ваш код работает хуже, чем существующие хранимые процедуры. Разработка «налога» это одно, а выполнение во время выполнения «налога» это совсем другое дело.