I have a lot to say for the port and why I'm going to stick with Kohana. First off, the port was very quick. You'll find that Kohana's libraries and helpers are neatly named and that, like in CodeIgniter, you'll probably figure out where to look for something by simply reading the file names.
One of the most important features of Kohana was that your final application is a flattened view of your application, the modules and the system. Each of these folders (application, system, modules/application) have the exact same file structure (config, controllers, models, views, etc.), but as you go up (from system, through modules and finally towards the application) files are replaced based on priority. So you can have a routes.php in your system/config/routes.php but in the end your application/config/routes.php will override it (if one exists). This has powerful implications!
The modules are an incredible feature. Consider your running two applications, simply like a front site and admin. There's a lot of times when the two applications will share the same models or have the same base controller. You can put all of those into a module and have both applications refer to the module. One application could also extend or even overwrite bits from the module.
The auto auto-loading helps you avoid making bad design decisions. I remember I had a problem with CI when I tried to make my own helpers that would extract the page section by parsing the URI segments. Now, I could have depended on the URL helper, but it's a bad decision to have a helper be dependent upon another helper. One way to avoid it would be to auto-load all dependencies, but that just makes for a sloppy solution. So what I had to do to avoid it was to fetch the CI instance and just use the URI class instead and cache the results for that request. No problem with that in Kohana, you just write helper::function and Kohana will make it available for you. That means you can reuse Kohana helpers within your own helpers.
Being strictly OOP is a huge plus. You now have a full design freedom and are able to seamlessly implement any patterns and use the full range of inheritance options. When you switch from CI to Kohana you'll start thinking differently about your design decisions. Imagine you had a dynamic header where you'd always like to set certain data for each controller (like meta keywords, description, author, css files loaded, etc.) I'd previously do it by either having a header controller with lots of setters (HMVC and very very tight coupling) or simply define the data for my header view in the base controller (I'd use an intermediary Config class to set the header, page, menu and footer data). I wanted all my pages to have default headers settings where the behavior can be changed in child controllers. So the neat way to do it, with a Config class, would be to have the class loaded with default values and change those in child controllers like:
$this->config->set_header_data(array('page_title' => 'New title', 'page_robots' => 'nofollow');
In Kohana you can do this without any intermediary classes to force behavior because each view is a self-containing object, so in your base controller you can do something like:
public $header;
public function __construct() {
$this->header = new View('header');
$this->header->page_title = Kohana::config('meta.default_page_title);
// other default settings
}
And in some child controller:
class Child_Controller extends Base_Controller {
public function __construct() {
parent::__construct();
$this->header->page_title = 'New page title';
}
}
Like other frameworks, Koahana offers 'vendor' support, that is, it provides you with a very simple guideline on how to structure 3rd party, non-kohana, code and have it available across the system. Usually, this involved hacking CI with your own file structure and somehow imposing those guidelines, or you could have been mess, as most, and just smack them all into your libraries folder (where they'd have no place) and just include them in some CI library. Overall, it's very neat in Kohana.
Kohana defines support for parsing config files. There is no 'routes.php', or 'config.php', etc. in Kohana. They're all config files located under 'config/' in your application, modules or system folder. It's supper easy to create your custom files and access it through Kohana::config('file_name.config_key') (Kohana::config() also supports setting values ((auto-magically create new salts and keys every now and then!!!))). In short, you won't have your config.php including a lot of your custom config files.
Kohana is very dependent on events from it's components. That means it's more used, easier to digest from reading code, easier to digest from reading libraries. You'll be feeling at home in no time.
The debugging is much much easier. Kohana offers two modes, based whether the application is in production or in testing. It's handled by config and is very useful for development. You can use the flag to control things like not sending e-mails while in development, etc. In development you have full access to a complete stack trace and generally the errors are more verbose. The thing I also like about Kohana is that it can be set to explicitly fail on the slightest error in development, for things such as trying to access a variable in a view that hasn't been set.
Finally, exception handling is a lot better in Kohana. You also have a lot of options on how to do custom error handling, but it requires zero or less hacking than CI. You can call set_error_handler() and set_exception_handler() and do custom error handling or you can simply overwrite the kohana_error_page.php in views, have it call other views or other controllers (your custom error controller), do something depending if your live or in development, etc.
I guess the trade offs are that CI has a bigger community and more add-ons developed. EEv2 will be completely based off CI and that gives CI developers a huge advantage.
Essentially, both are very easy. You need about as much the same time to grasp the conventions of CI and Kohana and it's a very fast learning curve. One thing you'll notice about Kohana is that it's as easy to extend and comes packed with more conventions that save even more time and that if you ported your CI application to Kohana that, once it's up and running, you wrote less code, extended less core files and implemented fewer hacks.