Laravel 13, released in February 2026, ships with a refreshed service container, streamlined middleware pipeline, and tighter PHP 8.4+ requirements. If your team runs Laravel 12.x in production, here is a practical walkthrough of everything you need to check before cutting over.

Dependency audit

Start with a clean picture of what your current lock file expects.

# Check for packages that cap at Laravel 12 or below
composer why-not laravel/framework 13.*

# Dry-run the upgrade without touching vendor/
composer require laravel/framework:^13.0 --dry-run --no-install

Common blockers include older first-party packages (laravel/cashier, laravel/scout, laravel/horizon) and community packages that have not yet widened their version constraints. Pin down which packages need updates before writing any application code.

Third-party packages to verify early

• Spatie packages (permissions, media-library, backup) - check each repo’s composer.json for a ^13.0 constraint.
• Livewire / Filament - confirm compatibility on their release blogs; these often ship support within days.
• Debugbar, Telescope, Pulse - update to their latest minor versions.
• PHPStan / Larastan - upgrade Larastan to a version that understands the new container bindings.

PHP version constraints

Laravel 13 requires PHP 8.4 or higher. If your servers still run 8.3, that is the first infrastructure change to plan.

php -v
# Confirm 8.4.x or 8.5.x

composer check-platform-reqs

On managed platforms (Forge, Vapor, Ploi), switch the PHP version in your server settings and redeploy a canary instance before touching the framework version. If your team uses hosted AI coding workflows for automated refactoring or CI-driven code reviews, confirm those environments also run a compatible PHP version.

CI pipeline updates

Your CI matrix should test both the old and new versions in parallel during the transition window.

# GitHub Actions example
jobs:
  tests:
    strategy:
      matrix:
        php: ['8.4', '8.5']
        laravel: ['12.*', '13.*']
        exclude:
          - php: '8.3'
            laravel: '13.*'
    steps:
      - uses: shivammathur/setup-php@v2
        with:
          php-version: ${{ matrix.php }}
      - run: composer require laravel/framework:${{ matrix.laravel }} --no-update
      - run: composer update --prefer-dist --no-progress
      - run: php artisan test

Also update any static analysis or code-style steps. Pint, PHPStan, and Rector rulesets may need version bumps to handle new Laravel 13 idioms.

Queue, cache, and session checks

Framework upgrades quietly change serialization formats and driver defaults more often than the changelog advertises. Test these explicitly.

Queues

1. Deploy the new code but keep old workers running briefly to drain existing jobs.
2. Verify that job payloads serialized under Laravel 12 deserialize correctly on 13.
3. If you use Horizon, upgrade laravel/horizon first and redeploy the Horizon dashboard before restarting workers.

Cache

php artisan cache:clear

If you use tagged caches or custom cache stores, confirm the tag format has not changed. Run your cache-heavy integration tests before going live.

Sessions

Laravel 13 updates the default session cookie configuration. Compare your config/session.php against the new stub:

# Generate a fresh config to diff against
composer create-project laravel/laravel /tmp/l13-fresh --prefer-dist --no-interaction
diff config/session.php /tmp/l13-fresh/config/session.php

Watch for changes in same_site, secure, and partitioned defaults that could silently log users out after deployment.

Database and migration concerns

Review the upgrade guide for any changes to the Schema builder, Eloquent casts, or migration stub format.

# Run existing migrations on a fresh database to catch schema issues
php artisan migrate:fresh --seed --env=testing
php artisan test --env=testing

If your app uses $casts as an array property (the pre-Laravel 11 style), confirm that the framework still supports it. Laravel has been nudging teams toward the casts() method since version 11, and deprecations eventually become removals.

Rollback strategy

Never upgrade a production framework version without a tested rollback path.

• Lock file snapshot: commit composer.lock on the current version in its own branch before upgrading.
• Blue-green or canary deploy: route a small percentage of traffic to the upgraded instance and watch error rates.
• Database forward-compatibility: avoid running irreversible migrations as part of the same deploy. Ship schema changes separately, ahead of the framework bump.
• Feature flags: wrap any code that depends on Laravel 13-only APIs behind a flag so you can disable it without a full rollback.

Quick checklist for busy teams

Use this as a go / no-go list before deploying to production:

• All Composer dependencies resolve cleanly against laravel/framework:^13.0
• PHP version on all servers and CI runners is 8.4+
• Test suite passes on Laravel 13 with zero deprecation warnings treated as errors
• Queue jobs serialized on Laravel 12 deserialize correctly on 13
• Cache cleared and tagged-cache behavior verified
• Session config diffed against fresh Laravel 13 defaults
• Database migrations run cleanly on a fresh database (migrate:fresh --seed)
• Horizon, Telescope, and Pulse upgraded and dashboards load correctly
• CI matrix includes both Laravel 12 and 13 during the transition
• Rollback branch with old composer.lock is ready and tested
• Canary deploy monitored for error-rate spikes for at least one hour
• Error and deprecation logs reviewed after full traffic cutover

Smoke-test list

After deployment, manually verify these flows (or automate them in a post-deploy health check):

1. Authentication - login, logout, password reset, two-factor if enabled.
2. Payment flows - Cashier webhook handling, subscription creation.
3. Notification channels - email, SMS, Slack, database notifications.
4. File uploads - local and cloud disk drivers.
5. Scheduled commands - run php artisan schedule:test and confirm output.
6. WebSocket / broadcasting - if using Reverb or Pusher, verify real-time events fire.
7. API endpoints - hit key endpoints with Postman or curl and compare response shapes to pre-upgrade snapshots.

Wrapping up

Most Laravel major upgrades are straightforward if you methodically audit dependencies, test in CI first, and keep a clean rollback path. The checklist above compresses the process into a repeatable routine your team can follow for this release and future ones. Start with the dependency audit, work through infrastructure and config changes, and only cut over production traffic once your smoke tests are green.