レガシーPHPをRailsへ移行する前に見る論点

「このPHP、誰が書いたフレームワークなのか分からない」「Laravelのバージョンが古すぎてPHP自体を上げられない」「新しく入った若手エンジニアが誰もPHPを書きたがらない」——長年運用されてきたPHPのシステムには、こうした声がつきものです。動いてはいるが触れる人が減り続け、いっそRailsに移行しようかという話が社内で出てくる、という相談を私たちはよく受けます。

この記事では、レガシーPHPをRailsへ移行するかどうかを判断するための論点と、移行すると決めた場合に全面書き換えの罠を避けて進める方法を、発注者向けに整理します。

そもそも「Railsへ移行」が正しい選択か

移行の相談を受けたとき、私たちが最初に確認するのは「なぜPHPが問題で、なぜRailsなら解決するのか」です。ここが曖昧なまま移行が始まると、多くの場合コストだけがかかって問題が解決しません。

移行を検討する動機としてよくあるのは次のようなものです。

• 採用できるエンジニアがいない: 独自フレームワークや古いCakePHPを書ける人材が市場に少なく、採用・オンボーディングのコストが高い
• PHP自体のバージョンが上げられない: フレームワークが古いAPIに依存しており、PHP本体のセキュリティアップデートに追従できない
• 開発生産性が頭打ちになっている: テストが書きにくい構造で、機能追加のたびに手動確認に時間がかかる

これらは正当な動機ですが、「PHPが嫌いだから」「流行っているから」という感覚的な理由だけでRailsに寄せるのは避けるべきです。PHP側でもLaravelへの部分的な刷新やテスト基盤の追加だけで採用・生産性の課題が解決するケースもあります。「PHPの何が具体的に事業のボトルネックになっているか」を先に言語化することが出発点です。

Railsへの移行が筋の良い選択になりやすいのは、社内・委託先ともにRailsエンジニアの調達がしやすく中長期の採用戦略と合致している場合や、現行PHPが独自実装で標準的なエコシステムの恩恵を受けられていない場合です。逆に、事業の変化が少なく現状のPHPで安定運用できているなら、移行せずに部分的な改善(テスト追加・依存アップデート・構造整理)にとどめるほうが投資対効果が高いこともあります。

全面書き換えが罠になりやすい理由

移行すると決めた発注者の多くが最初に考えるのが「いっそ全部Railsで作り直す」という全面リプレイスです。気持ちは理解できますが、私たちはこれを基本的にはおすすめしません。理由は3つあります。

• 仕様が文書化されていないことが多い: 長年運用されたPHPのコードは、コードそのものが唯一の仕様書になっているケースが大半です。書き直しの過程でエッジケースの挙動を見落とすと、リリース後に「前はできたのにできなくなった」というクレームが噴出します
• 開発期間中、事業側の要望に応えられなくなる: 全面書き換えは数ヶ月から1年以上のプロジェクトになりがちで、その間は新機能追加がほぼ止まります。競合が動いている間に身動きが取れなくなるリスクは無視できません
• 切り替えのタイミングが一発勝負のリスクになる: 新システムへの一斉切り替えは、本番データでしか再現しない不具合に初めて気づく、というパターンが起きやすく、切り戻しも簡単ではありません

PHPのコードが読みづらいのは事実でも、書き直しがリスクを減らすとは限りません。動いているものを動かしたまま、少しずつ置き換える段階移行のほうが、事業への影響を抑えながら着実に前進できます。

段階移行の現実解: ストラングラーパターンと並行運用

私たちが基本方針とするのは、いわゆる「ストラングラーパターン」に近い進め方です。PHPのシステムを一気に置き換えるのではなく、機能単位でRails側に少しずつ処理を移し、最終的にPHP側の役割をゼロに近づけていきます。

1. リバースプロキシで振り分ける

URLパスやサブドメインの単位でリバースプロキシ(NginxやALBなど)を設定し、Railsに移行済みの機能はRailsへ、未移行の機能は従来のPHPへルーティングします。この構成であれば、移行単位ごとに独立してリリース・切り戻しができ、システム全体を止めずに進められます。

2. 移行単位を「機能」より小さく切る

いきなり「会員機能」「注文機能」のような大きな単位で移行するのではなく、その中の1つの画面・1つのAPIエンドポイントといった粒度で移行します。粒度を小さくするほど、1回の移行失敗の影響範囲が限定され、原因の切り分けも容易になります。

3. 認証・セッションの共存設計を先に決める

PHPとRailsが並行稼働する期間は、ログインセッションをどちらのシステムでも有効に保つ必要があります。Cookieの共有ドメイン設定、セッションストアの共通化、認証トークンの互換性など、ユーザーが「気づかないうちにログアウトさせられる」事故を防ぐ設計を最初に固めておきます。ここを後回しにすると、移行中盤で大きな手戻りが発生しがちです。

