Laravel Rescue: How to Recover a Failing Project (UK Guide)

If you are reading this because a Laravel project has gone wrong, start here: it is not a reflection on your judgement. Software projects fail for structural reasons — requirements that moved, a budget that got squeezed, a developer who took the only working knowledge of the system with them when they left. We assess code, not people, and almost nothing we find in a failing Laravel app is a surprise.

A working Laravel application, even a messy one, encodes years of business decisions that are genuinely valuable. Most of the time it can be recovered. This guide covers what to do today, how an audit works and what it costs, the version deadlines quietly driving a lot of UK rescues right now, and the narrow set of circumstances in which a rewrite is actually the right call.

The signs you need a rescue

None of these are unusual. All of them are recoverable.

• Your developer has gone silent. Replies have dried up, or the firm has simply disappeared.
• Every change breaks something else. Deploys have become feared events, so improvements quietly stop happening.
• You are stuck on an old Laravel version. Nobody will touch the upgrade because nobody is confident it will still work afterwards.
• There are no tests and no documentation. Only one person ever understood it, and they are gone.
• You suspect a security problem but cannot confirm it. Outdated dependencies, exposed credentials, weak authentication — and no one who can tell you either way.
• Every estimate doubles. The project has been “nearly done” for months.

What to do first — before you hire anyone

This is the part most owners skip, and it is the part that matters most. Before any code gets written, establish what you actually own. In our experience the first genuine deliverable of a rescue is often not a refactor at all — it is a list of accounts and passwords. Jump24, a UK Laravel Partner, lists “agency transitions” as a named category of rescue project for exactly this reason.

Work through this today. You can do all of it without a developer.

1. Check who owns your domain. Run a WHOIS lookup. If the registrant is your former developer rather than your company, that is your single biggest exposure — everything else depends on the domain.
2. Confirm the git repository is under your control. Is it in an organisation account owned by your company, or a personal account belonging to someone who has stopped replying? Add a second company-controlled owner now.
3. Get the hosting and server credentials. Server access, control panel logins, SSL certificate ownership, DNS access.
4. Audit third-party accounts. Stripe, Mailgun, AWS, and anything else your app depends on. Are they registered to a company email address, or to someone’s personal one?
5. Find out when the app was last deployed — and whether anyone can still deploy it at all.
6. Test a backup. Not “confirm a backup exists” — actually restore one somewhere safe. An untested backup is a hope, not a plan.
7. Collect whatever documentation exists, even if it is a handful of Slack messages and a README.

Do this politely and in writing. Most departing developers hand things over without drama when asked plainly. If the relationship has already broken down, having this list complete before you escalate puts you in a considerably stronger position.

Then ask someone technical to check three things that are quick to verify and dangerous to leave: whether APP_DEBUG is set to true in production (it exposes stack traces, and often configuration, to anyone who triggers an error), whether the .env file is reachable from a browser, and whether credentials are committed into the git repository’s history. Those three, plus untested backups, are what we treat as immediate rather than scheduled.

The clock nobody told you about

A large share of Laravel rescues are not really rescues. They are overdue upgrades that stalled, and the deadlines are public and verifiable.

Laravel’s own release policy states it plainly: “For all Laravel releases, bug fixes are provided for 18 months and security fixes are provided for 2 years.” Major versions land roughly every Q1. That gives a support picture that catches a lot of businesses off guard:

Read that table as a calendar rather than a reference. Laravel 11 has received no security fixes since 12 March 2026. Laravel 12 stops receiving bug fixes on 13 August 2026 — roughly four weeks from the date this was published. Laravel 13, released on 17 March 2026, is the current version.

PHP is running its own clock underneath. Its policy gives each branch two years of active support and then, from PHP 8.1 onwards, “two additional years for critical security issues only”. So: PHP 8.1 reached end of life on 31 December 2025. PHP 8.2 is security-only and dies on 31 December 2026 — under six months away. PHP 8.3 is security-only until 31 December 2027. PHP 8.4 and 8.5 are the only branches still in active support. (Do not apply that four-year window backwards: PHP 8.0 ran under the older policy and ended on 26 November 2023.)

This is not a niche problem. JetBrains’ State of PHP 2025 survey of 1,720 developers who name PHP as their main language — a global sample, not a UK one — found that 33% still work with PHP 7.x, every release of which has been end of life since November 2022 at the latest.

”We’re on LTS, so we’re fine”

We hear this often, and it is now a red flag rather than reassurance. Long-term support ended with Laravel 6, which received bug fixes until 25 January 2022 and security fixes until 6 September 2022. None of the current release rows carry an LTS marking; the modern policy has no LTS tier at all. If someone has told you your app is fine because it is on LTS, they are describing a framework whose security support expired nearly four years ago.

How an audit works, and what it costs

An audit exists to replace anxiety with a priced list. Ours is £2,500–£5,000 depending on the size of the application, and the fee is credited in full against any remedial work you commission. You get a written, plain-English report that is yours to keep — you are free to act on it with us, with your own team, or with anyone else.

The work splits into two halves. The automated half is genuinely cheap: composer audit and npm audit surface known CVEs and abandoned packages; PHPStan (with Larastan for Laravel-aware rules) runs static analysis across levels 0 to 10; Enlightn checks Laravel-specific concerns like CSRF configuration and mass assignment; Psalm, PHPMD and OWASP ZAP cover taint analysis, complexity and dynamic testing. Useful tools, all of them — but note what they do not do. PHPStan will not tell you that your architecture is wrong, and it will not find your security vulnerabilities.

