Kohana 3.3, on a project that earns money every day. The framework is effectively finished. The repository barely moves, the community left years ago. Nobody will approve a rewrite, and I have stopped asking. This is a normal situation and it deserves a better plan than “someday we migrate”.
The plan we settled on is a freeze.
Pin the exact framework version and vendor it. Not “3.3.*”, the exact commit. The build must be reproducible in five years, when the original download link is dead.
Keep our own fork. It accepts one kind of change: security fixes. No features, no refactoring, no cleanup. Every patch in the fork is a liability during any future migration, so the list must stay short enough to read in one sitting.
Write tests around the places where our code touches the framework hardest. Routing, the ORM, the request cycle. These tests are the safety net for PHP upgrades, because PHP keeps moving even if Kohana does not, and something will break on 7.0.
And the main rule, the one that changes daily work: new business code must not depend on Kohana_* classes when it can avoid it. New logic goes into plain PHP services, wired through Composer autoload, and controllers stay thin adapters. I wrote about this before, and the freeze is where it pays off. Every class that does not know about Kohana is a class that survives Kohana.
The point of a freeze is that the frozen part stops costing attention. A dead framework with a fixed boundary around it is just old code, and old code that works is fine. The dangerous thing is a dead framework that keeps leaking into every new file you write.