「動いているからいい」は危険信号。PHPで作られた古い業務システムをLaravelにリプレイスすべき判断基準と、失敗しない移行コストの試算方法を実案件をもとに解説します。
こんな状況、心当たりありませんか？
「10年前に作ってもらったシステムが動いているからとりあえず問題ない」「改修を依頼するたびに費用が高くなってきた気がする」「担当エンジニアがいなくなって、誰も中身を把握していない」——。
こうした状況に直面している企業は、神奈川の中小企業の中でも決して少なくありません。当社にも毎月数件、こうした相談が舞い込んできます。システムは動いている。でも何かが少しずつおかしい。その「おかしさ」の正体と、適切な判断基準をこの記事で整理します。
なぜ古いPHPシステムは限界を迎えるのか
技術的負債が静かに蓄積される
2000年代〜2010年代前半に構築された業務システムの多くは、フレームワークを使わない「素のPHP（生PHP）」で書かれています。当時はそれが標準的な開発手法でした。しかし時代とともに問題が顕在化してきます。
よく見られる典型的な問題点：
- PHPのバージョンが5系や7系のまま放置されており、セキュリティパッチが適用されていない
- ファイルが数百個に分散し、どこに何が書いてあるか誰も把握していない
- SQLインジェクションに対する防御が不十分（プリペアドステートメント未使用）
- テストコードが一切存在せず、修正するたびに別の箇所が壊れる
- ドキュメントが存在しないか、現状と乖離している
こうした状況では「ちょっとした機能追加」でも数十万円の見積もりが当たり前になります。なぜなら修正前にシステム全体の動作確認を一から行う必要があるからです。
セキュリティリスクは「いつか」ではなく「今」の問題
PHP 8.0未満はすでに公式サポートが終了しており、新たな脆弱性が発見されても修正パッチが提供されません。個人情報保護法の改正により、情報漏洩時の企業責任も以前より重くなっています。「動いているから大丈夫」という判断は、法的リスクも含めて再考が必要です。
Laravelへのリプレイスを検討すべき5つのシグナル
以下の条件に2つ以上当てはまる場合、リプレイスの検討を真剣に始めるべきタイミングです。
移行コストの正しい試算方法
「Laravelに移行したい」という相談で最初に聞かれるのが「いくらかかりますか？」という質問です。この見積もりを間違えると、プロジェクトが途中で頓挫します。実案件をもとに、正しい試算の考え方を解説します。
ステップ1：現行システムの機能棚卸し
移行コストの最大の決定要因は「機能の数と複雑さ」です。まず現行システムの機能を洗い出し、以下の3段階で分類します。
【機能分類の目安】
シンプル（1〜3日/機能）
- マスタデータのCRUD（登録・一覧・編集・削除）
- CSVインポート・エクスポート
- メール送信フォーム
標準（3〜7日/機能）
- 権限管理を伴うユーザー認証
- 複数テーブルが絡む帳票出力
- 検索・フィルタリング機能
複雑（7日以上/機能）
- 外部API連携（会計ソフト・決済など）
- バッチ処理・スケジュール実行
- 独自の計算ロジック（在庫引当など）
ステップ2：データ移行コストを別途計上する
よくある失敗が「データ移行を軽視する」ことです。10年分のデータを新しいデータベース構造に移し替える作業は、機能開発とは別に必ず工数がかかります。
// データ移行スクリプトの例（LaravelのArtisanコマンド）
// 古いDBから新しいDBへのマイグレーション
namespace App\Console\Commands;
use Illuminate\Console\Command;
use Illuminate\Support\Facades\DB;
class MigrateOldCustomers extends Command
{
protected $signature = 'migrate:customers';
protected $description = '旧システムの顧客データを移行する';
public function handle()
{
// 旧システムのDBから取得
$oldCustomers = DB::connection('old_db')
->table('customer_mst')
->get();
$this->withProgressBar($oldCustomers, function ($old) {
DB::table('customers')->updateOrInsert(
['old_system_id' => $old->cust_cd],
[
'name' => trim($old->cust_name_kj),
'name_kana' => trim($old->cust_name_kn),
'email' => strtolower(trim($old->mail_addr)),
'phone' => preg_replace('/[^0-9]/', '', $old->tel_no),
'created_at' => $old->create_date,
'updated_at' => now(),
]
);
});
$this->newLine();
$this->info('顧客データ移行が完了しました。');
}
}
このように旧DBと新DBを同時接続し、差分を吸収しながら移行するスクリプトを機能ごとに作成します。データの揺れ（全角・半角混在、NULLの扱いなど）の吸収作業が最も時間を要します。
ステップ3：コスト試算の実例
ある案件（製造業・社員50名・10年稼働の受発注管理システム）での試算例を公開します。
この案件では総額約480万円・期間5ヶ月でリプレイスを完了しました。移行後の保守費用は年間36万円（月3万円）となり、移行前の年間保守費用120万円と比較して約70%の削減を実現しています。
段階的移行 vs 一括リプレイス：どちらを選ぶべきか
| 観点 | 段階的移行（ストラングラー） | 一括リプレイス |
|---|---|---|
| リスク | 低い | 高い |
| 期間 | 長い（6ヶ月〜2年） | 短い（3〜8ヶ月） |
| コスト | 高め（並行稼働コストが発生） | 明確に試算しやすい |
| 業務への影響 | 最小限 | 切り替え時に一時的な影響あり |
| 推奨シーン | 24時間稼働・停止不可システム | 夜間・週末に停止できるシステム |
業務系システムの多くは夜間や休日に停止できるため、一括リプレイスの方がコスト効率に優れています。ただし、ECサイトや24時間受付システムは段階的移行が安全です。
よくある失敗パターンと回避策
失敗①：「とりあえず同じ機能を再現」で要件定義をサボる
古いシステムの機能を「そのまま再現してほしい」という依頼は一見シンプルに見えますが、実際には誰も使っていない機能まで移行することになります。当社がある卸売業のシステムを調査した際、全機能の約35%が「誰も使っていない画面」でした。移行前に必ず現場ヒアリングを行い、不要機能の削除判断をすることでコストを大幅に削減できます。
失敗②：テスト工数を「最後に少し」しか見ていない
移行プロジェクトでは、テストに全体工数の20%以上を確保するのが鉄則です。「動いているように見えるのに数値計算が微妙にズレていた」という問題は、本番稼働後しばらく経ってから発覚するケースがあります。計算ロジックが絡む機能は特に念入りに旧システムとの出力比較テストを行ってください。
失敗③：移行後のサーバー環境を現行と変えない
せっかくLaravelに移行したにもかかわらず、旧システムと同じ古いレンタルサーバーに置き続けるケースがあります。LaravelはComposerやキューなどのモダンな機能を活用してこそ効果を発揮します。移行を機にVPS（ConoHaやさくらのVPS）またはクラウド（AWS・GCP）への移行も検討することを強くお勧めします。
開発・運用でお困りなら
システム開発
設計から運用まで、堅牢なシステムを構築します
※ 通常1営業日以内にご返信します
まとめと次のステップ
古いPHPシステムは「動いている」という事実が判断を鈍らせます。しかし保守コストの増大、セキュリティリスク、そして機能拡張の限界は静かに忍び寄っています。Laravelへのリプレイスは単なる技術的なアップデートではなく、今後10年の開発体制を再設計するための投資です。
移行後の変化として、あるクライアントでは「機能追加の見積もりが平均60%削減」「新しいエンジニアがジョインしても即日コードを読める」「セキュリティ監査をパスできるようになった」という成果が出ています。
「うちのシステムは移行が必要なのか、費用はどのくらいかかるのか」が気になる方は、現行システムの概要（機能数・利用人数・稼働年数）を簡単にまとめてご連絡ください。Fivenine Designでは、移行前の無料ヒアリング・概算見積もりを承っています。神奈川を中心に、20年以上の開発実績で培ったノウハウをもとに、御社に最適な移行計画をご提案します。
