Laravel 11 to 12 / 13 upgrade planning

Laravel 11 is now past security support. The official Laravel release policy gives bug fixes for 18 months and security fixes for 2 years. Laravel 11 was released on March 12, 2024, its bug fixes ended September 3, 2025, and its security fixes ended March 12, 2026.

Source facts last checked May 3, 2026: Laravel 13 release notes and support policy.

That does not mean every Laravel 11 application is broken today. It means Laravel 11 is no longer the version you should choose as a destination. If you are planning work now, the decision is usually Laravel 12 as the conservative landing point or Laravel 13 as the longer-run baseline.

Start with the destination

The wrong question is “how do we upgrade Laravel 11?” The better question is “what supported baseline should this system run for the next two years?”

Laravel 12 supports PHP 8.2 through 8.5 and receives security fixes until February 24, 2027. Laravel 13 requires PHP 8.3 or newer and receives security fixes until March 17, 2028. That PHP requirement is the first fork in the plan.

If production cannot move to PHP 8.3 safely yet, Laravel 12 is the practical target. If PHP 8.3 or 8.4 is already viable, Laravel 13 gives a longer support window.

Inventory the Laravel-specific surface

Before changing composer.json, map the parts of the app that Laravel upgrades usually touch.

• Laravel version and exact patch level
• PHP version used by web, CLI, queues, and scheduler
• first-party packages: Horizon, Cashier, Passport, Sanctum, Scout, Telescope, Octane
• authentication stack and starter kit history
• queue drivers and failed-job handling
• scheduler commands and cron entry
• custom service providers and macros
• middleware stack
• broadcasting, events, notifications, and mail transport
• filesystem disks and signed URL behavior
• deployment hooks: config cache, route cache, queue restarts, migrations

Laravel upgrades fail most often in the glue code around the framework, not in controllers that look simple on a read-through.

Run Composer as a planning tool

Composer should be used to expose blockers before any production change.

Work in a branch and ask Composer what prevents the target:

• packages that do not allow Laravel 12 or 13
• packages that require an older PHP version
• abandoned or renamed packages
• conflicts between first-party Laravel packages
• private packages that need their own constraints updated

Do not solve every conflict in one commit. Group blockers by owner: framework, first-party package, third-party package, private package, and app code. That grouping becomes the upgrade estimate.

Decide 12 first or 13 direct

For many Laravel 11 systems, Laravel 12 is a low-drama step because it was intentionally light on breaking changes. Laravel 13 is also positioned as a relatively minor upgrade, but it raises the minimum PHP version to 8.3 and introduces a longer support window.

Use Laravel 12 first when:

• PHP 8.2 is the current safe production runtime
• the package graph is tight
• the app has weak smoke coverage
• the team needs a short security-support recovery step

Consider Laravel 13 direct when:

• PHP 8.3+ is already proven in staging
• dependencies already support Laravel 13
• the app has a reliable deploy and rollback path
• the business wants to avoid another framework project in 2027

Either way, keep the sequence reversible. A direct jump is not a virtue if it hides too many risks in one deploy.

Test the Laravel behaviors that users do not see

Browser smoke tests matter, but Laravel upgrades also break background behavior.

Include:

• php artisan config:cache and route:cache
• scheduler dry runs and key scheduled commands
• queue worker boot and restart
• job serialization for queued jobs already in flight
• payment webhook handling
• mail sending with the production transport config
• file uploads and storage disk writes
• login, password reset, and session persistence
• migrations in a copy of production data

For SaaS systems, queue and scheduler checks are as important as the HTTP smoke test. Many upgrade failures are invisible until the first delayed job runs under the new code.

Keep the public plan boring

An upgrade plan should be readable by a non-Laravel stakeholder:

1. Map the current system.
2. Make staging match production.
3. Fix Composer blockers.
4. Upgrade framework and first-party packages.
5. Run smoke tests and background checks.
6. Ship behind a rollback plan.
7. Document the new supported baseline.

That is the same shape used in our Laravel upgrade service: audit first, stabilize, then move one supported step at a time.

When to audit first

Use an audit before the Laravel upgrade if the application has no staging environment, no trusted deploy process, unknown queue behavior, old PHP, old MySQL, or a sole developer who owns the production knowledge.

The useful output is not just “upgrade to Laravel 13.” It is a risk register, package map, PHP target, database compatibility note, smoke-test list, and a sequence that explains what can ship safely now versus what needs a later modernization pass.