サポートの切れた古いLaravel（6系だったと記憶しています）のシステムを引き継ぎ、バージョンアップまで進めた実例があります。修正で多かったのはPHPの書き方の変更に伴うもので、いちばんの懸念は移行作業そのものではなく「知らないシステムのフルテストができているか」でした。引き継いだものは基本的に現状維持ではなくバージョンアップまで持っていきます。旧WordPressでは、プラグインの仕様変更と「無料だったものが有料になっている」問題が別の難しさになります。
古いバージョンのLaravelで動いているシステムの保守を引き継いでくれる会社はあるか、という問いには、Laravel・WordPressの保守で気をつけるべきバージョン管理で一般論として答えています。この記事はその一般論ではなく、FUNBREWが実際にサポート終了後のLaravelのシステムを引き継いで、バージョンアップまで進めたときに何が起きたかを、開発会社の側から書いたものです。お客様が特定できる情報は書いていません。
どんなシステムを引き継いだのか
引き継いだのは、Laravelの6系で動いていたシステムです。バージョンは6だったと記憶していますが、細かい数字より「公式のサポートがすでに終わっていた」ことのほうが実務では重要でした。Laravel 6はLTS（長期サポート版）ですが、公式のサポートポリシーではセキュリティ修正の提供が2022年9月3日で終了しています（出典: Laravel公式リリースノート 6.x Support Policy）。つまり引き継いだ時点で、フレームワーク自体に脆弱性が見つかっても修正が出ない状態でした。
サポートが終了したフレームワークで動いているシステムは珍しくありません。動いている間は困らないので、そのまま数年が過ぎている。FUNBREWにこうした引き継ぎの話が来るのは、たいてい元の開発会社との関係が切れたか、PHPやサーバーの更新で動かなくなる見込みが立ったときです。似た経緯の実例はテスト環境がないシステムを引き継いだらにも書いています。
バージョンアップで実際に多かった修正は何か
結論から言うと、いちばん多かったのはLaravel本体の変更というより、Laravelのバージョンを上げるのに伴ってPHPのバージョンも上がり、PHPの書き方として通らなくなった箇所の修正でした。
PHPのバージョンが上がることで書き方が変わる
Laravelの新しいバージョンは、それぞれ動作に必要なPHPのバージョンが決まっています。Laravelを上げれば、PHPも一緒に上げることになります。すると、古いPHPでは動いていた書き方が、新しいPHPでは非推奨や削除になっていて動かなくなる。今回のバージョンアップで手を入れた箇所の多くは、この「PHPの書き方の変更」に伴うものでした。自分のシステムのPHPがいつまでサポートされるかはPHPサポート終了日カレンダーにまとめています。
Laravel側でも非推奨（deprecated）になった機能がある
PHPほど多くはありませんが、Laravel側でも古いバージョンで使えていた書き方や機能が、新しいバージョンでは非推奨や廃止になっているものがあります。これも一つずつ、新しい書き方に置き換えていきます。
ここまでの作業自体は、正直に言えば大きな不安はありません。バージョンごとに何が変わったかは公式の移行ガイドで分かっていますし、FUNBREWとしてはやり慣れた作業です。問題は次の項目です。
いちばんの懸念は「フルテスト」ができているかどうか
引き継いだ古いLaravelのシステムをバージョンアップするとき、FUNBREWがいちばん懸念していたのは移行作業ではなく動作確認でした。
知らないシステムだから、どこをテストすべきかが分からない
自分たちで作ったシステムなら、どこにどんな機能があり、バージョンアップの影響がどこに出やすいかは頭に入っています。引き継いだシステムは違います。どれくらいの機能があるのか、どの画面がどの処理につながっているのか、まずそれを知るところから始まります。
書き換えた箇所が動くことを確認するのは難しくありません。難しいのは、自分が把握していない機能まで含めて「システム全体を一通り確認した」と言い切れるかどうかです。この「フルテストがちゃんとできているか」が、今回の引き継ぎで最大の課題でした。引き継ぎ直後に修正より先に環境を作る理由は保守を引き継いだ最初の1ヶ月に何をしているかに書いています。
発注側にお願いしたいのは「業務で使っている機能の一覧」
だからこそ、引き継ぎのときに発注側から出てくると助かるのが、実際に業務で使っている機能や画面の一覧です。仕様書のような整った資料である必要はありません。「毎月これを出している」「この画面は使っていない」といった情報だけでも、テストの範囲を決める手がかりになります。
現状維持ではなく、バージョンアップまで持っていく理由
古いLaravelのシステムを引き継いだとき、FUNBREWは基本的にそのまま保守するのではなく、バージョンアップまで持っていきます。
理由は、放置すると後の工数が増えるからです。開発側が使う技術は年々新しくなっていきますが、お客様のシステムがそれに追いついていないと、ちょっとした機能追加や修正をするたびに古い環境との差を埋める作業が発生します。先に何かをやろうとしても、まず土台を直さないと手が付けられない。放っておくほど、その差は広がります。
逆に言えば、バージョンアップを先に済ませておけば、その後の修正や追加は普通の作業として進められます。バージョンアップの費用がどう決まるかはPHPバージョンアップの費用はいくらかに書いています。
旧WordPressの場合は何が違うか
古いWordPressの引き継ぎも実例があります。こちらはLaravelとは違う難しさがありました。
古いプラグインの仕様が変わっている
WordPressを新しいバージョンに上げると、古いプラグインが軒並み動かなくなる、と言うと言い過ぎですが、かなりの数のプラグインで仕様が変わっています。同じ名前のプラグインでも、設定の持ち方や動き方が以前と違う。一つずつ確認して、必要なら代替を探す作業になります。
無料だったプラグインが有料になっている
いちばん扱いが難しいのは、プラグインのライセンスが変わっている場合です。以前は無料で使えていた機能が、今は有料プランでしか使えなくなっていることがあります。
これが厄介なのは、技術の問題ではなく説明の問題だからです。バージョンアップをすると、お客様から見れば「今まで使えていた機能が使えなくなった」ように見えます。実際には機能が削られたのではなく、プラグインの提供元が料金体系を変えたのですが、バージョンアップの結果として起きるので、一見すると機能低下に見えてしまう。ここを事前に説明して納得してもらうのに手間がかかりました。WordPressから別の仕組みへ移る判断についてはWordPressからの移行ガイドも参考にしてください。
まとめ
サポートが終了した古いLaravel（6系）のシステムをFUNBREWが引き継いでバージョンアップした実例では、修正で多かったのはPHPの書き方の変更に伴うもので、Laravel側の非推奨機能の置き換えもありました。移行作業自体より、知らないシステムの「フルテストができているか」がいちばんの懸念でした。引き継いだシステムは現状維持ではなくバージョンアップまで持っていきます。放置するほど後の工数が増えるからです。旧WordPressでは、プラグインの仕様変更と、無料だったプラグインが有料になっている問題があり、後者は技術より説明の難しさでした。
古いLaravelやWordPressのシステムでお困りなら、PHP・Laravelの救済サービスか保守サービスのページをご覧いただくか、お問い合わせからご相談ください。
この記事をシェア
古いLaravel・WordPressのシステムを引き継いでほしい方へ
サポートが終了したフレームワークで動いているシステムでも、現状の確認から始めて、バージョンアップまで含めてご相談いただけます。まずは業務で使っている機能を教えてください。