How Much Does It Cost to Fix an Old Laravel App?

Your Laravel app still works. Mostly. Picture a dental practice in Columbus, Ohio, whose booking system runs on a Laravel 8 app a freelancer built years ago. Laravel 8 no longer gets security fixes. The billing code is a file nobody wants to open, and the developer who understood it left two years back. Every change takes a week, and every week someone asks the same question: how much does it cost to fix an old Laravel app? You've got two quotes so far. One says a light cleanup. The other says start again. Neither explains where its number comes from.

"Hence, plan to throw one away; you will, anyhow."

Fred Brooks, The Mythical Man-Month, 1975

Brooks was writing about new systems, but the lesson carries over to old ones. You can't price a fix you don't understand. Below is what moves the bill, how to read your own app before you call anyone, and what to put in writing before you sign.

What actually drives the cost

Four things move the number more than anything else.

How far behind the app is. Each major Laravel version is its own upgrade step. Going from Laravel 8 to Laravel 11 means three steps, and each one touches config, packages and queued jobs.

Whether there are tests. Without them, every change means someone clicking through checkout by hand. Nobody enjoys that. It's also where most of the hours go.

How tangled the data model is. Clean tables with clear relationships can be upgraded and extended. A customer's phone number stored in three places, say users, orders and an old contacts table, needs untangling first. That work is slow. It's also easy to underestimate.

What the app connects to. Stripe webhooks, Mailgun sends, a Horizon queue and a php artisan schedule:run cron entry are where old apps fail quietly. Each one has to be checked after every change.

These are relative sizes, not prices. A small app with no tests and a messy data model can cost more to fix than a bigger app that's clean and covered.

Upgrade, refactor or rebuild: read your app first

Use this table to get a first read on your own app before you talk to anyone.

The last row is the one people skip. If nobody can say what the app does, every quote is a guess. So the first job is to write it down.

Start by drawing the system

Before we build anything, we draw the client's system. That means the app's main job, what connects to what, and who keeps each part running. For an old Laravel app, we add three questions. Which scheduled jobs run each night? Which queues carry the emails and invoices? Which accounts hold the Forge server, the Cloudflare DNS and the Stripe keys?

That last question matters more than most owners expect. Ask it early. If the server sits on one developer's personal login, fix that first. Whatever the quote says.

Why upgrades go in steps

Laravel publishes a support policy for each release at laravel.com/docs/releases, so check which version you're on before anyone quotes you. Each major version changes something: config files, package versions, and sometimes how queued jobs or middleware behave. Jumping several versions in one go is how a two-week upgrade turns into a month of guessing which change broke the invoices.

A safer plan looks like this:

1. Laravel 8 to 9, tests green, deploy to staging.
2. Laravel 9 to 10, tests green, check the Redis queue and the nightly jobs.
3. Laravel 10 to 11, tests green, then the billing path gets a manual walkthrough.

If the app has no tests, write them first, for the billing path and the main booking flow. PHPUnit or Pest will do. That adds to the bill up front. It also keeps the rest of the bill predictable.

Laravel was the first language I got paid to write

I've worked in Laravel for years. Owners of old apps are usually surprised by what sits around the framework. It's the Eloquent model that everything imports. It's the cron job nobody remembers adding. It's the invoice email that only fails when a customer has two addresses on file. Those are the places where a quote should look harder. They're also where a good first conversation starts.

What to ask for in a quote

A useful quote names the version the app will end on, the number of upgrade steps, what the tests will cover, and who holds the hosting and the accounts. Ask at least three teams the same questions in writing. Then compare the answers line by line. A single lump sum tells you nothing. I'd trust the team that answers every question without a sales pitch.

Ask what you'll own at the end too: the code repository, a short document that explains how the app is put together, and a deploy process someone else could follow. Those three items decide whether your next developer can help you or has to start from zero.

When a rebuild is the cheaper answer

Sometimes the honest answer is a rebuild. The signs are clear once you look for them. Every new feature needs a workaround. The data can't answer the questions the business now asks. The structure was built around a product you no longer sell. At that point, paying to keep the old core costs more than paying for a new one.

Even then, keep the data and the parts your users rely on. A rebuild that throws away working MySQL records and the people who understand them usually costs more than the code it replaces. Scope it the way you'd scope any new product. Decide what the new system must do first and what can wait. Our how to scope an MVP guide walks through that method.

Frequently asked questions

Is it cheaper to upgrade or rebuild a Laravel app?

Usually upgrade, as long as the data model holds up. Don't let anyone talk you into a rewrite on day one. Upgrading in steps keeps working parts working, and each step is a smaller risk than a rewrite. A rebuild wins when the structure fights every new feature. The table above shows which one you're in.

How do I know if my Laravel app has tests?

Look for a tests folder with real test files, then run php artisan test. If the folder is missing or empty, or the tests fail before anyone has changed a line, treat the app as untested. Ask the team how they'll cover checkout and billing before they touch either one.

Should I pay for an audit before the full project?

Pay for one when nobody on your side can explain the app, or when the quotes are far apart. Don't skip it just to save a week. An audit won't fix anything by itself. It turns guesses into a list you can compare line by line, which is the cheapest way to find out which quote you can trust.

If your Laravel app is stuck between two quotes, our web development team can work through the system with you. Our top 10 Laravel development companies list covers other firms worth comparing. It starts with the same step: draw the system, then ask for the quote in writing.