The old system still works. Orders go in, invoices come out, and the one developer who understands it picks up the phone when something breaks. That is exactly why moving off it feels risky, and why so many companies put it off until something forces the issue. If you plan to migrate PHP to Laravel, the safe route is rarely a rewrite from scratch. It is a planned move, one module at a time, with the business running on the old code until each new piece has shown it can do the same job.
Why this can't wait much longer
PHP versions have fixed support windows, and many legacy applications are running past theirs. According to PHP's supported versions page and its list of unsupported branches:
- PHP 7.4 reached end of life on 28 November 2022, and PHP 8.0 on 26 November 2023.
- PHP 8.1 reached end of life on 31 December 2025.
- PHP 8.2 receives security fixes only until 31 December 2026.
- PHP 8.4 has active support until 31 December 2026 and security support until 31 December 2028.
An application on PHP 7.x has had no security fixes from the PHP project for years. Laravel 13, released in March 2026, requires PHP 8.3 or newer, so moving to current Laravel also moves you onto a supported PHP version such as PHP 8.4. You fix two problems with one project.
Why a big-bang rewrite usually goes wrong
The tempting plan is to rebuild everything in Laravel, then switch over one weekend. It fails in predictable ways.
- Hidden rules. Ten years of code hold decisions nobody wrote down: a rounding rule for one region's tax, a customer who gets invoices in a different format, a status that only one report uses. A rewrite finds them one at a time, usually after launch.
- A moving target. The business keeps asking for changes to the old system while the new one is built. Either you freeze the old system for months, or you build every change twice.
- All the risk on one day. If anything is wrong at cutover, everything is wrong at cutover.
- No value until the end. Months of spending before anyone uses a single new screen.
We would only suggest a full rewrite when the old system is small, or when the business process itself is being redesigned and the old behavior no longer matters.
How to migrate PHP to Laravel one module at a time
This approach is often called the strangler pattern: the new application grows around the old one and takes over its work piece by piece until the old code can be removed.
1. Get the old system under control
Put the code in Git if it isn't already. Set up a staging copy with a recent database, error logging and tested backups. Then list every entry point: pages, form handlers, cron jobs, API endpoints and any scripts that process incoming email or files. That list becomes your migration plan. If the old code runs on PHP 7.x, check whether it can move to PHP 8.x with modest fixes; sometimes that alone buys valuable time.
2. Put Laravel in front
There are two common setups. Either the web server sends specific paths to Laravel and everything else to the old code, or Laravel receives every request and a fallback route hands anything it doesn't recognize to the legacy application. Either way, users see one site and the URLs don't change.
3. Share the database before you change it
Resist the urge to redesign the schema on day one. Laravel's Eloquent models can point at existing tables, even ones that break Laravel's naming conventions. Say the old system stores customers in tbl_customers with a primary key called cust_id and no timestamp columns. In Laravel 13 the model looks like this:
use Illuminate\Database\Eloquent\Attributes\Table;
use Illuminate\Database\Eloquent\Model;
#[Table('tbl_customers', key: 'cust_id', timestamps: false)]
class Customer extends Model
{
}Both applications now read and write the same data. Clean up table names and columns later, once every piece of code that touches a table lives in Laravel.
4. Decide who owns login, early
Two applications need one login. Pick which system owns the session from the start and make the other one trust it. Moving login to Laravel early is usually worth it, because it lets you fix password storage.
Many older PHP systems store unsalted MD5 or SHA-1 password hashes. Laravel hashes passwords with bcrypt by default, and you can upgrade users silently as they log in: check the old hash, and if it matches, store a new bcrypt hash and delete the old one.
if ($user->legacy_md5 && hash_equals($user->legacy_md5, md5($password))) {
$user->password = Hash::make($password);
$user->legacy_md5 = null;
$user->save();
}Users who never log in keep their old hashes, so after a set period, force a password reset for whoever is left.
5. Move modules in order of risk
Start with low-risk, read-only parts such as reports and admin lists. They test your models against real data without being able to damage it. Move core workflows next, and money last: invoicing, payments and anything that feeds accounting.
6. Retire the old code
Move cron scripts into Laravel's scheduler and queues. Log every request that still reaches the legacy code; when that log stays empty for a few weeks, delete the old code.
Testing: prove the new code matches the old
Before rewriting a module, record what the old code produces for real inputs. For an invoicing module, that might be the totals, tax and line items for every order from last month. Then make the new Laravel code produce the same results for the same inputs. Each difference is either a bug in the new code or a bug in the old code that the business has come to rely on. Decide each one on purpose, with someone from the business in the room.
For anything involving money, run both versions side by side for a billing cycle: calculate in both, compare automatically, and alert on any mismatch before you switch over.
Small, frequent releases are part of the safety net. A deployment setup that swaps versions without interrupting users makes it cheap to ship each piece as it is ready, and our walkthrough of zero-downtime deployments for Laravel shows one way to set that up.
A worked plan for a typical system
Imagine a distributor's order system: about 80 PHP files written over ten years, a MySQL database with 45 tables, and these modules: users and login, customers, products and price lists, orders, PDF invoices, monthly reports, and six cron scripts for stock sync and reminder emails.
- Groundwork: Git, staging, logging, backups, the entry-point list and a PHP upgrade check.
- Laravel in front with a fallback route; login and users moved, with password upgrades on login.
- Monthly reports, which are read-only and a safe test of the models on legacy tables.
- Customers, products and price lists.
- Orders.
- Invoices, with one billing cycle of parallel runs comparing totals.
- Cron scripts moved to the scheduler and queues.
- Legacy code removed and the schema cleaned up.
Each phase goes to production on its own, so the business never stops for a cutover weekend. To estimate, count the entry points in each module, estimate each one, and add a buffer for undocumented rules. The thinner the documentation and the fewer people who remember why things work the way they do, the bigger that buffer should be.
When not to migrate to Laravel
A PHP-to-Laravel migration is not always the right investment. Check these before you commit.
- The app is small and stable. Upgrading it to a supported PHP version and adding tests around the risky parts may be all it needs.
- It is built on another maintained framework, such as Symfony. Upgrading that framework is usually a smaller job than switching.
- The process is moving to off-the-shelf software within a year or two. Keep the old system patched and spend the budget on the move.
- Nobody on the business side has time. A migration keeps asking "is this old behavior intended?", and someone has to answer.
If you are still weighing whether Laravel is the right destination at all, our comparison of Laravel and Node.js for business backends covers that choice.
The first practical step costs nothing: write down every entry point of your current system and which PHP version it runs on. That list tells you how urgent the move is and how big it will be.
When you have it, our Laravel team can review the codebase and propose a phase plan. We can sign an NDA before you share any code, and the first phase can be a single paid milestone so you can judge the work before committing to the rest. Start the conversation through our contact page.