4. 優先順位は「変更頻度」と「複雑さ」で決める

すべての機能を同じ熱量で移行する必要はありません。変更頻度が高く事業上のボトルネックになっている機能から着手すると効果を早期に実感でき、以降の予算確保にもつながります。一方でPHP側の複雑さが低い機能を先に片付け、移行の型(データ移行・認証共存・リリース手順)を確立してから複雑な機能に進むほうが安全です。決済・請求など失敗が許されない機能は、テストを厚めに敷いてから着手するか、あえて後回しにして先に手順を確立してから臨みます。

データ移行で見落としがちな論点

段階移行では、PHP側とRails側が同じデータベースを参照し続ける期間が発生します。ここでの設計ミスは後から気づきにくく、修正コストも高くなりがちです。

PHP側の古いテーブル設計(正規化されていないカラム、暗黙の型変換に依存した値など)は、RailsのActiveRecordの規約にそのまま載せられるとは限りません。ビューやアダプタ層を挟んで差異を吸収するか、段階的にスキーマ自体を整理するかを事前に決めます。また移行期間中に両システムから同じテーブルへの書き込みが発生する場合、片方だけがバリデーションやコールバックを実行して不整合が生まれるリスクがあるため、書き込み元をどちらか一方に限定できないかをまず検討します。

一括データ移行は一度で成功するとは限りません。失敗時に何度でも安全に再実行できる(冪等性のある)スクリプトにしておくことで、本番移行当日のリスクを大きく下げられます。件数の一致だけでなく、金額計算やステータス遷移といったビジネスロジックが絡む値は、旧システムと新システムで結果を突き合わせるバッチを用意し、機械的に差分を検出できるようにします。

移行しない、あるいは部分改善にとどめる選択肢

ここまで移行の進め方を解説してきましたが、誠実に付け加えておくと、Railsへの全面移行が最善とは限らないケースも少なくありません。事業の成長が緩やかで現状のPHPシステムが安定稼働している場合は、移行コストに見合うリターンが得られないことがあります。Laravel等の標準フレームワークへの刷新やテスト基盤の追加、依存ライブラリのアップデートだけで、採用・保守性の課題がある程度解決することもあります。移行の動機が「特定のエンジニアの好み」に偏っていないか、組織全体の技術選定として妥当かを一度立ち止まって検討する価値があります。

移行はゴールではなく手段です。「何を解決したくてRailsに移行するのか」を明確にできないうちは、着手を急がないほうが結果的に投資対効果は高くなります。

外注時に確認すべきこと

レガシーPHPからRailsへの移行を外部チームに依頼する際は、以下を確認してください。

• 全面書き換えを最初の提案にしていないか: ストラングラーパターンのような段階移行を具体的に説明できるかどうかは、パートナー選びの重要な判断材料です
• 認証・セッションの共存設計を持っているか: PHPとRailsが並行稼働する期間、ユーザー体験を壊さない設計を事前に説明できるか
• データ移行スクリプトの再実行可能性と検証方法を計画しているか: 「動かしてみて壊れたら考える」進め方ではないか
• 移行しない選択肢も検討した上で提案しているか: 移行そのものが目的化していないか

こうした判断は、PHPに限らず古いシステム全般の「改修とフルリプレイスのどちらを選ぶべきか」という論点とも重なります。詳しくは技術的負債は改修とフルリプレイスどちらを選ぶべきかで扱っています。また、そもそも既存プロダクトのどこから手をつけるべきかを見極める観点は既存プロダクトの改善、外部チームが最初に見る観点にまとめていますので、あわせてご覧ください。

torcheees では Ruby on Rails を中心に、レガシーPHPからの段階移行を含む既存プロダクトの改善・モダナイゼーションを手がけています。詳しくはモダナイゼーションのサービスページをご覧ください。

まとめ

• レガシーPHPからRailsへの移行は、「何が事業のボトルネックになっているか」を明確にした上で判断すべきで、移行しない・部分改善にとどめる選択肢も誠実に検討する価値がある
• 全面書き換えはリスクが大きく、リバースプロキシによる振り分けと機能単位の段階移行(ストラングラーパターン)で、事業を止めずに進めるのが現実的
• データ移行では認証・セッションの共存設計、書き込みの一貫性、スクリプトの再実行可能性と検証方法を事前に固めておくことが、移行当日の事故を防ぐ

「PHPが古くなってきたが、Railsに移行すべきか判断がつかない」という段階でも構いません。torcheees では既存プロダクト改善向けに、1〜4週間の「開発診断」で現状のコードと移行の要否を確認し優先順位をご提示するほか、継続的な改善支援も行っています。お問い合わせフォームからお気軽にご相談ください。