CodeIgniter 3 to 4 migration for live applications

This page is for you if you want to stay on CodeIgniter. Your app works, your developers know CodeIgniter, and you do not want the cost and risk of changing framework. A CodeIgniter 3 to 4 migration gives you a supported framework and a supported PHP version while keeping the overall shape of the app familiar.

It is honest to call it a partial rewrite, not an upgrade. CodeIgniter 4 was rebuilt from scratch and is not backwards compatible, so every controller and model is touched. The business logic inside them, your SQL and your database schema mostly carry over. That is why it still costs far less than a full rebuild.

If you already know you want to leave CodeIgniter for a bigger ecosystem, read my CodeIgniter to Laravel migration page instead. Doing CI4 first and then Laravel later means paying for two migrations.

CodeIgniter 3.1.13 is the last official CI3 release. It added PHP 8.0 and 8.1 compatibility, and the CodeIgniter download page now describes the 3.x line as in maintenance with mostly security updates. On the CodeIgniter forum, the answer to "does CI3 support PHP 8.2?" has been the same for years: not officially, upgrade to CI4.

That matters because PHP 8.1 stopped receiving security fixes on December 31, 2025, and PHP 8.2 follows on December 31, 2026. Hosts move accounts to newer PHP, and CI3 apps start to fail in the predictable ways listed below.

Community forks of CI3 exist that patch it for PHP 8.2 to 8.4. They can buy time, but they are maintained by individuals, may behave slightly differently from 3.1.13, and you are still on a framework with no roadmap. I can apply them as a short bridge while the real migration runs, and I explain the CI3 errors in more detail in CodeIgniter 3 PHP 8 errors and fixes.

• "Creation of dynamic property is deprecated" warnings from core classes and your own models on PHP 8.2 and later
• "Passing null to parameter of type string" deprecations in URI handling, form helpers and your own code
• Session handler return-type warnings that can stop logins working cleanly
• Old libraries that call functions removed in PHP 8, such as each() or create_function()
• A PHP 9 future where today's deprecations are expected to become hard errors

When people compare CodeIgniter 3 vs 4, the headline is "namespaces and PSR-4". In practice, these are the changes that take the time on a real migration:

• Folder layout: application/ becomes app/, and the web root moves to public/, so your server's document root must change
• Loading: $this->load->model() and $this->load->library() give way to namespaced classes, model() and service()
• Input: $this->input->post() becomes $this->request->getPost(), and validation rules move to CI4's Validation service
• Models: CI4 models have $allowedFields, built-in timestamps and soft deletes, which change how inserts behave
• Routing: CI4 disables auto-routing by default, so every URL needs an explicit route or Improved Auto Routing
• Hooks and MY_Controller checks become Filters, which is where auth and CSRF should live
• Some CI3 libraries were removed (Cart, Javascript, Trackback, XML-RPC among them) and need a replacement
• Encryption and sessions use new config; CI4 has a CI3 compatibility setting for encryption, but sessions are usually reset at cutover

Partly. There are open-source helpers that convert CodeIgniter 3 to 4 by moving files, adding namespaces and rewriting common calls. They save typing on simple controllers. They do not understand your hooks, your base controller, HMVC modules, or the places where business logic lives in views and helpers, and that is where migrations go wrong.

I use tooling where it is reliable and migrate the rest by hand, one module at a time, comparing old and new output on the same data. For the full step-by-step technical view, see my CodeIgniter 3 to 4 migration guide.

Both are valid. The decision depends on the app's future more than its past.

• Choose CI4 if the app is stable, mostly CRUD and reports, your team knows CodeIgniter, and you want the smallest change that gets you onto supported PHP
• Choose CI4 if the app is a product built on CI, such as a Perfex CRM add-on, where the host platform decides the framework
• Choose Laravel if you plan major new features, need queues, scheduled jobs, APIs for a mobile app or complex permissions, or struggle to hire CodeIgniter developers
• Choose Laravel if the code is so tangled that most of it would be rewritten anyway

A small app with a dozen controllers is a very different job from a multi-module ERP with HMVC and custom libraries. I give a fixed quote after a short call or a written brief, usually once I have seen the code.

The main drivers are the number of controllers and models, how much logic sits in views and helpers, third-party libraries that have no CI4 version, how many URLs must stay identical, whether any tests exist, and whether the server can run two PHP versions side by side during the move.