Preparing for Laravel 14: PHP 8.4, Symfony 8, and Breaking Changes You Can Investigate Now

The next Laravel upgrade is not just about framework compatibility. It is an opportunity to discover how much your application depends on assumptions you have never tested.

Imagine this scenario.

Your Laravel application has been running reliably for years. You update PHP, refresh Composer dependencies, run the test suite, and deploy. Everything looks successful.

Then customers start reporting unexpected login problems. A background worker behaves differently from the web application. One integration begins returning errors that never appeared in your local environment.

Nothing dramatic changed in your controllers. Your business logic looks almost identical.

Yet the system is behaving differently.

This is a hypothetical scenario, but the risks behind it are real. Framework upgrades affect more than the framework itself.

As Laravel 14 approaches, the important question is not simply whether your application will support the next major version.

It is whether you understand the dependencies, runtime assumptions, and architectural decisions that could make the next upgrade unnecessarily expensive.

And there is already enough evidence to start investigating.

Laravel 14: What We Actually Know in 2026

Let's separate confirmed information from predictions.

Laravel 13 was released on March 17, 2026. It requires PHP 8.3 or later within its officially supported PHP range, which currently includes PHP 8.3, 8.4, and 8.5.

Laravel 13 also supports Symfony 7.4 and Symfony 8 components through its Composer dependency constraints.

Symfony 8 is not a future release. Version 8.0 arrived in November 2025, and Symfony 8.1 became the stable feature release in May 2026. Symfony 8.0 has already reached the end of maintenance.

PHP 8.4, released in November 2024, introduced features including property hooks and asymmetric visibility. PHP 8.5 followed in November 2025.

Here is the relevant landscape:

Sources: Laravel release notes, Symfony release calendar, and PHP supported versions.

Laravel follows an annual major-release cadence, generally around the first quarter. A Laravel 14 release in 2027 is therefore a reasonable expectation, not a confirmed release commitment.

Likewise, Symfony 8's PHP 8.4 requirement makes PHP 8.4 a significant compatibility target, but it does not establish that Laravel 14 will require PHP 8.4 as its minimum.

That distinction matters.

Developers should plan around evidence, not assumptions presented as release announcements.

The Real Upgrade Risk Is Not Where Most Developers Look

When developers discuss a major framework upgrade, the conversation usually begins with syntax, deprecated methods, and dependency versions.

Those things matter.

But I think the more important risks exist at the boundaries between systems.

A production Laravel application rarely consists of Laravel alone.

It may include:

• PHP and its extensions.

• Symfony components used internally or directly.

• Composer packages maintained by independent developers.

• Database drivers and database-specific SQL behavior.

• Redis, queues, scheduled jobs, and background workers.

• Payment gateways, authentication providers, and third-party APIs.

• Docker images, CI pipelines, and server configurations.

Every dependency introduces another set of compatibility assumptions.

A framework can remain backward compatible while an indirectly upgraded package changes behavior. A PHP upgrade can succeed while a previously tolerated declaration begins generating deprecation warnings.

And a deployment can pass every unit test while still interrupting active sessions.

This is why I prefer to think about upgrades across three layers:

Runtime compatibility: Can the application execute correctly on the target PHP version?

Dependency compatibility: Can Composer resolve a supported, secure combination of packages?

Behavioral compatibility: Does the application still behave correctly for real users and business processes?

The first two are relatively easy to automate.

The third is where engineering judgment becomes valuable.

PHP 8.4: Prepare for More Than a Minimum Version Bump

PHP 8.4 represents another step toward a more expressive, strongly modeled language.

Two additions deserve attention: property hooks and asymmetric visibility.

Property hooks and asymmetric visibility

PHP 8.4 allows developers to control property reads and writes more precisely.

Consider a simple value object:

<?php

final class CustomerProfile
{
    public private(set) string $email;

    public function __construct(string $email)
    {
        $this->email = strtolower(trim($email));
    }
}

