Laravel Modernization Decision Framework: Upgrade, Rewrite or Wait?

Most teams I talk to don't lack the will to modernize a legacy Laravel application. especially given why enterprises keep choosing Laravel in the first place and don't want to walk away from that investment.

Do you upgrade in place, or is this one of the cases where a partial rewrite earns its cost? Is this urgent, or is it safe to leave alone for another year? How much of this can you scope before committing real budget, rather than finding out six weeks in?

Answering those well takes a framework, not a gut call, and this is the one I use. It grew out of the modernization assessments I run at Cubet, an official Laravel Partner. I use it to separate applications that are straightforward upgrade candidates from the ones that need a more deliberate strategy, before we ever get to Continuum, our modernization program.

The pattern holds across most of the legacy Laravel codebases I've been inside: the hardest decisions are rarely about the framework version itself. They're about a payment package that's been unmaintained since Laravel 8, business logic buried in a controller nobody currently on the team wrote, a test suite that covers the happy path and nothing else, and data you genuinely cannot afford to get wrong. This framework is built around those things, not the version number.

How to use this framework?

Work through the sections below in order. Each one narrows the next: how upgradeable the application is shapes whether a rewrite is worth considering, that shapes your risk tolerance and technical approach, and your success criteria give everyone a way to know, later, whether it worked.

None of this requires a specific vendor, tool, or methodology. It's the set of questions I'd want answered regardless of who ends up doing the work.

How long does a Laravel upgrade take?

Your current Laravel version is a useful first signal, not a reliable estimate on its own.

That's the same table I'd sketch on a whiteboard in a first conversation, and it's the same one I mistrust the moment I see a Laravel 7 or earlier app with a hand-rolled ORM extension or three custom service providers nobody's touched since 2019. Laravel doesn't allow skipping versions, so an application several releases behind has to pass through every one on the way to current, per Laravel's own release and support policy. The hop count is real. It just isn't the whole estimate. and knowing what changed in a recent release like Laravel 11 helps you judge how much of that count is genuine framework change versus your own technical debt. What moves the number:

• PHP version, and how far it has to move alongside Laravel, per PHP's own supported-versions policy; jumping two PHP major versions at once tends to surface more deprecation warnings than the Laravel upgrade itself does

• Dependency compatibility: how many packages in composer.json have no tagged release for the target Laravel version, versus ones that just need a version constraint bump

• Existing test coverage, because without it every upgrade step is a manual regression hunt instead of a php artisan test run

• Application size and how much custom code sits outside the framework's own conventions

• How many custom or unusual packages are in play, and how many of those are forks nobody's tracked back to upstream

• Database and data-model complexity

• Number and criticality of third-party integrations

• Deployment architecture, and how much of it changes alongside the code

• General technical debt: undocumented logic, dead code paths, inconsistent patterns from three different engineering regimes

Two applications on the same starting version can need very different amounts of work. That's exactly what a proper assessment is for.

How do I assess a legacy Laravel application?

When I assess a Laravel application for modernization, I score it across six dimensions, not just "what version is it on."

1. Upgradeability. Current Laravel and PHP version against the latest supported release, and how many hops separate here from current.

2. Dependency health. What proportion of Composer packages are actively maintained versus abandoned, and how many have no drop-in replacement for the target version. This is usually the single biggest surprise in a Discovery-style assessment: a package that looked fine two years ago has often gone quiet on Packagist since.

3. Business-logic understanding. Whether the team currently supporting the application can explain what it does and why, or whether large parts of it are a black box, typically visible in fat controllers, missing domain models, and Eloquent models doing far more than persistence.

4. Test readiness. What automated coverage exists, whether it's PHPUnit or Pest, and how much of the application's real behavior could be verified before and after a change, not just whether the suite is green.

5. Deployment and data risk. Downtime tolerance, data criticality, schema complexity, and how mature the current CI/CD, rollback, and backup-restore practices are.

6. Modernization cost. Not a rule of thumb, but a number derived from the five dimensions above, applied to this specific application.

These six dimensions are the actual substance of a modernization assessment, and they're what Continuum's Insight stage formally scores as the Continuum Score. Anyone quoting a fixed price or timeline without working through them for the application in question is estimating, not assessing.

Should I upgrade or rewrite my Laravel application?

This is where I've watched modernization decisions go wrong in both directions: teams patch an application that needs to be rethought, or scrap one that had years of proven value left in it because the code just felt old.

Rather than a hard rule, weigh the signals below against each other for the specific application.

This isn't a scorecard to tally and act on mechanically. A single strong signal, like a truly fundamental data-model change, can outweigh several weaker ones pointing the other way. The matrix exists to make the reasoning explicit, not to replace judgment with arithmetic.

As a default, though: I'll almost always recommend an in-place, sequential upgrade first. It costs less, carries less risk, and preserves institutional business logic that a rewrite would otherwise reconstruct from scratch, usually incompletely, and usually at several times the cost anyone budgeted for. A full framework migration means rebuilding years of edge-case handling and integration logic in an unfamiliar stack. Reach for a partial rewrite when the matrix above clearly points that way, not by default.

When does a Laravel rewrite make sense?

Rarely as the first option, but sometimes as the right one: when the current architecture genuinely can't support what the business needs next, when a compliance or data-residency requirement forces a new architecture regardless of framework version, or when the honest answer to "how well understood is the business logic" is that almost nobody knows anymore and the application has drifted so far from active use that rebuilding it clean is simpler than untangling it. Outside of cases like these, rewriting is often a response to how old the code looks rather than to a clearly defined business or architectural need.

