How Much Does It Cost to Rescue a Neglected Laravel Codebase?

The other three articles in this series covered what happens when your Laravel developer leaves, what happens when nobody is applying security updates, and the seven warning signs that your application has crossed from asset to liability. If you recognised your situation in any of those pieces, you are now facing the question they were all leading to.

The uncomfortable discovery, which the data makes unavoidable, is that every figure in this article is a multiple of the monthly cost of not having needed the article at all.

What it costs to find out where you stand

The first thing any competent Laravel specialist will tell you is that they need to look at the codebase before they can quote for fixing it. That assessment is not free — or rather, when it is free, it is usually a sales conversation dressed as a technical review.

What you actually need at this stage is not just a list of problems. You need a technical assessment, an architecture review, a phased roadmap with budget ranges, and an honest recommendation on whether to fix, refactor, or rebuild. That is considerably more than a code audit — and the pricing reflects the difference.

A standalone code audit — someone running automated tools and writing up findings — costs £2,000 to £8,000 in the UK market, estimated from published contractor rates of £400–£550 per day (IT Jobs Watch) at three to ten days of work. No UK Laravel agency publishes a fixed price; all require a consultation before quoting. International specialists who do publish — Mastering Laravel in the US at $2,500–$3,500 (masteringlaravel.io), DevCom at $5,000–$16,000 (devcom.com) — give some sense of the range. But a code audit alone tells you what is wrong. It does not tell you what to do about it, in what order, at what cost, or whether you should be building at all.

Rocking Tech's Platform Discovery Sprint is designed for exactly this situation. It is a fixed-fee, three-week engagement at £4,500 that produces a 15–20 page written report covering technical assessment, architecture review, technology recommendation, a phased roadmap with budget ranges per phase, a risk assessment, and a build-buy-or-fix recommendation — including the option of "don't build, use off-the-shelf." For applications that already exist and need rescuing, it includes a Code Health Scorecard: automated scanning with SonarQube and PHPStan plus a manual expert review, producing a severity-prioritised issue list with a fix, refactor, or rebuild recommendation per component.

The fee is credited in full against any subsequent build or remediation engagement signed within 30 days. If you take the deliverable elsewhere — which you are explicitly welcome to do — it stands as a complete, portable document. You own everything specific to your project.

At £4,500, the Discovery Sprint sits between a basic code audit and a comprehensive one — but delivers something neither provides: a decision-ready roadmap with costs attached. It is the difference between being told your roof is leaking and being handed a builder's quote with options, phases, and a timeline.

What upgrading actually costs

If the assessment confirms that your application is running end-of-life PHP or Laravel versions — and given that approximately 38–45% of PHP applications are running unsupported versions according to both W3Techs and Zend's 2025 PHP Landscape Report (zend.com), the probability is not small — the first remediation step is upgrading.

As of March 2026, only Laravel 12 receives patches. Laravel 11's security support ended earlier this month. Everything from Laravel 10 downwards has been end-of-life for months or years. The version support timeline is covered in detail in Signs Your Laravel Application Is Becoming a Liability — if you haven't checked your composer.json yet, that article explains exactly how and why.

The cost of upgrading depends on two things: how many versions you need to jump, and how much custom code the application contains.

Laravel Shift (laravelshift.com), the industry-standard automated upgrade tool, handles the mechanical parts — Composer dependency updates, deprecated method renames, configuration file changes, middleware signature updates. It costs $29–$39 per version jump, and it requires incremental upgrades: you cannot skip from Laravel 6 directly to Laravel 12. Upgrading from Laravel 6 to 12 means six sequential shifts at approximately $234 total for the tool itself. From Laravel 8 to 12, roughly $146.

But the tool only handles the parts that follow Laravel's conventions. Third-party package compatibility, custom business logic, proprietary libraries, and comprehensive testing all require a developer. Laravel Shift's own FAQ states that small applications without many dependencies may be upgraded within a few hours, while larger applications with lots of dependencies or customisations may take around twenty hours (laravelshift.com).

Synthesising published case studies and UK contractor rates, the realistic cost range looks like this:

A simple application — under 30,000 lines of code, fewer than twenty packages, one or two version jumps — might cost £200–£1,500 including the Shift tool and a few hours of developer review.

A medium application — 50,000 to 100,000 lines, thirty to fifty packages, three or four version jumps — runs £2,500–£6,500 at UK rates once you factor in the manual work, testing, and package compatibility resolution.