The private(set) declaration allows the property to be read publicly while limiting writes to the class itself.

This reduces boilerplate when modeling data with controlled mutation.

Property hooks provide another option for implementing getter and setter behavior directly within property declarations.

These improvements are useful for domain objects, data-transfer objects, and services where explicit boundaries matter.

However, I would not rush to introduce them throughout an existing Laravel application.

An Eloquent model is not simply a conventional PHP object. Eloquent uses its own mechanisms for attributes, casts, accessors, mutators, and persistence.

Replacing an established Eloquent cast or accessor with a PHP property hook without understanding the interaction is not an architectural improvement.

It is an experiment that needs testing.

My recommendation: Start adopting PHP 8.4 language features in isolated, framework-independent classes where their behavior is predictable. Treat Eloquent integrations separately.

Small deprecations can expose large maintenance problems

One PHP 8.4 change is particularly easy to overlook.

Implicitly nullable typed parameters are deprecated.

Previously:

function findCustomer(string $email = null): void
{
    // ...
}

The explicitly nullable version is:

function findCustomer(?string $email = null): void
{
    // ...
}

This may appear insignificant.

But imagine a large application with internal libraries, legacy helpers, and third-party packages that contain hundreds of similar declarations.

A PHP upgrade can reveal issues distributed across the entire dependency tree.

The appropriate response is not automatically to suppress deprecation reporting.

Instead, determine whether the warnings originate in code you control, maintained dependencies, or abandoned packages.

PHP's official 8.4 migration guide documents the relevant compatibility changes.

Before moving production, I would investigate the application on PHP 8.4 with deprecations visible in a development or CI environment.

I would also test the actual extensions used in production, including database drivers, Redis, image processing, and any native extensions.

The application starting successfully is not sufficient evidence that the runtime migration is complete.

Symfony 8: The Dependency Upgrade That Deserves More Attention

Laravel developers sometimes underestimate how much of their application runs through Symfony components.

Laravel uses Symfony packages for capabilities such as HTTP handling, console execution, processes, routing infrastructure, and mail-related functionality.

Symfony 8 therefore matters even if you never create a Symfony application.

Symfony 8 is about removing accumulated compatibility layers

Symfony 8.0 and Symfony 7.4 were released with equivalent feature sets, but Symfony 8 removed deprecated functionality accumulated during the previous development cycle.

It also raised its minimum PHP requirement to 8.4.

According to Symfony's release retrospective, Symfony 8.0 removed more than 13,000 lines of deprecated code.

That is a meaningful architectural decision.

Removing deprecated functionality makes a framework easier to maintain, but it can expose applications and packages still relying on obsolete interfaces or behaviors.

The consequences depend on which components you use and whether your dependencies rely on removed functionality.

See Symfony's official 8.0 retrospective.

Laravel 13 already supports Symfony 8

Here is a detail worth emphasizing.

Laravel 13's framework dependencies include constraints such as:

{
    "symfony/console": "^7.4.0 || ^8.0.0",
    "symfony/http-foundation": "^7.4.0 || ^8.0.0",
    "symfony/http-kernel": "^7.4.0 || ^8.0.0"
}

These constraints are taken from the Laravel 13 framework's Composer manifest.

This does not mean every Laravel 13 application automatically installs Symfony 8.

Composer must find a compatible combination across the application's entire dependency graph.

On PHP 8.3, Symfony 8 is not an option because Symfony 8 requires PHP 8.4 or higher. On PHP 8.4, Symfony 8 may be available, but another package could still restrict the allowed version.

That gives us an important conclusion:

You do not need to wait for Laravel 14 to investigate Symfony 8 compatibility.

You can begin with your existing application.

Find the packages blocking an upgrade

Composer provides useful diagnostic commands:

php -v

composer show --locked laravel/framework

composer show --locked symfony/http-foundation

composer why symfony/http-foundation

composer prohibits php 8.4

