Многое конечно зависит от специфики проекта, но примерный алгоритм действий в общем случае такой:
1. Выбираете новый фреймворк (или без него, на ваше усмотрение). Решаете делать новый функционал на нем и только на нем. ZF2/3 ли, Symfony, Laravel - разницы никакой, что вам нравится. Готовьтесь к тому, что придется бизнес логику переписать полностью (если интеграция с фреймворком была жесткой, как обычно делают PHP разработчики). Если была завязанность на абстракциях и модульная структура - вас можно поздравить, переход будет безболезненным и быстрым.
2. Приготовьтесь, что работы станет больше, чем просто на ZF1 задачи решать и дальше. Постарайтесь не просесть слишком по производительности.
3. Есть список URL, перенесенных в новое приложение. Решение о том, какому приложению отдать обработку запроса, находится в точке входа в приложение. (в index.php, например. Т.е если обычно там происходит просто инициализация приложения, то перед ним теперь должна быть бизнес-логика определения, какому приложению дать ход, этакий свой мини-роутер. Если переписано - отдаете новому приложению. по дефолту старому)
4. Если у вас не было тестов - именно тут вы начнете понимать, почему они были нужны :)
Ну и по факту получается, что у вас некоторое время будет 2 приложения, которые надо параллельно разрабатывать. Старое помечаете как немодифицируемое. Приходит задача - сначала переносите ее на новый фрейм, тестируете, если работает как надо - в своем мини-роутере направляете соответствующие запросы в новое приложение. Постепенно с 0% до 100% доводите - и можно выкидывать старый фреймворк и микро-роутер в индексе, вы переехали.
Повторюсь в поддержку ответов выше, бизнесу почти всегда откровенно все равно, что там под капотом, не эта технология приносит денег. Если вы не можете убедить начальство законсервироваться и все переписать - значит или в этом правда нет необходимости, или у вас недостаточно прокачан навык убеждения.
Простой
Сложный
Простой
