結論から書くと、Laravel のバージョンアップは 1メジャーずつ、検証環境で、確認項目を決めてから 進めるのが最も安全です。そして詰まる原因の多くは Laravel 本体ではなく、PHP のバージョン、サードパーティのライブラリ、テストがないことの3つにあります。
公式のアップグレードガイドには作業時間の目安が書かれています。Laravel 13 のガイドでは「10 Minutes」、Laravel 12 のガイドでは「5 Minutes」です。ただ、これは直前のバージョンから標準的な構成で上げる場合の話です。何年も更新していないシステムや、独自の拡張が入ったシステムにそのまま当てはめることはできません。
まず現在地を確認する
最初に、今のバージョンがどの状態にあるかを確認します。Laravel 公式のリリースノートによると、各リリースのバグ修正は18か月、セキュリティ修正は2年提供されます。公式の表は次のとおりです（2026年11月時点）。
| バージョン | 対応PHP | リリース | バグ修正の期限 | セキュリティ修正の期限 |
|---|---|---|---|---|
| Laravel 10 | 8.1〜8.3 | 2023年2月14日 | 2024年8月6日 | 2025年2月4日 |
| Laravel 11 | 8.2〜8.4 | 2024年3月12日 | 2025年9月3日 | 2026年3月12日 |
| Laravel 12 | 8.2〜8.5 | 2025年2月24日 | 2026年8月13日 | 2027年2月24日 |
| Laravel 13 | 8.3〜8.5 | 2026年3月17日 | 2027年第3四半期 | 2028年3月17日 |
この表から分かるのは、Laravel 11 以前はすでにセキュリティ修正の期限を過ぎていること、Laravel 12 もセキュリティ修正のみの期間に入っていることです。あわせて、動いている PHP のバージョンも確認します。Laravel 13 は PHP 8.3 以上が必要なので、PHP 8.2 以下で動いているシステムは PHP の更新もセットになります。
確認するのは次の4点です。
- Laravel のバージョン（
composer.lockのlaravel/framework） - 本番環境の PHP のバージョン（開発環境と違うことがあるので本番で確認する）
composer.lockがリポジトリにあるか、本番のコードと一致しているか- テストがあるか、あるなら今の環境で通るか
事前調査から本番切り替えまでの手順
手順は次の流れです。順番を入れ替えると、問題の原因が切り分けられなくなります。
- 本番の状態を再現する。 コードとデータベースのコピーで、検証環境を本番と同じ PHP・同じミドルウェアのバージョンで動かします。ここで動かないなら、バージョンアップの前に解決します。
- 確認項目を決める。 売上や業務に直結する操作（ログイン、登録、検索、帳票、メール、定期処理、外部連携）を一覧にします。これがバージョンアップ後の合格基準になります。
- ライブラリの対応状況を調べる。
composer outdatedで更新があるパッケージを一覧にし、移行先のバージョンに対応しているかを確認します。対応を止めているものが見つかったら、代替や自前実装の検討が必要です。 - 1メジャーずつ上げる。 公式のアップグレードガイドは「Upgrading To 13.0 From 12.x」のように直前のバージョンからの手順だけを扱っています。飛ばすと、途中のガイドに書かれた変更を見落としやすくなります。
- バージョンごとに確認する。 上げるたびにテストと確認項目を実行し、バージョンごとにコミットを分けます。問題が出たときに戻れる地点を作るためです。
- 本番を切り替える。 切り替え手順、戻し手順、確認する人を事前に決めておきます。データベースの変更を伴う場合は、切り替え前のバックアップから戻せることを確認しておきます。
- 切り替え後のログを見る。 エラーログと定期処理の結果を確認します。毎月・毎週しか動かない処理は、切り替えた直後には動かない点に注意が必要です。
Composer の composer.json では laravel/framework だけでなく、関連パッケージも一緒に更新します。Laravel 13 のガイドでは laravel/tinker や phpunit/phpunit なども更新対象に挙げられています。
自社の案件では、Laravel 6 系から 10 系程度までバージョンを上げた業務システムで、期間は1か月弱でした。規模や構成、テストの有無で大きく変わるため、あくまで一例です。
実際に詰まるポイント
PHP の非互換
Laravel より PHP の変更で動かなくなるケースが目立ちます。特に PHP 7 系から上げるときは注意が必要です。PHP 8.0 の非互換の一覧から、業務システムで影響が出やすいものを挙げます。
0 == "foo"の比較結果が true から false に変わった。エラーにならず結果だけ変わるので、最も見つけにくい変更です。each()が削除され、$array{0}の書き方も使えなくなった。- PDO の既定のエラーモードが「エラーを出さない」から「例外を投げる」に変わった。今まで黙って失敗していた SQL が、画面エラーとして表に出ます。
さらに PHP 8.1 では組み込み関数の引数に null を渡すことが非推奨に、PHP 8.2 では動的プロパティの作成が非推奨になりました。非推奨の段階では動きますが、ログが大量に出て本当のエラーが埋もれることがあります。
サードパーティのライブラリ
管理画面、決済、PDF、Excel 出力などのパッケージが新しい Laravel に対応していないと、そこで止まります。保守が止まったパッケージは待っても対応されないので、代替への置き換えか、必要な部分だけ自前で書くかを判断します。作業量が読みにくい部分なので、見積の前に調べておくべき項目です。
フレームワークの中に手が入っている
vendor 以下を直接書き換えている、フレームワークのクラスを継承して内部の動きに依存している、といった実装は、公式ガイドの想定外です。composer install をすると修正が消えるので、最初に本番と vendor の差分を確認します。
変更に気づきにくい挙動の違い
エラーにならない変更は、テストや確認項目がないと見逃します。たとえば Laravel 13 では CSRF 対策のミドルウェアの名前が VerifyCsrfToken から PreventRequestForgery に変わっており、独自に参照している箇所は修正が必要です。セッションのシリアライズ設定を php から json に変えると、ログイン中の全ユーザーのセッションが無効になるとガイドに明記されています。業務時間中に切り替えると、全員がログアウトされることになります。
何世代も飛んでいる場合の考え方
Laravel 8 のように何世代も前の場合、1つずつ上げるか、最新の構成で作り直してコードを移すかの選択になります。
- 1つずつ上げる: 途中で動作確認ができ、問題の原因を切り分けやすい方法です。テストや確認項目があるなら基本はこちらです。
- 新しい構成へ移す: Laravel を新しくインストールし、そこへコードを移します。独自の設定が少なく、規模が小さいシステムに向いています。
どちらを選んでも、古いライブラリの置き換えは避けられません。先にライブラリの調査をしてから決めると、判断を誤りにくくなります。
テストがない場合の進め方
テストが1本もないシステムは珍しくありません。だからといって、全機能のテストを書いてからでは着手できなくなります。現実的には次の順で進めます。
- 手順で決めた確認項目を、人が実行できる手順書にする
- 特に止まると困る処理から、画面を通した機能テストを少しずつ追加する
- 計算や帳票など、結果が明確な処理は「今の出力」を基準としてテストに固定する
3つ目は、正しいかどうかではなく 今と同じかどうか を確かめるテストです。バージョンアップの目的は動作を変えないことなので、これで十分に役立ちます。
h-system でできること
h-system では、Laravel を含む PHP システムのバージョンアップと保守を、調査から実装まで開発者本人がお引き受けしています。自社でも Laravel 製のサービスを企画から運用まで続けており、他者が構築したシステムの引継ぎ、Zend Framework 1 のシステムを PHP 8.1 で動くようにした対応などの経験があります。「どこまで上げられるか、まず調べたい」という調査だけのご依頼もできます。初回のご相談と概算のお見積りは無料で、詳細な調査が必要な場合は着手前に範囲と費用をご案内します。