composer prohibits symfony/http-foundation 8.1.0

composer check-platform-reqs

composer audit

Run these commands within your project using a current Composer installation.

They answer different questions.

composer why identifies packages requiring another package.

composer prohibits helps identify constraints preventing a particular version from being installed.

check-platform-reqs checks the actual PHP runtime and installed extensions against package requirements.

composer audit checks dependency security advisories and related package health information.

These commands do not guarantee a successful upgrade. They provide evidence about the existing installation and dependency constraints.

If a supported Symfony version cannot be installed, investigate the blocking package rather than immediately forcing an update.

Avoid treating --ignore-platform-reqs as a solution. Bypassing a platform requirement does not make an incompatible application compatible.

For applications using Symfony components directly, I would pay particular attention to custom integrations and extension points.

The more code that depends on vendor implementation details, the more carefully those details need to be reviewed.

The Breaking Changes Worth Investigating Already Exist

It is tempting to publish a speculative list of Laravel 14 breaking changes.

I think that would miss a better opportunity.

Laravel 13's existing upgrade documentation already provides examples of changes that can expose hidden assumptions in real applications.

These are confirmed Laravel 13 changes, not announced Laravel 14 changes.

1. Request-forgery protection

Laravel 13 renamed its CSRF middleware from VerifyCsrfToken to PreventRequestForgery.

The newer middleware includes request-origin verification using the Sec-Fetch-Site header while maintaining token-based protection mechanisms.

The previous middleware classes remain available as deprecated aliases.

Why investigate this?

Because authentication and request protection often involve more than standard Laravel forms.

Applications may have embedded frontends, webhook endpoints, custom middleware exclusions, or unusual cross-origin request flows.

Not every such integration will break. But these are sensible places to test real request behavior rather than relying entirely on mocked HTTP tests.

2. Cached-object deserialization

Laravel 13's default cache configuration introduced a serializable_classes setting that defaults to false.

This is intended to strengthen protection against unsafe PHP object deserialization.

Applications intentionally caching serialized PHP objects may need explicit allow-lists or a different cache payload format.

For example, I would generally prefer caching a simple array representing a pricing snapshot rather than an entire Eloquent model with relationships and hidden internal state.

The first representation is easier to inspect and less tightly coupled to PHP class structure.

The second may be convenient initially but can introduce compatibility questions during deployment and deserialization.

3. Session serialization

The Laravel 13 application skeleton defaults session serialization to JSON.

But changing an existing application from PHP session serialization to JSON can invalidate active sessions.

For an internal administration tool, requiring users to authenticate again might be acceptable.

For a customer-facing checkout application, an unexpected session interruption may have measurable business consequences.

The correct decision depends on the application's risk profile and deployment plan.

4. Database behavior and Eloquent serialization

Laravel 13 now validates that the uniqueBy argument passed to upsert() is non-empty.

On MySQL and MariaDB, the database driver uses actual primary and unique indexes to identify conflicts, even though the Laravel API requires the argument.

An integration that previously supplied an empty uniqueBy value can now throw an exception.

Laravel 13 also changes how eager-loaded relationships are restored when serialized Eloquent model collections are deserialized, including in queued-job scenarios.

That is exactly the sort of behavior that deserves regression tests.

The source is the Laravel 13 upgrade guide.

Notice the pattern.

None of these issues requires a dramatic framework rewrite.

They involve assumptions about existing behavior that may never have been explicitly documented.

That is why upgrade preparation is fundamentally an exercise in understanding your application.

The Most Valuable Upgrade Tool Is a Test That Protects Business Behavior

A successful Composer update tells me the dependency resolver found an acceptable package combination.

It does not tell me whether my application's authorization boundaries still work.

Consider a hypothetical SaaS application where customers manage their own invoices.

A critical behavior is that one customer must never be able to change another customer's invoice.

A Laravel feature test might look like this:

<?php

namespace Tests\Feature;

use App\Models\Invoice;
use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Tests\TestCase;

