change data capture (cdc) - название класса инструментов для захвата изменений данных и переноса их куда вам надо

Хм, попробую донести мысль по другому.
Проблема - это наличие неразрешимого в текущем контексте противоречия.

Пока вы не сформулировали противоречие - говорить о необходимости внесения изменений рано.

Основная проблема - структура легаси базы не соответствует ни тому, как это принято в выбранном фреймворке для нового проекта, ни общепринятому подходу. Но я понял, как это разрулить. Переименую таблицы, поправлю код легаси проекта. Буду менять структуру таблиц и добавлять новые по мере необходимости

Спасибо

А что за мифический "фреймворк"?

Легаси - чистый  PHP, фреймворк - Laravel. Но это не принципиально ИМХО.

выглядит как шило на мыло

Почему ?

тоже интересно узнать, почему? @pragus

Тут может быть пара таких проблем с поиском мест использования таблиц со старым названием. 1. В коде название таблицы вычисляется, например, не 'hour_archive', а 'hour' . '_archive'. 2. Есть скрипты "не из проекта", которые используют базу. Например, скрипты из крона.

С именами порядок - они не определяются динамически. А вот со скриптами да, придется поискать. Тем более, что даже базового ридми в проекте нет.

Если первым будет меняться код, а не база, и если будет использоваться Eloquent, то название таблицы можно определить через свойство $table. Вдруг поможет эта информация.

Это я знаю :) просто хотелось сразу избавиться от User, ModuleRole и подобного.

Звучит похоже как на https://docs.microsoft.com/en-us/azure/architecture/patterns/strangler-fig , но только там не про "оборачивание фреймворком". Вообще, глубокая зависимость приложения от конкретного фреймворка - не самое лучшее архитектурное решение. Об этом Ralf Johnson писал еще в 1991, а сегодня, в век DDD/Clean/Onion/Hexagonal/CQRS, такая цель, как "мигрировать на современный фреймворк", звучит несколько интересно. В хорошей архитектуре, фреймворк обычно не проникает выше логики уровня инфраструктуры, и легко сменяется с одного на другой.

Непонятно, какую проблему пытаетесь решить (согласен с @WatchTh15 ). Для исправления структуры БД вроде необязательно внедрять фреймворк.

Про методы работы с легаси есть монументальная книга “Working Effectively with Legacy Code” by Michael C. Feathers. Можете посмотреть в ней, возможно, найдете то, что ищете.

Вообще я за то, чтобы у БД был API и абстракции уровня хранения данных никогда не протекали в логику приложения.

Можно конечно и кусок прикладной логики шить в бд.  Иногда это оправдано. Но чаще нет.

Поэтому с моей точки зрения наличие в коде приложения реализующего прикладную логику прямых обращений к абстракциям уровня хранения данных (таблицы, поля, вьюхи... Всё, кроме хранимых процедур) - bad smell.

php на php.

Менять надо весь код. Для этого фреймворк и нужен. Вопрос по базе был, так как не понятно было, как ее мигрировать на новую струкруту постепенно (теперь понял ;)).
За ссылку на паттерн и книгу  - спасибо. Посмотрю обязательно.
Что касается DDD  - это в плане миграции - сначала обернуть, потом разделить логику по доменам.

Реалии, к сожалению, таковы, что в проекте мало того, что нет никакой ORM. Там практикуется прямой доступ к базам данных, не принадлежащих проекту.

Прям почти как у меня ситуация. Делаю Strangler pattern, у новых (заменённых) сервисов свои базы данных.