Немного банальностей:
1. Бизнес не даст ресурсов на переписывание проекта с 0: время и большие риски
2. Бизнесу как правило все-равно какое говно там крутится, лишь бы деньги приносило.
3. Если более-менее адекватное руководство - нужно донести идею постепенного рефакторинга кода по мере необходимости в процессе фикса багов и разработки новых фич и тем самым аргументировать что на разработку новых фич/фикс багов нужно больше времени.
Как я бы делал:
1. Тесты на существующие функции (если возможно, видел методы в контроллерах с мешаниной вызовов методов моделей, созданием DTO и сохранением их через репозиторий, прямых http-запросов и запросов в бд на 1000+ строк, покрыть такое тестами - невозможно)
2. Составить план рефакторинга, где отметить что и где надо сделать, коротко, в основном для команды разработчиков.
3. Постепенно рефакторить старый код по мере взаимодействия с ним.
4. Новый код - писать сразу правильно, для взаимодействия со старым кодом где нет возможности/времени его переделать - делать какие-то адаптеры, что бы не распространять токсичный код.
5. Как оперативная мера защиты от SQL иньекций можно поставить что-то вроде этого
https://github.com/nbs-system/naxsi
6. Мониторинг кода, который не используется -
pinba.org , по мере обнаружения такого кода - удалять безвозвратно (в крайнем случае есть VCS, я надеюсь). Начать с более высокоуровнего кода - контроллеры, напримерю. Плюс IDE в этом могут помочь и grep.
7. Как вариант - новые фичи можно пилить в отдельном проекте (v2), крутить оба и постепенно переходить на новый, со временем старый (v1) выкинуть (и начать делать новый - v3 :-) )