final class InvoiceAuthorizationTest extends TestCase
{
    use RefreshDatabase;

    public function test_user_cannot_update_another_users_invoice(): void
    {
        $owner = User::factory()->create();
        $otherUser = User::factory()->create();

        $invoice = Invoice::factory()
            ->for($owner)
            ->create(['status' => 'draft']);

        $this->actingAs($otherUser)
            ->patchJson(
                "/api/invoices/{$invoice->getKey()}",
                ['status' => 'paid']
            )
            ->assertForbidden();

        $this->assertDatabaseHas('invoices', [
            'id' => $invoice->getKey(),
            'status' => 'draft',
        ]);
    }
}

This example uses standard Laravel testing APIs supported in Laravel 13.

It assumes the hypothetical application has an Invoice model, the relevant factories and relationship, an authenticated invoice-update endpoint, and policy enforcement that returns HTTP 403.

Those application-specific pieces must exist for the test to run.

The value of the test is not that it checks a Laravel feature.

It protects a business rule.

If an upgrade accidentally changes how authorization middleware, route binding, or policy integration behaves, this test can expose the regression.

I would apply the same thinking to other important workflows:

• A payment must not be captured twice.

• A queued notification must not send to the wrong customer.

• A refund must not be issued without authorization.

• An API integration must handle retries safely.

• An expired subscription must not retain access indefinitely.

Tests around these behaviors provide more long-term value than tests that merely reproduce framework implementation details.

A framework version can change. Those business promises usually cannot.

A Practical Laravel 14 Preparation Plan

Here is how I would approach preparation before Laravel 14's official release.

Phase 1: Understand your current application

Document the actual Laravel version, PHP version, Symfony components, Composer dependencies, extensions, database versions, and deployment environment.

Identify abandoned dependencies, custom service providers, direct vendor integrations, and code with weak test coverage.

Pay particular attention to packages that are maintained infrequently but sit inside critical workflows.

Deliverable: a dependency and compatibility inventory, not an immediate upgrade.

Phase 2: Establish a trustworthy baseline

Run the full test suite on the current supported application stack.

Record existing failures before changing anything.

Add regression tests for authentication, authorization, billing, scheduled jobs, queues, and critical API integrations.

Use the same database family as production when testing database-specific behavior. SQLite alone cannot validate every MySQL or PostgreSQL query.

Deliverable: a baseline that distinguishes existing defects from upgrade regressions.

Phase 3: Build a compatibility matrix

For an application already compatible with Laravel 13, useful investigation targets include:

These are proposed test configurations, not guarantees that every application's package graph can resolve them.

Change one major variable at a time when diagnosing failures.

Otherwise, you can spend hours trying to determine whether a regression came from PHP, Symfony, Laravel, or an unrelated dependency.

Phase 4: Test the operational boundaries

A web request is only one part of a Laravel application.

I would also test:

Queue workers: Can jobs created by an earlier application version still be processed safely during a rolling deployment?

Sessions: Will a configuration change log users out, and has that behavior been approved?

Integrations: Are HTTP headers, signatures, retries, timeouts, and error handling behaving as expected?

Performance: Have database query counts, memory use, queue latency, and response times changed under representative workloads?

Rollback: Can the previous application version run against the current database schema if deployment is reversed?

This last point deserves special attention.

Rolling back application code does not automatically reverse database migrations or undo data transformations.

A credible upgrade plan must account for both.

Phase 5: Upgrade when the evidence supports it

Once Laravel 14's official release notes and upgrade guide become available, compare them against the inventory and tests already prepared.

Update dependencies in a separate branch, using Composer's dependency diagnostics and appropriate full-dependency resolution.

Run automated tests, conduct targeted manual checks, and deploy through a controlled process.

For critical systems, prefer a canary or staged rollout with monitoring and a documented rollback decision.

The objective is not to prove that an upgrade is effortless.

It is to make the risks visible before customers discover them.

