Legacy PHP to Laravel Migration Services
Running a custom PHP application, or one built on a framework that no longer exists? I move legacy PHP to Laravel and Vue one piece at a time, with the old code still serving everything that hasn't moved yet, so your business keeps working the entire way through.
The app that runs your business was written by someone who left in 2016.
A great deal of the PHP running real companies was never built on a framework, or was built on one that has since been abandoned. It works. It also has no tests, no documentation, and one person who understands it, if you're lucky.
None of these are emergencies on their own. Together, they're a slow-moving one.
- No structure to hold on to. Database queries in templates, business rules in includes, and a login system someone wrote from a tutorial. Every change risks something unrelated.
- Retired frameworks. Zend Framework 1, Symfony 1.x, Kohana, FuelPHP: all end of life, all without security fixes, all with hiring pools close to zero.
- PHP version lock. mysql_* functions, register_globals habits, and deprecated syntax mean the app can't move to a supported PHP release without work nobody has scoped.
- Security exposure. Unparameterised SQL, md5 passwords, and file uploads written to the web root are common in this generation of code. They are also exactly what the migration fixes first.
- Fear of change. Deploys are FTP and hope. Improvements stop happening because every one of them is a risk.
A stack you can hire for, host anywhere, and build on for the next decade.
Hireable
Laravel is the most widely used PHP framework, with a large US hiring pool and an active package ecosystem.
Batteries included
First-class queues, scheduling, auth, billing (Cashier/Stripe), and testing out of the box, instead of the bolt-ons every legacy PHP app grew on its own.
Modern interface, one codebase
Vue 3 with Inertia.js gives you a modern, fast interface without maintaining a separate API project, or a clean API + SPA if that's what you need.
Deploys you can trust
Deploys through Forge or your existing AWS setup with zero-downtime releases.
No big-bang rewrite. No cutover weekend.
The biggest risk in any migration is the rewrite that takes a year and launches all at once. I avoid that entirely using the strangler pattern:
- 01
Laravel goes in front
A new Laravel application is deployed alongside your legacy PHP app, sharing the same database and domain.
- 02
Shared sessions and auth
Users log in once. Existing password hashes are preserved, so nobody is forced to reset their password.
- 03
Route by route
Requests for migrated sections go to Laravel. Everything else still goes to the legacy PHP code, untouched.
- 04
Module by module
Each module (orders, users, reporting, admin) is rebuilt, tested against the original behavior, and switched over on its own.
- 05
The old app retires quietly
When the last route moves, the legacy PHP code is removed. There's no launch day because the launch already happened in pieces.
You get working improvements in weeks, not a year from now, and you can pause or reprioritize at any point.
Everything, mapped to its Laravel equivalent.
| Legacy PHP | Laravel |
|---|---|
| Procedural pages (page.php) | Routes + controllers + Form Requests |
| Raw SQL / mysql_* calls | Eloquent and the query builder, always parameterised |
| includes/ and config files | Service container, config, environment variables |
| $_SESSION handling | Laravel sessions and middleware |
| Homegrown login (md5 / sha1) | Laravel auth with legacy hash compatibility |
| .htaccess rewrite rules | Laravel routes + redirects for old URLs |
| HTML with inline PHP | Blade or Vue 3 components |
| Inline validation and error strings | Form Requests + lang files |
| File uploads to the web root | Laravel Storage (local or S3), out of the web root |
| Cron shell scripts | Artisan commands + scheduler + queues |
| Zend 1 / Symfony 1 / Kohana MVC | Laravel controllers, Eloquent, middleware |
Data stays where it is. The schema is migrated in place and improved gradually, not dumped and reloaded.
From first call to retired legacy PHP app.
-
01
Migration Fit Call
We talk through your app, your team, and your constraints. You leave with a realistic ballpark range and an honest read on whether migrating now makes sense.
-
02
Migration Assessment
I audit the codebase: framework and PHP versions, dependencies, custom modules, security exposure, and data model. You receive a module-by-module migration map, a phased roadmap, and a fixed-price quote. The full fee is credited toward the migration if you proceed within 60 days.
-
03
Phased Migration
Laravel is deployed alongside the existing app, then modules move over in priority order. You see progress in production every few weeks.
-
04
Support & Handoff
Documentation, tests, and a clean handoff to your team, or an ongoing support and hosting retainer if you would rather not manage it.
What does a legacy PHP to Laravel migration cost?
It depends mainly on four things.
As a rough guide, the Fit Call gives you a ballpark range for your specific app. The assessment turns that range into a fixed quote.
- Size of the codebase Number of modules, controllers, and custom screens.
- How much structure exists Framework conventions make a codebase faster to map than hand-rolled pages.
- Integrations Payments, CRMs, ERPs, third-party APIs.
- Test coverage and documentation Less of both means more discovery.
Who you'll work with
I'm Kelly Brintle, a principal architect and full-stack developer based in Carolina Beach, North Carolina. I run CraftWeb as a senior, hands-on consultancy: when you hire me, I'm the one reading your code, designing the migration, and writing the Laravel.
I specialize in legacy PHP migrations and full platform rebuilds on Laravel, Vue, and AWS, including payments, CRM, and communications integrations with Stripe, HubSpot, and Twilio. The same approach works for Yii, CodeIgniter, CakePHP, and custom PHP.
Legacy PHP migration questions, answered
It's not on a framework. Can you still run the two side by side?
Yes. Routing happens at the web server by URL path, so it works with any PHP application, framework or not. Migrated paths go to Laravel; everything else keeps hitting the old code.
Will our users have to reset their passwords?
No. Whatever the old code hashed with (md5, sha1, salted variants, crypt), Laravel verifies it and upgrades each user to bcrypt transparently the next time they log in.
Nobody knows what the old code does. How do you migrate it?
By treating the running app as the specification. Each piece is characterised (what it reads, writes, and sends for a set of inputs) before it is rebuilt, and the Laravel version is tested against that. Undocumented behaviour is discovered, not guessed.
What happens to our data?
It stays in your existing database. Schema changes are additive during the migration; cleanup and renames wait until the old code is gone.
Can we fix the security problems first, before migrating?
Often that is the right first phase: parameterise the queries, move uploads out of the web root, and get onto a supported PHP version. The Fit Call is where we decide whether to stabilise first or migrate first.
Can our in-house developers work alongside you?
Yes. I set up the architecture and patterns, and your developers take on pieces as they get comfortable with Laravel.
How long does a migration take?
It depends on scope. Small applications can move in a couple of months; larger platforms run longer. Because work ships in phases, you see results in production well before the end.
Do you work with companies outside North Carolina?
Yes. I work with clients across the US, remotely.
Find out what your migration would actually take.
A 30-minute call. You'll leave with a ballpark range, the main risks in your codebase, and a clear next step, whether or not we work together.