A large or complex application — over 100,000 lines, fifty-plus packages, five or more version jumps — costs £6,500–£25,000 or more. Zend, which provides enterprise PHP migration services, states plainly that direct migration costs can range from a few thousand to hundreds of thousands of dollars (zend.com). Bark.com, a UK company with seven million customers, saved over 500 hours of engineering work by using Zend's professional migration services for their PHP modernisation (zend.com) — giving some indication of what a DIY approach would have consumed.

The variables that drive cost upward are predictable: abandoned or unmaintained third-party packages that need replacing, heavy customisation that doesn't follow Laravel conventions, absence of automated tests (32% of PHP developers still don't write tests, according to JetBrains' 2025 survey (jetbrains.com)), and cross-major PHP version jumps that introduce breaking changes in the language itself.

What rescue and remediation costs

Upgrading versions is the structural foundation. But a neglected codebase usually needs more than a version bump. The accumulated problems — the ones covered in this series' diagnostic articles — require remediation work that sits on a spectrum from targeted fixes to full reconstruction.

No UK Laravel agency publishes fixed pricing for rescue projects. The estimates below are derived from published UK contractor and agency rates applied to documented project scopes.

Emergency security patches — the developer-left-and-something-broke scenario — typically take one to three days and cost £1,500–£4,000 at agency rates. If it's out-of-hours or urgent, expect a 20–40% premium. One UK source documented an average emergency repair cost of £2,847.

Planned remediation — refactoring problematic modules, updating dependencies, adding test coverage, resolving architectural issues identified in an assessment — is measured in weeks, not days. A four-to-eight-week remediation sprint with one or two developers runs £15,000–£40,000 depending on scope and severity.

Partial rebuild — replacing the most damaged components while preserving what works — takes three to six months and costs £40,000–£100,000. This is where Martin Fowler's Strangler Fig pattern applies: gradually replacing legacy components with new ones, running both systems in parallel until the old parts can be retired. Fowler's assessment, updated in August 2024, is blunt — full replacement plans "go down in flames most of the time" (martinfowler.com).

Full rebuild — starting from scratch — takes six to twelve months or more and costs £80,000–£250,000+ for a typical business application. Steadfast Collective, a Laravel Platinum Partner, shows Clutch-verified project ranges of £10,000–£200,000 (clutch.co). Box UK, a Welsh agency, has a single ongoing Laravel engagement documented at approximately £300,000 (clutch.co).

The fix-versus-rebuild question

At some point during the assessment, the question surfaces: is it cheaper to fix this or start again?

The software industry has been arguing about this for twenty-six years, since Joel Spolsky published his canonical essay calling full rewrites "the single worst strategic mistake that any software company can make" (joelonsoftware.com). His reasoning: old code contains years of accumulated bug fixes and edge-case handling that look ugly but represent hard-earned knowledge. Throw it away and you throw away everything it learned.

The argument has aged well. Netscape's rewrite of Navigator took three years, produced no version 5, and handed the browser market to Internet Explorer. Digg's v4 rebuild lost 26–30% of US traffic in a single month. The pattern is well-documented.

But the counterargument has sharpened too. Modern tools provide higher abstraction layers. AI-assisted development has changed the economics. Daniel Schwartzer, writing on CyberArk's engineering blog, argues that blindly following "never rewrite" in the 2020s will cost a fortune.

The pragmatic middle ground, supported by the data, is that the answer depends on four things. How deep is the technical debt — surface-level issues in otherwise sound architecture, or fundamental structural problems? How much of the codebase needs changing — 20% or 80%? Is the current technology stack still viable for the next three to five years? And critically, can the business afford to pause feature delivery for the duration of a rebuild?

Doug Bradbury at 8th Light developed a quantitative model for rewrite costs that accounts for three compounding factors most estimates miss (8thlight.com). First, the existing application keeps evolving during the rebuild — if your rebuild team is three times faster than the original development, add 50% to estimates just for catch-up. Second, there are always undiscovered features — typically 25% more scope than initially identified. Third, feature-for-feature parity is never enough — customers expect improvement, adding roughly 30% more work. His formula turns a one-year estimate into 2–2.5 years in practice.

The honest recommendation, in almost every case, is to avoid full rewrites. Fix what is broken. Upgrade what is outdated. Replace components incrementally. The Strangler Fig approach is slower but it keeps the application running, keeps revenue flowing, and doesn't bet the business on a multi-month project that historically fails more often than it succeeds.