What About AI-Assisted Laravel Upgrades?

AI is increasingly relevant to how developers investigate large codebases.

Laravel's own tooling reflects this change.

The Laravel 13 upgrade guide documents an AI-assisted upgrade workflow using Laravel Boost. In September 2026, the first-party Laravel AI SDK also reached version 1.0, reflecting a broader investment in AI-native development capabilities.

But AI changes the speed of code modification more easily than it changes the responsibility for correctness.

The 2026 Stack Overflow Developer Survey illustrates that distinction.

Among respondents to its AI-trust question, 48% said they trust AI output when they can easily verify it. Only 6.6% said they trust it for many tasks including important work decisions.

That makes sense to me.

AI can be useful for locating deprecated APIs, explaining unfamiliar dependencies, suggesting tests, or reviewing upgrade diffs.

But an AI-generated change to payment authorization still needs human review and executable verification.

I would treat AI as an accelerator for investigation, not as an authority on whether production is safe.

The best upgrade workflow combines automated tooling, clear acceptance criteria, and engineers who understand the consequences of failure.

What Eight Years of Laravel Development Has Taught Me

After nearly eight years working with Laravel, I have become more interested in the decisions surrounding framework code than in framework syntax alone.

Laravel's developer experience is one of its greatest strengths. It allows teams to build meaningful functionality quickly without repeatedly solving common infrastructure problems.

But developer convenience and architectural simplicity are not always the same thing.

A clever abstraction can save time today while making dependency changes harder to understand later.

A direct call to a vendor's internal implementation may work perfectly until that implementation disappears.

And an application with hundreds of passing unit tests can still be vulnerable if those tests ignore the behaviors customers actually depend on.

The principle I would apply today is straightforward:

Use frameworks aggressively for the problems they solve well. Build explicit boundaries around the decisions your business cannot afford to get wrong.

For example, keep billing rules, authorization decisions, and important integration contracts understandable and testable without requiring developers to trace an entire request through every framework layer.

That does not mean building an elaborate abstraction around every Laravel feature.

Overengineering can create as much maintenance difficulty as excessive coupling.

It means choosing boundaries deliberately.

This approach makes future framework upgrades less intimidating because fewer critical assumptions are hidden.

The Business Case for Preparing Early

A client rarely cares which Symfony component handles an HTTP request.

They care whether customers can log in, payments work, and the application remains available.

That is the connection developers must make when discussing framework upgrades with business stakeholders.

There are several potential costs to delaying maintenance:

Security exposure: Unsupported runtimes and dependencies may stop receiving security updates.

Maintenance pressure: More accumulated incompatibilities can turn a manageable upgrade into a larger project.

Delivery delays: New features may become harder to implement when essential packages no longer support the existing stack.

Operational risk: A rushed upgrade may increase the possibility of user-facing regressions.

But upgrading has costs too: engineering time, testing infrastructure, third-party package updates, and deployment coordination.

The right approach is not to upgrade everything immediately.

It is to reduce uncertainty continuously, so an eventual upgrade becomes a planned engineering investment rather than an emergency.

Laravel's current support policy provides bug fixes for 18 months and security fixes for two years per major release. Laravel 12's documented security support ends February 24, 2027, while Laravel 13's extends to March 17, 2028.

Those dates offer practical planning inputs for CTOs, agencies, and teams maintaining client applications.

Should Every Laravel Application Move Quickly to the Newest Stack?

No.

There is a reasonable counterargument to aggressive upgrade planning: stability has value.

Symfony 7.4 is a long-term support release, with security support scheduled through November 2029. For a conservative environment, a maintained LTS dependency may be more appropriate than rapidly adopting every new feature release.

A stable Laravel application with strong security controls, supported dependencies, and good monitoring does not automatically become a better product because its components have newer version numbers.

There are also situations where a different architectural choice makes sense.

A team building an application deeply around Symfony-specific conventions might benefit from using full-stack Symfony rather than relying on those internals through Laravel.