When should you wait?

Not every legacy Laravel application needs to be modernized this quarter. Waiting is a legitimate answer when:

• the application is stable and its Laravel and PHP versions are still within active security support

• there's no meaningful business driver forcing the decision right now

• the application sees low change velocity, with few new features or integrations planned

• modernization would provide little measurable business value at this time

• its dependencies remain healthy and actively maintained

Don't wait, no matter how stable the application feels today, once technical debt starts constraining product development, security, compliance, scalability, or operational reliability, or once the framework or PHP version is approaching the end of its support window. The cost of waiting stops being flat at that point: Laravel's no-version-skipping rule means every additional deferred year can add another mandatory hop, and dependencies healthy today are more likely to be abandoned by the time the upgrade eventually happens.

Define your risk tolerance

Before any technical decisions get made, three business questions need real answers, not assumptions.

Start with the downtime budget. Zero-downtime cutover is achievable with a blue-green deployment, but it adds cost and time relative to a scheduled maintenance window. Get specific: is a two-hour window on a Sunday night acceptable, or does a customer-facing SLA rule that out? This is a business call, and it changes the technical approach, right down to whether you're running a dual-write period on the database or not.

Next, data criticality tiers. Not all data carries the same risk if a brief reconciliation window is needed. Separate what truly cannot tolerate even a short discrepancy (financial ledgers, patient records, anything with legal consequences) from what can (analytics events, cached reports). This determines where manual sign-off is mandatory and where an automated row-count-and-checksum reconciliation is enough.

Finally, identify any non-negotiable compliance gates: controls that have to be verified before go-live, such as a pending audit date, versus ones that can be verified as part of ongoing governance afterward. Knowing which is which affects sequencing, not just scope.

Set success criteria before work begins

Agree these in writing at the start, not informally at the end. A modernization without pre-agreed success criteria is unfalsifiable: there's no way to know afterward whether it worked. At minimum, define:

• Target Laravel and PHP version, and why that target, not automatically "the latest"

• Minimum test coverage threshold for business-critical modules

• A clean security scan pass, with no unresolved CVEs at or above an agreed severity

• A defined performance benchmark, such as response time under a specified concurrent load

• Zero unreconciled data discrepancies across the tiers defined above

• Named business-stakeholder sign-off per module, not just a technical sign-off

How much does Laravel modernization cost?

Anyone who quotes a number before working through the assessment above is guessing. What drives cost is a small, identifiable set of factors: the number of major-version hops required, the volume of custom code that needs review, gaps in existing test coverage that have to be closed before changes can be verified safely, the number of dependencies with no maintained upgrade path, the complexity of the data model, and how much infrastructure or deployment change gets bundled into the same project.

That's why a credible modernization engagement starts with a scoped, fixed-price assessment rather than a fixed-price implementation quote. The assessment turns those cost drivers into an actual number for a specific application, instead of a rule of thumb applied across every legacy Laravel codebase regardless of its condition.

Questions to answer before you start

Should this be budgeted as capex or opex? 

Most organizations capitalize modernization work as an extension of an existing asset's useful life, similar to other software capitalization treatment, but this depends on accounting policy and jurisdiction. Confirm with finance before finalizing the budget category.

What should be explicitly excluded, so it doesn't become a surprise cost? 

Net-new feature development, infrastructure or hosting migration, changes required on a third-party vendor's side of an integration, and design or UX overhaul. Any of these can be scoped as an addition, but a modernization budget shouldn't assume they're included by default.

What do we own at the end of the engagement? 

Full IP ownership of the code, plus documentation covering what was assessed, what was decided, and what was tested. The tooling involved in a Laravel upgrade (Laravel Shift, Rector, PHPStan) is standard and commercially available, not proprietary to any one vendor, so an internal team can operate independently afterward.

How do we know the modernized application behaves identically to the old one?

Through functional parity testing, not just a passing suite: before-and-after behavior comparison, and, for the most critical modules, a period of running old and new logic in parallel to compare real output before fully cutting over.

What happens if we start a modernization and need to pause halfway? 

A good reason to insist on phase-based delivery with a signed-off deliverable at each stage, rather than one long continuous build. Done that way, every completed stage leaves the application in a working, deployable state, rather than leaving you with a half-finished, unusable result.

Readiness checklist

Before starting a structured assessment, with any partner or internally, have these ready:

• Access to the source repository and a staging or production-like environment

• A named business stakeholder per major module who can confirm business rules

• Current hosting and infrastructure documentation

• A list of third-party integrations and how critical each one is

• Any known compliance certifications, audits, or deadlines that intersect with the work

• Downtime tolerance and data-criticality tiers defined, per the risk section above

• An executive sponsor who can approve sign-offs and any changes to scope

Where this fits with Continuum

This framework doesn't assume a specific vendor; it's the reasoning I run through before recommending an approach for any Laravel application. Continuum, Cubet's structured framework for executing a Laravel modernization, is what happens once that reasoning is complete.

Continuum's first stage, Insight, is this framework run formally against a specific application: the same six dimensions above, scored as the Continuum Score, and translated into a costed, sequenced plan, delivered as a fixed-price, standalone engagement with no obligation to continue.

If you can't confidently answer the questions in this framework for your own application, the next step isn't to start upgrading. It's to assess the application first. That's what a Continuum Discovery engagement is for: establish the current state, identify the real modernization risks, compare the viable paths, and produce a costed roadmap before any implementation begins. 

Read more about Continuum, Cubet's Laravel modernization framework, or get in touch to scope a Continuum Discovery engagement.