Almost every business I talk to has one. A PHP application written eight or ten years ago, by someone who has since moved on, that still runs the most important part of the company. Nobody wants to touch it. Every new feature takes three times longer than it should, and the server it runs on is quietly getting older.
The instinct is to say: let's rewrite it properly. I understand that instinct. I also think a big-bang rewrite is the riskiest thing you can do to a working business. Here is the approach I use instead.
First, understand what you actually have
Before writing a line of Laravel, I spend time reading the old code and the database. I'm looking for a few things:
- Which parts are used every day, and which are dead code nobody has opened in years.
- Where the business rules live. In old PHP apps they are often scattered across page files, SQL queries and even JavaScript.
- What talks to the outside world: payment gateways, SMS providers, cron jobs, CSV imports, other systems reading the same database.
- The URLs customers and search engines know.
This usually produces a short written map of the system. It's the most valuable document in the whole project, because it turns "the scary old app" into a list of modules with clear edges.
Run old and new side by side
The pattern I use is often called the strangler fig: the new system grows around the old one until the old one can be removed.
In practice:
- Install Laravel and put it in front of the existing app.
- Laravel handles the routes that have been migrated. Everything else falls through to the old PHP code, untouched.
- Both apps read and write the same database during the transition.
- Move one module at a time: login, then customers, then orders, then reports.
From the user's side nothing changes, except that pages slowly get faster and bugs stop coming back.
Treat the database carefully
Old databases are rarely tidy. Missing foreign keys, columns named data2, dates stored as text. I don't clean all of that on day one. I wrap the existing tables in Eloquent models first, so Laravel works with the data as it is. Then I improve the schema in small, reversible migrations, each with a backup and a rollback plan.
Keep URLs and SEO safe
If the old app has public pages, every URL that ranks in Google needs to keep working or redirect with a 301 to its new home. I export the old URL list before starting and test every one of them before each release.
Test the boring paths
The bugs that hurt in a migration are rarely in the new features. They're in the old behaviour nobody wrote down: a discount that only applies on Fridays, an invoice number format an accountant depends on. I write tests that pin down how the old system behaves today, then make the new code pass them.
What it usually looks like
| Phase | What happens |
|---|---|
| Audit | Read the code and database, write the module map |
| Foundation | Laravel in front, shared database, auth moved first |
| Module by module | Each module migrated, tested and released on its own |
| Cleanup | Old code removed, schema improved, server upgraded |
The timeline depends entirely on the size of the app, which is why I always start with the audit rather than a guess.
Is it worth it?
If the old app still works and rarely changes, maybe not yet. But if every change is slow and risky, if it runs on a PHP version that no longer gets security updates, or if you want to add things like an API, a mobile app or AI features, a gradual move to Laravel pays for itself quickly.
I offer this as part of my migration and modernization service. If you have an old PHP system you're nervous about, tell me about it. The first conversation is usually just me asking a lot of questions.
