Quick Answer

Laravel 12, released February 24, 2025, is intentionally a low-disruption upgrade — Laravel’s own release notes describe it as a maintenance release focused on minimizing breaking changes. Most Laravel 11 applications can upgrade to Laravel 12 without changing any application code. The three areas where enterprise teams most commonly get caught: Carbon 2 support has been removed, UUID generation now defaults to UUIDv7 instead of UUIDv4, and SVG files are no longer accepted by the image validation rule by default.

Published October 14, 2025 by Jordan Mills, Lead Engineer at NCM Technology — 7 min read

Introduction

Laravel 12 shipped on February 24, 2025, and the framework’s own release team was unusually direct about what it is: a maintenance release. Unlike Laravel 10 to 11, which restructured the application skeleton significantly, the Laravel 12 enterprise upgrade guide is a short read. Most applications upgrade cleanly without touching application code.

That said, there are three specific breaking changes that have caught enterprise teams off guard in production — not because they are complex, but because they are subtle. Date handling, UUID semantics, and file validation behave differently in ways that do not produce obvious error messages. This post covers each one and what to check before deploying a Laravel 11 to 12 upgrade to your production environment.

 

 

What Is Actually New in Laravel 12

The most visible additions in Laravel 12 are the new application starter kits. Laravel now ships official starters for React, Svelte, Vue, and Livewire. The React, Svelte, and Vue kits use Inertia 2, TypeScript, and shadcn/ui components. The Livewire kit uses the Flux UI component library with Laravel Volt. WorkOS AuthKit integration is also available as an option across the starter kits, adding social authentication, passkeys, and SSO support from day one. Breeze and Jetstream will not receive further major updates following this release.

For enterprise applications already in production, these starter kit additions are largely irrelevant — they matter for new projects. What matters for existing applications heading into the upgrade are the breaking changes.

 

 

The 3 Breaking Changes That Catch Enterprise Teams

1. Carbon 2 is removed — Carbon 3 is now required

Laravel 11 supported both Carbon 2 and Carbon 3 for date handling. Laravel 12 does not. Carbon 2 support is removed entirely, and all Laravel 12 applications require Carbon 3.

This is not usually a large rewrite, but date logic has a habit of hiding in places you do not immediately think to check: third-party packages, helper functions, test factories, and legacy service classes. Before upgrading, search your entire codebase for Carbon usage and verify that everything is compatible with Carbon 3’s API. The most common friction points are methods that changed behavior between versions — in particular, anything involving date arithmetic or comparison operations.

What to do: Run your full test suite after updating the Carbon dependency. If you do not have adequate test coverage on date-sensitive logic, this is the area to manually verify before deploying to production.

2. UUID generation defaults to UUIDv7 instead of UUIDv4

Models using Laravel’s HasUuids trait now generate ordered UUIDv7 values by default. Previously they generated random UUIDv4 values. UUIDv7 is sequential, which improves database index performance and sorting behavior — in most cases this is a genuine improvement.

Where it becomes a breaking change is if your application or any downstream system makes assumptions about UUID format. UUIDv7 encodes a timestamp component, so if you are validating UUID format anywhere or if external systems expect the random structure of UUIDv4, you need to test this explicitly. If you want to keep UUIDv4 behavior, alias the alternative trait:

use Illuminate\Database\Eloquent\Concerns\HasVersion4Uuids as HasUuids;

What to do: Search for HasUuids in your codebase. Test any API endpoints or database queries that depend on UUID format. If any external system consumes your UUIDs and expects UUIDv4 structure, explicitly opt back in to the v4 trait.

3. SVG files are no longer accepted by the image validation rule

Laravel’s image validation rule (‘image’) no longer accepts SVG files by default in Laravel 12. If your application allows SVG uploads through any admin panel, CMS, or user-facing upload flow, and those uploads are validated with the standard image rule, they will now fail validation after the upgrade.

To re-enable SVG support explicitly, use either image:allow_svg or File::image(allowSvg: true). This is a deliberate security decision — SVGs can contain embedded scripts and were considered an inconsistency in the image validation rule’s intention of accepting rasterized images.

What to do: Search your validation rules for any use of the image rule. Check whether SVG uploads are expected in any of those flows. Apply the allow_svg flag only where genuinely needed and where SVG content is trusted.

Upgrade Process for Enterprise Applications

Step	What to Do
1. Check PHP version	Laravel 12 requires PHP 8.2 or higher. Confirm your production environment meets this before touching composer.json.
2. Update dependencies	Change laravel/framework to ^12.0 in composer.json, then run composer update
3. Run the upgrade guide	The official Laravel upgrade guide documents every breaking change. Read it fully before deploying.
4. Check Carbon usage	Search for Carbon throughout the codebase. Run date-related tests explicitly.
5. Check UUID models	Search for HasUuids. Test any UUID-dependent API or query logic.
6. Check image validation	Search for the ‘image’ validation rule. Verify SVG upload flows where needed.
7. Check third-party packages	Many packages have minimum Laravel version requirements. Verify every package in composer.json supports Laravel 12.
8. Upgrade staging first	Run the full upgrade in your staging environment and run your full test suite before touching production.

 

 

Frequently Asked Questions