2026.09.02

「独自PHPの古いシステム」は最新サーバーに移転できる？老朽化サイトを安全に延命する方法

執筆者情報

中村圭介

株式会社カジヤ/代表取締役　男性向けファッション通販サイト運営の会社を経験し、現職に至る。デザインや開発から、ECやメディアのコンサルティングまでを一貫して行う。お付き合いのあるお客様の事業を成功に導けるように、再現性のある成長支援ができる会社を目指す。

【AIによる要約】
– 独自PHPの古いシステムでも、条件が揃えば最新サーバーへの移転・PHPのバージョンアップによる「延命」は可能です。ただし「延命で足りるケース」と「リプレイスしかないケース」の線引きが重要です。
– DBが分離していてフレームワーク・ライブラリの依存が把握できるなら延命優先。コードの解析に本体改修と同等以上の工数がかかる見込みならリプレイスを推奨します。
– まずPHPの公式サポート終了状況（EOL）とサーバーOSのサポート期限を確認し、移転前に必ず現行環境のバックアップとステージング検証の体制を用意してください。

「サーバーを引っ越したいんですが、無理でしょうか？」

「社内の予約管理システムが10年前の独自PHPで作られていて、サーバーが古い。レンタルサーバー会社から『このOSはもうサポートしません』と通知が来た」——。

当社カジヤに届く相談で、ここ数年特に増えているのがこのパターンです。業界歴10年以上で300社以上の企業サイト・Webシステムの支援に携わってきた経験から言うと、2010年前後に構築された独自システムの「更新期限切れ」は、いままさに全国で同時多発的に起きています。

レンタルサーバー各社が古いOS・古いPHPの環境を順次廃止しているため、「まだ動いているから放置」ができなくなったのです。この記事では、

古い独自PHPシステムは最新サーバーに移せるのか（移せる条件・移せない条件）
「延命」と「リプレイス」を分ける判断基準
移転・延命作業の実際の工程と、そこにかかるコストの裏側

を、現場で何度も復旧・移行に立ち会ってきた経験に基づいて解説します。

古いサーバーから新環境への移転イメージ

まず押さえるべき現状：PHPには「寿命」がある

サーバー移転の話の前に、確認してほしい一次情報があります。PHP公式が公開しているサポート対象バージョン一覧（php.net/supported-versions）です。

PHPにはアクティブサポート→セキュリティサポート→サポート終了（EOL）という寿命サイクルがある
EOLを過ぎたバージョンはセキュリティ修正が一切提供されない
レンタルサーバー会社が古いPHPを廃止するのは、このEOLに沿った動き

つまり「今動いている」ことと「安全」は別問題です。EOLのPHPで動き続けるサイトは、既知の脆弱性を突かれ続ける状態と同じです。IPA（情報処理推進機構）も古いソフトウェアの利用継続を主要なリスクとして注意喚起しています。

ここで重要なのは、PHPのバージョンを上げられないシステムは、サーバーを新しくしても延命できないという点です。新しいサーバーの多くは新しいPHPしか動かないため、「移転」と「PHP対応」はセットの課題になります。

移転できるかどうかを分ける2つの条件

古い独自システムの移行可否は、当社では基本的に次の2点でまず判断します。

条件1：データベースが「分離」しているか

DB（MySQL等）がアプリと分離していれば、DBはダンプして新サーバーに移せるため成功率が高い
反面、ファイルベースでデータを持つ古い作り（CSV直接更新など）は移行難度が跳ね上がる

条件2：コードの「依存関係」が把握できるか

ソースに古いフレームワークやライブラリへの依存が明記されていれば解析は速い
新しいPHPで動かなくなった関数（非推奨・削除された関数）をどこまで書き換える必要があるかが、工数の大半を占める

この2点がクリアなら、延命は現実的な選択肢になります。

延命かリプレイスかの判断分岐イメージ

プロの判断基準：「延命」と「リプレイス」はこう分ける

「どっちにもメリットがあります」という答えは、意思決定の役に立ちません。当社が実際の見積もり判断で使っている基準を言い切ります。

延命（移行＋PHP対応）を選ぶべきケース

今後3年程度は現行機能で事業が回る見込み
DB分離・依存把握ができており、改修対象のコード量が現行コードの2割未満
予算よりも「今止まらないこと」が優先される（受注システム、予約システムなど）

リプレイス（作り直し）を選ぶべきケース

コード解析の見積もりが本体改修と同等以上になる（=延命の費用対効果が崩れている）
独自機能のうち実際に使われているのが半分以下（使わない機能の移植コストが無駄）
今後の事業計画に機能拡張・外部サービス連携が含まれている

特に見落とされがちなのが3つ目です。「古いシステムを延命→2年後に結局リプレイス」だと総額は二重払いになります。移行見積もりがリプレイスの4割を超えるなら、最初からリプレイスを検討する方が合理的というのが、当社の現場感です。

延命・移行の実際の工程（ここが費用の裏側です）

「サーバー移転って、ファイルコピーすれば終わりでは？」というご相談をよく受けます。実際の工程を見ると、なぜ工数がかかるのかが分かります。

移行の5ステップ工程イメージ

現状調査・解析：PHP・OSのバージョン、DB構造、依存ライブラリ、動作しなくなる関数の洗い出し
ステージング環境の構築：新サーバーと同条件の検証環境を用意。本番を直接触る移行は絶対にしない
コード修正・DB移行：非推奨関数の書き換え、DBのダンプ投入と文字コード整合の確認
検証：主要機能の実機テスト。フォーム送信・決済・メール送信など「外から見えない動線」こそ重点的に
本番切り替え：DNS切替、旧環境を一定期間温存したまま様子見

このうち1と4を省略した移行が、当社が過去に何度も「復旧」として引き取ってきた案件です。切り替え直後にメールが飛ばない、決済が通らない——移行事故の大半は「検証環境なしで本番に載せた」ことで起きています。 自社でもEC事業を運営している立場から断言しますが、ECサイトの停止は1日あたりの売上と顧客の信頼を直接失います。ここだけはDIYの範囲ではありません。