How long all of this takes

Timelines matter as much as costs, because the application does not stop ageing while the rescue is in progress. Every month of remediation is another month of accumulated risk on the parts that haven't been fixed yet.

A Discovery Sprint — technical assessment, architecture review, and phased roadmap — takes three weeks from kickoff to final presentation.

A version upgrade using Laravel Shift runs in minutes for the automated portion. The manual review, testing, and package compatibility work takes one to three weeks for a straightforward application, and one to two months for a complex one with many dependencies. Multi-version jumps — Laravel 5 to 12, for instance — can take three to twelve months for large applications.

A planned remediation sprint of four to eight weeks is realistic for resolving the priority findings from an assessment without attempting to address everything at once.

A partial rebuild using the Strangler Fig approach runs three to six months, with the application remaining operational throughout. A full rebuild takes six to twelve months or more — and the data on overruns is sobering. Bradbury's research at 8th Light shows that rewrite projects routinely take four to ten times longer than estimated once catch-up costs, undiscovered scope, and adoption enhancements are factored in.

The single most common cause of timeline overruns in rescue work is inadequate test coverage. Without automated tests, every change requires manual verification, every upgrade requires exploratory testing, and every deployment carries the risk of undetected regression. The 32% of PHP developers who don't write tests — JetBrains' figure — are building applications that are significantly more expensive to rescue than they needed to be.

The number that makes all of them look expensive

A managed Laravel support retainer in the UK market runs between £450 and £2,000 per month depending on scope and response time requirements. Steadfast Collective, a Laravel Platinum Partner, starts at £1,400 per month for full team access including strategy, design, and development (steadfastcollective.com). LaraLink starts at £750. At the other end, basic website maintenance from generalist agencies starts below £100 — but that is CMS button-clicking, not the kind of support a custom Laravel application requires.

At £450 per month — the entry point for Rocking Tech's Laravel support retainer — the annual cost is £5,400. That covers security patch application, dependency monitoring, version upgrades, server monitoring, and emergency response for the application. It is, by a considerable margin, the smallest number in this article.

The comparison is not subtle, but it is worth stating explicitly. £5,400 per year is less than a single average cyber breach for a UK SME (£6,400, AMVIA 2026). It is a fraction of a single emergency remediation project (£3,000–£7,000). It is roughly 1/10th of a planned remediation sprint (£15,000–£40,000). It is 1/15th to 1/45th of a full rebuild (£80,000–£250,000+). And it is approximately 1/570th of the fine the ICO levied on Advanced Computer Software Group for leaving a known vulnerability unpatched — a figure we covered in detail in Laravel Security: What Happens When Nobody's Applying Updates.

Cross-industry research on preventive versus reactive maintenance consistently finds a cost multiple of three to nine times. The BOMA Preventive Maintenance Guidebook puts it at three to nine. The Marshall Institute at two to five. De Sitter's Law of Fives, from civil engineering, says neglected maintenance costs five times more to repair, and neglected repairs cost twenty-five times more to rebuild. In software specifically, the Standish Group finds that post-deployment modifications typically cost three to four times the original development cost.

The pattern across every data source cited in this series is the same. The cost of maintaining a Laravel application is small, predictable, and constant. The cost of rescuing one is large, unpredictable, and grows with every month of neglect. The gap between the two is not 10% or 20%. It is an order of magnitude — and it compounds.

What to do next

If you have read this far, you are probably in one of three positions.

You know your application needs attention but you don't yet know the scope. The Platform Discovery Sprint — £4,500, three weeks, fully credited against any subsequent engagement — will tell you exactly where you stand, what the options cost, and whether to fix, refactor, or rebuild. It is the first step for every rescue conversation.

You know the scope and it is manageable. A maintenance retainer at £450 per month covers security patches, dependency updates, version upgrades, monitoring, and emergency response. It is the structural fix for the pattern described across all four articles in this series — the pattern where a small, predictable cost is repeatedly deferred until it becomes a large, unpredictable one.

You know the scope and it is serious. A rescue project — remediation, partial rebuild, or full rebuild — needs proper scoping before anyone quotes a number. The Discovery Sprint produces a written roadmap with phased costs, so you know what you are committing to before you commit.

Whichever position you are in, the one thing the data consistently says not to do is nothing. Every month of inaction moves you further along the cost escalation curve — and further away from the flat line at the bottom where maintenance sits.