PHPからTypeScript・Next.jsへ移行するには｜業務・データ・認証の設計

PHPからTypeScriptへサービスを移すときは、コードの書き換えに加えて、業務、データ、認証、運用の引き継ぎが必要です。最初に、既存機能を再現する部分と、業務に合わせて変える部分を分けます。

Next.jsやSupabaseなどは移行先の候補です。現在のサービスで必要な処理と、公開後に管理する人から構成を選びます。判断の全体像はPHPサービスの再構築ガイドをご覧ください。

この記事は、既存サービスの事業・運用責任者向けです。業務側では残す操作と止められない処理を整理し、データ変換や認証の引き継ぎ方法は技術担当者へ設計を依頼します。

使う技術を決める前に、処理を分ける

画面、ログイン、データの更新、定期処理、ファイル出力、外部APIを一覧にします。画面を作る仕組みが決まっても、長時間の集計や大量のメール送信まで同じ場所で処理できるとは限りません。

公開ページ中心ならAstro、利用者ごとの操作が多いサービスなら画面・サーバー処理・データベースを含めた構成を検討します。HPの静的化とWebサービスの再構築は、移行するものが異なります。

データは、項目の対応と値の意味を確認する

移行元と移行先で、ID、日時、金額、状態、空欄、添付ファイルの扱いを照合します。形式が違う項目は変換方法を決めます。

移行の設計例として、旧データの会員番号を新しい環境のIDへ変えるなら、対応関係を残し、取引や投稿が同じ会員へ結び付くことを確認します。日時は保存している時刻の基準、金額は端数の扱いも照合します。

データ移行は一度の取り込みだけでなく、練習、照合、公開直前の追加分の反映まで計画します。移行チェックリストに整理用の項目があります。

ログインを引き継ぐ方法は、現在の認証方式で変わる

既存のパスワードをそのまま移せると決めつけず、保存形式と移行先の認証方式を調べます。パスワード再設定をお願いする場合は、通知、再設定の画面、問い合わせ対応も計画します。

ログイン後の権限も別に設計します。Supabaseを使う場合は、利用者ごとのデータへのアクセスを制限するRLSや、サーバー処理の権限を確認します。Supabaseの公式ガイド

新しい構成に移っても、誰が何をできるかは自動的には決まりません。モダン構成のセキュリティレビューが確認の入口になります。

部分的に移すなら、新旧の接続点を決める

一部の機能から置き換える場合は、どちらがデータを書き込むか、認証をどう共有するか、失敗した処理をどちらで再実行するかを決めます。

新旧の両方で同じ機能を変更し続けると、差分の管理が増えます。機能ごとの切り替え条件と、旧機能を停止する時期まで含めて計画してください。部分改修と全面再構築の比較で検討できます。

例：管理画面の照会から順に置き換える

以下は、PHPで動く受注管理をTypeScript・Next.jsへ段階的に移す設計例です。実案件の実績ではありません。現在の処理を分離できるか、権限を引き継げるかを調べたうえで採用を判断します。

最初の段階では、旧環境にある注文をどの経路で安全に読むかを技術担当者が設計します。新画面を作っただけで、利用者の権限まで引き継げるとは限りません。

業務側は、変更してよい注文、締め処理の時刻、取消時の扱いを確認します。技術側は、データを書き込む場所と、障害時に戻す範囲を記録します。こうして段階ごとの完了条件を決めると、単に「画面ができた」で次へ進まずに済みます。

公開前に、同じ業務を新旧で照合する

同じ入力に対し、表示、金額、状態、通知が意図どおりになるかを確かめます。変えると決めた仕様は例外として記録し、それ以外の違いを調べます。

移行時のテスト項目で完了条件を作り、再構築サービスでは調査・設計・実装・切り替えを分けて見積もります。現在の環境の脆弱性対応は、既存の運用担当者と並行して進めてください。