The expensive half is judgement: reading what the automated output means for your business, separating what is fragile from what is merely unfashionable, and sequencing the fixes so you can fund the critical ones first.

On timing, the most useful published UK benchmark comes from Rocking Tech, a firm in Milton Keynes and London: 2–3 weeks for a typical application of 50–200 models and 10,000–50,000 lines of code. They are also, as far as we can find, the only UK company publishing a fixed price for this work — a £4,500, three-week Platform Discovery Sprint. That is one vendor’s rate card, not a market rate; the UK norm remains consultation-then-quote.

The upgrade path, honestly

Here is the version arithmetic that actually applies to most stalled apps.

Say you are on Laravel 11 running PHP 8.2. You can move to Laravel 12 without touching PHP at all — Laravel 12 supports PHP 8.2 through 8.5. Anyone telling you the PHP upgrade is unavoidable to reach Laravel 12 is wrong.

But it is a dead end on two clocks at once. Laravel 12 loses bug-fix support on 13 August 2026, and PHP 8.2 goes end of life on 31 December 2026. So a durable fix means landing on Laravel 13 on PHP 8.3 or above — Laravel 13 requires a minimum PHP version of 8.3, and that is the point at which the PHP floor genuinely bites. If you are going to do the work, do it once and land somewhere that buys you real runway.

The mechanics are version by version, following the official upgrade guides, rehearsed on a staging environment that mirrors production, with a zero-downtime cutover and a tested rollback. Not big-bang.

Why the upgrade stalled in the first place

Automation is cheap. Laravel Shift publishes its prices: most version shifts are $39, the Laravel 12.x shift is $29, the 13.x shift is $19, and PreShift is free. Rector automates broader refactoring for nothing.

So why is anyone stuck? Because the framework diff was never the hard part. Rector requires test coverage to verify that its changes are semantically correct — and the JetBrains survey found 32% of PHP developers write no tests at all, with 42% not regularly using code quality tools. That is the mechanism behind almost every stalled upgrade we see. You cannot safely automate an upgrade to a codebase that cannot tell you when it breaks.

Which is why we do not start with the upgrade. We start by wrapping the critical paths — checkout, login, reporting — in characterisation tests that lock in current behaviour. Then the $39 shift becomes safe, and the human work around it is what you are actually paying for.

When a rewrite is genuinely right — and when it is not

Almost never, at the whole-application level. A rewrite discards working business logic that nobody has written down, in exchange for a promise that the new version will be better. It usually takes longer than the estimate and ships fewer features than the thing it replaced.

A rewrite of a single module is sometimes the right answer, and our audits do occasionally recommend it — where the module is well-bounded, where its requirements have genuinely changed, and where repair would cost more than replacement. We put numbers against both options rather than quietly billing for the harder path.

Be sceptical of a whole-app rewrite proposed by someone who has not yet read the code. “It’s a mess, let’s start again” is frequently a statement about a developer’s comfort, not about your business.

How to avoid this happening again

• Own everything from day one. Domain, repository, hosting, third-party accounts — all in your company’s name, all the time.
• Make upgrades routine, not a project. Laravel ships annually. Budget a little time each year and you will never face a four-version leap.
• Insist on some test coverage. Not perfection — one commonly cited benchmark treats around 60% as acceptable and 75%+ as commendable. Enough to make upgrades safe is enough.
• Get documentation as a deliverable, not a favour.
• Watch the calendar, not the vibes. Put the Laravel and PHP end-of-life dates in a diary and review them annually.

Frequently asked questions

Is my Laravel version still supported?

Laravel 10 lost security fixes on 4 February 2025 and Laravel 11 on 12 March 2026 — both are fully end of life. Laravel 12 loses bug fixes on 13 August 2026 but keeps security fixes until 24 February 2027. Laravel 13 has security fixes until 17 March 2028. Then check PHP separately: 8.1 ended on 31 December 2025 and 8.2 ends on 31 December 2026.

We’re on an LTS version — doesn’t that mean we’re safe?

No, and it is worth checking what you are actually on. Laravel 6 was the final LTS release, and its security support ended on 6 September 2022. Current Laravel releases have no LTS tier — every version gets 18 months of bug fixes and 2 years of security fixes, full stop.

Can’t we just run Laravel Shift and be done?

Only if you have tests. A Shift costs $19–$39 and does the mechanical work well, but automated refactoring can only be verified as semantically correct by a test suite. The safe order is: characterisation tests first, then the automated shift, then manual work on what it could not handle.

What happens if we do nothing?

Nothing, until it doesn’t. Running end-of-life PHP or Laravel means newly disclosed vulnerabilities in your stack never get patched. Meanwhile modern packages stop installing cleanly, hiring gets harder, and the eventual upgrade gets more expensive every month you defer it — which is how an overdue upgrade becomes a rescue.

Where to start

If your Laravel project is in trouble, the first conversation is free and confidential — no judgement, no obligation. Bring what you know, even if that is “the developer stopped replying and I’m not sure what we own.”

Zorinto is a UK software development company in Slough (Zorinto Ltd, Companies House 15494238), delivering since 2019 — first as Criztec — with 75+ projects shipped, 98% client satisfaction and a 5.0 Google rating.

Read the detail on our Laravel rescue service, see how rescue engagements compare with our other work on the pricing page, or — if the recovery is done and you want to build on solid ground — look at Laravel development. When you are ready, get in touch.