ну то есть, можешь почитать про strainglet паттерн например. тут надо два фреймворка между собой подружить для начала а не пытаться "код переносить". это по сути большой проект по переписыванию с нуля и это никогда не работает с точки зрения экономики. большинство таких инициатив просто умирают
ну и опять же - выглядит так что у тебя и с ларавелью опыта не очень много. возможно лучше будет попытка замены отдельных компонентов коханы на какие-то другие компоненты
например - роутинг - замена на симфони роутинг (лара всеравно его юзает). или там еще какие штуки. Изоляция кода с бизнес логикой паралельно. или там введение какого-нибудь service locator (потому что di если его нет ты быстро не внедришь) что бы хоть как-то с зависимостями бордак разбирать
тебе в любом случае стоит озаботиться вопросами автотестов - что-то дешевое. типа простой скрипт который ходит по страничкам и кликает кнопки просто что бы убедиться что нет крэша. Самые базовые сценарии. Большую часть проблем это отловит на подлете и сделать не очень дорого. Если есть возможность этот вопрос зааутсорсить (есть куча компаний которые тебе напишут такие тесты быстро) то стоит это делать...
мосты, адаптеры, фасады (не something::getSomething() - это не фасад, это сервис локатор к фасаду, люди это путают в ларе постоянно и авторы фреймворка не помогают ибо сами путают)
главное что бы этот проект на кохане был написан не любителями "чистой архитектуры" и прочих слоеных булшитов с высокой связанностью. Лапшу проще рефакторить чем лазанью. главное что бы получились равиоли)
я если честно плохо помню как кохана выглядит и че там с ней можно сделать в плане миграции. но в любом случае начал бы с того что бы организовать мост, что бы условно фронт контроллер заменить и вот это все. адаптеры под компоненты каханы что бы можно было постепенно переносить и т.д