Similarly, a small product with limited resources may get greater immediate value from improving test coverage, fixing production issues, or removing a risky abandoned dependency than from experimenting with upcoming framework versions.

My position is not that early adoption is always good.

Early investigation is valuable because it allows adoption to happen at the right time.

That is a different argument.

My Prediction: Upgrade Readiness Will Become an Engineering Capability

Over the next 12–24 months, I expect AI-assisted maintenance workflows, dependency analysis, and automated refactoring to become increasingly normal parts of PHP development.

That is a prediction, not a confirmed Laravel roadmap.

I also expect engineering teams to place more emphasis on verifying behavior rather than simply verifying that generated code compiles and tests pass.

More automation will make changes easier to produce.

It will not eliminate the need to understand them.

For Laravel developers, this creates an opportunity.

The developer who can explain compatibility constraints, identify architectural risk, design meaningful regression tests, and communicate business impact will provide value beyond knowing the latest framework APIs.

Those skills are transferable across Laravel, Symfony, and other technology stacks.

And they become more important as applications accumulate integrations, data, customers, and years of operational history.

Final Thoughts: Don't Wait for Laravel 14 to Understand Your Application

Think back to the hypothetical deployment at the beginning of this article.

The application starts. Composer succeeds. The tests pass.

Yet users experience problems.

The mistake was not necessarily upgrading.

The mistake was assuming that technical compatibility automatically guaranteed behavioral compatibility.

Laravel 14 will eventually bring its own documented requirements and changes. Some may be easy to adopt. Others may matter only to specialized applications.

We do not need to invent those changes today to start doing useful work.

PHP 8.4 is available. Symfony 8 is available. Laravel 13 already supports meaningful compatibility investigations. The official upgrade guides contain concrete behaviors worth reviewing.

The opportunity is to use this time to understand our systems better.

The best preparation for Laravel 14 is not predicting every breaking change. It is building an application whose important behavior you can confidently verify when change arrives.

That is the kind of engineering maturity that outlasts a framework release.

And it raises a question worth discussing:

If your Laravel application had to move to a new PHP and Symfony stack tomorrow, what would worry you most: dependency compatibility, missing tests, or the parts of the system nobody fully understands anymore?

Frequently Asked Questions

1. When will Laravel 14 be released?

As of October 15, 2026, Laravel 14 has not been officially released, and a confirmed release date has not been established in the official sources reviewed. Laravel generally follows an annual major-release cycle around Q1, making 2027 a reasonable expectation rather than a guaranteed date.

2. Will Laravel 14 require PHP 8.4?

That has not been officially confirmed. Laravel 13 requires PHP 8.3 or later and officially supports PHP 8.3 through 8.5. Symfony 8 requires PHP 8.4 or higher, but that does not independently establish Laravel 14's minimum PHP requirement.

3. Does Laravel 13 support Symfony 8?

Yes. Laravel 13's Composer manifest permits Symfony 7.4 or Symfony 8 for several core Symfony components. Your ability to install Symfony 8 also depends on PHP 8.4 or higher and the constraints of other installed dependencies.

4. Can I start preparing for Laravel 14 while using Laravel 12 or 13?

Yes. Audit your Composer dependencies, check PHP compatibility, review the latest official upgrade guide, improve regression tests, and document your deployment assumptions. Do not change your production framework version solely to prepare for an unreleased major version.

5. What commands help identify Laravel upgrade compatibility problems?

Start with composer show --locked, composer why, composer prohibits, composer check-platform-reqs, and composer audit. These help identify installed versions, dependency relationships, version constraints, platform requirements, and security advisories.

6. Should I use AI tools to upgrade a Laravel application?

AI tools can help analyze dependencies, identify deprecated usage, and generate candidate refactors. However, developers should review changes and verify them with automated tests, integration tests, and deployment checks. AI-generated modifications are not proof of production compatibility.