Trade Supplier Order Desk: CodeIgniter Upgrade & Laravel Migration

We started by mapping the system: 214 controllers, 96 database tables and no tests. Each screen was traced from route to query so we knew what it read, what it wrote and which business rules it applied. The result was a map of risk that told us where to tread carefully and where change was safe.

That map also shaped the order of work. Pricing was the most sensitive area, so it was protected first; reports and stock screens were the slowest, so they were tuned early; and the modules the business wanted to change most were first in line for Laravel.

• Every route, controller and table catalogued
• Business rules extracted from the code
• A risk map guiding the order of work

Stage one moved the application to CodeIgniter 3 on PHP 8.3. Working on a copy, we fixed 340 incompatibilities: deprecated functions, removed extensions and changes in error handling. Every screen was tested against a snapshot of live data so behaviour could be compared before and after.

The upgraded application went live on a supported PHP version three weeks before the host’s deadline, with staff noticing nothing except that some screens were already faster.

Before touching pricing logic we wrapped it in PHPUnit tests for legacy code: trade bands, quantity breaks, contract prices, VAT rounding and delivery thresholds, all checked against results from the old system. Those tests run automatically in GitHub Actions on every change, so an upgrade or refactor cannot silently alter what a customer pays.

With the safety net in place, performance work could begin. Missing indexes were added, N+1 queries in the pricing engine were rewritten, Redis caching was introduced for repeated lookups, and a report that loaded the entire order history to show one week now queries only what it needs. The slowest screens fell from eight seconds to under half a second.

Stage three began replacing the old code with Laravel 11 using the strangler pattern. New modules run in Laravel behind the same URLs and share the database and session with the CodeIgniter application, so staff move between old and new screens without noticing a seam.

Four modules have been rebuilt so far, chosen because they were the areas the business wanted to improve, with no change to how the team works. Each further module can be migrated when there is value in doing so, rather than in one risky big-bang rewrite.