Legacy PHP to Laravel
Modernisation for PHP applications that still earn money and cannot be frozen for a year while someone “rebuilds it properly”.
Legacy PHP is usually a business process, not a framework choice
The expensive part of a PHP-to-Laravel move is not routing. It is implicit rules in the old code: rounding, stock, who is allowed to reverse a transaction. A rewrite that skips characterisation of those rules will look prettier and still be wrong.
If you are already on Laravel and merely behind, you want upgrades, not this page.
Process
- Map the real system What is PHP, what is a stored procedure, what is a human with Excel.
- Stabilise Backups, deploys, the credentials in someoneu2019s head.
- Carve a boundary The first Laravel surface is the one with the most change or the most risk u2014 not the homepage.
- Move data with a plan Dual write or read, cutover, not a hopeful mysqldump on Friday.
Questions that usually come up
Do we have to rewrite everything?
Almost never as a first move. A strangler approach u2014 new Laravel around the parts that change u2014 is usually less romantic and more successful.
Can you support the old PHP while migrating?
Yes. Production still has to run. That is part of the sequence, not a side quest.
Qualification
Discuss your Laravel project
Name, work email, and a short description of the application is enough. No discovery call theatre before I know whether I can actually help.
- UK businesses with a real Laravel (or legacy PHP) application
- Build, support, rescue, upgrade or integration work
- Reply from Oliver Burton, usually within one working day