VtigerCRM OSSの導入・運用 ｜ バージョンアップ
VtigerCRM 7系から8.4へ移行する手順。PHP 8の互換性・500エラー・切り戻し
サーバーの更新期限が迫っている。PHPを切り替えたら画面が真っ白になった。古いVtigerCRMを長く使っているほど、顧客や案件のデータに加えて、添付、帳票、権限、外部連携が業務に組み込まれています。
本記事では、OSS版VtigerCRM 7系から8.4.0を目標に更新する場合を例に、公式パッチの選び方、PHPと拡張の互換性、検証から本番切替までの5ステップを解説します。
OS・PHPの期限と、VtigerCRMの対応範囲を確認する
CentOS Linux 7は2024年6月30日、PHP 7.4はPHPプロジェクトのセキュリティサポートが2022年11月28日に終了しました。延長サポートやベンダー独自の修正を利用している場合は、対象パッケージと契約期限を確認します。OS、Webサーバー、PHP、DB、VtigerCRM本体と拡張を台帳にまとめると、期限と更新の依存関係を見渡せます。 CentOS公式の終了日 ／ PHP公式のサポート終了一覧
VtigerCRM OSS 8.4.0は、公式リリースでPHP 8.x対応を案内しています。移行先のPHPは、具体的なマイナーバージョンで本体・拡張・外部ライブラリの動作を確認して選びます。PHPプロジェクトによるセキュリティサポート期限は、PHP 8.2が2026年末、PHP 8.3が2027年末です。PHP 8.2を使う計画なら、次の更新時期も合わせて検討します。 Vtiger OSS公式リリース ／ PHPのサポート期限
PHPを切り替えたら白画面・HTTP 500になったとき
発生時刻、直前の変更、失敗した操作を記録し、同じ時刻のWebサーバー・PHP-FPM・アプリ・DBのログを照合します。画面へのエラー詳細の表示はオフにし、閲覧を制限したログで確認します。更新を試した直後なら、プログラムだけが更新されたのか、DBの変更まで進んだのかを先に確認します。
| 症状・ログ例 | 考えられる要因 | 確認すること |
|---|---|---|
画面が白い、HTTP 500、TypeError | 旧コードや依存ライブラリが新しいPHPで停止 | 最初の致命的エラーとスタックトレースで、対象ファイル、呼び出し元、渡された値を確認。 |
| 一部機能で関数が見つからない | 削除されたAPI、PHP拡張の不足、WebとCLIの設定差 | Web側とcronが使うCLI側それぞれのPHPバージョン、読み込む設定と拡張を確認。 |
| 帳票や独自画面だけで失敗 | 旧モジュール・テンプレート・本体差分の影響 | 該当モジュールの版とログを確認。純正ファイルとの差分、対応版や代替を洗い出す。 |
Unknown column、更新後の画面が欠ける | コードとDBの不整合、スキーマ更新の未反映 | 適用したパッチ、実行ログ、DB定義を照合。失敗した状態を保全し、復元した検証用コピーで再現する。 |
PHP 8.0では、配列や Countable 以外を count() に渡すと TypeError になります。一方、未定義の配列キーへのアクセスはPHP 8で警告です。警告を例外に変換する設定やハンドラーもあり、実際に処理が止まった原因はログから判定します。 PHP公式のcount()仕様 ／ PHP 8.0の互換性変更
7系から8.4へ移行する5つの実践ステップ
Step 1 同じ時点のバックアップから検証環境を復元する
DB、VtigerCRMのプログラム・拡張一式、添付の storage、config.inc.php、user_privileges などを復元できる形で保全します。アプリ外の添付や外部保存先があれば、それも対象に含めます。DBと添付で時点がずれないよう、書き込みを止める時間や整合性を取る手段を決めます。接続情報を含むバックアップはアクセスを制限します。 Vtiger公式のバックアップ案内
アクセスを制限した別環境に復元し、旧版のままでログイン、権限、主要レコードと添付を確認します。検証側のcron・メール送受信・Webhook・外部APIの送信を初期状態では止め、試験時にテスト用の経路だけを開きます。 VtigerCRMのバックアップと復元
Step 2 本体の差分・拡張・業務上の依存関係を棚卸しする
現行の正確なバージョンの配布ファイルと比較し、本体、言語ファイル、テンプレート、外部ライブラリの差分を洗い出します。拡張ごとにモジュール名、版、提供元、関連データ、対応するPHPとVtigerCRM、再取得方法を記録します。日本語の姓名順、PDF、ワークフロー、cron、外部連携も利用部門に確認します。
各機能に「継続」「更新」「置換」「廃止」を割り当てます。拡張を無効化する場合は関連画面やジョブへの影響を検証し、アンインストールがデータを削除するかは事前に確認します。残す機能は拡張として再実装できる範囲も検討します。 標準設定・拡張・個別開発の境界線
Step 3 公式パッチの対象版を合わせ、段階ごとにDB更新を確かめる
ソースとDBの現行バージョンを照合し、各パッチの移行元・移行先、実行時に使うPHPとDB、必要な拡張、空き容量を記録します。次の表は、7.4.0正式版を起点に公式の個別パッチを順につなぐ例です。7.5.0や8.0.0からなら該当する段階から検討します。6系や古い7系は正確な起点に対応する配布物と中間環境を別途調べます。
| 移行元 | 移行先 | 公式配布パッチ |
|---|---|---|
| 7.4.0 GA | 7.5.0 | vtigercrm-740GA-750-patch.zip |
| 7.5.0 | 8.0.0 | vtigercrm-750-800-patch.zip |
| 8.0.0 | 8.1.0 | vtigercrm-800-810-patch.zip |
| 8.1.0 | 8.2.0 | vtigercrm-810-820-patch.zip |
| 8.2.0 | 8.3.0 | vtigercrm-820-830-patch.zip |
| 8.3.0 | 8.4.0 | vtigercrm-830-840-patch.zip |
検証用コピーで、各パッチの手順に従って配布物を展開し、アクセスを制限した /migrate のウィザードで処理します。段階ごとにソース・DBバージョン、SQLの失敗、変更対象のテーブル・カラム、ログインを確認し、復元できる状態を保存してから次へ進みます。タイムアウトやメモリ上限は測定結果をもとに調整し、途中失敗時はログを保存して、整合した直前の状態を復元してから再試行します。 Vtiger公式のマイグレーション手順
8.3.0 → 8.4.0では、DB更新が実行されたことを照合します。
確認した公開ZIPでは、8.2.0 → 8.3.0のパッチに含まれる移行元バージョン一覧に 830 がなく、8.3.0 → 8.4.0のパッチはその一覧を差し替えません。配布コードを照合した結果、この組み合わせでは 830_to_840.php が選ばれない可能性があります。バージョン表示に加え、利用環境で該当するMailScanner・Webフォームのテーブル定義やデータ、メール取り込み・フォーム登録の結果を確認します。未反映なら次へ進まず、適用したパッチとログをもとに調査します。 8.3.0の配布パッチ ／ 8.4.0の配布パッチ
Step 4 PHP 8の移行先で、日本語表示・拡張・定期処理を確認する
PHPを切り替える時点は、更新前後のコードとパッチの前提を突き合わせ、リハーサルで決めます。移行先ではWebとCLIそれぞれのPHP設定と拡張、DBの文字コード・照合順序、権限、cronの実行コマンドを確認します。互換性検証に旧PHPが必要な場合は、外部公開しない一時環境で扱います。
対応する日本語言語パックと拡張を検証し、姓・名、一覧・詳細、メール差し込み、日本語PDF、CSV入出力、添付の閲覧・保存を試します。古い本体ファイルの持ち込みは、必要な差分と新環境への実装方法を先に確認します。 日本語言語パックの案内 ／ 日本仕様化の5つの確認項目
Step 5 合格条件と切り戻しの時刻を決めて本番を切り替える
リハーサルで最終バックアップ、DB更新、添付同期、業務試験にかかる時間を計ります。本番切替では、旧環境の利用者・フォーム・APIからの書き込みと定期処理を止め、最終データを取り込みます。新環境を限定公開して合格条件を確認し、公開先を切り替えた後に新環境の連携・cronだけを再開します。DNSなどの切替が反映される間も旧環境への書き込みを止め、二重処理を防ぎます。
| 確認領域 | 確認する操作や証跡 | 切り戻しを検討する例 |
|---|---|---|
| データ・添付 | 主要モジュールの件数、代表案件の関連・金額、複数年代の添付の取得 | 想定外の欠落、添付を開けない、案件が別の企業にひも付く。 |
| 業務・権限 | 一般ユーザーのログイン、作成・編集、権限どおりの閲覧、見積・請求PDF | 主要業務が完了しない、見えるべきでないデータが見える。 |
| 連携・定期処理 | メール、Webフォーム、外部API、cronを承認したテスト条件で確認 | 未処理が滞留する、同じ通知や外部データが二重に作成される。 |
切り戻しの判断者と最終判断時刻を先に決めます。戻す場合は新環境への書き込みとジョブを止め、DB・プログラム・添付が同じ時点の旧環境へ戻します。新環境を開放した後の入力、メールや外部連携の送信済みデータは別途保全し、再入力・照合の扱いを決めます。
現行を引き継ぐ段階更新か、新規環境への再構築か
段階更新は、現行の構成とDBを引き継ぎながら更新する方法です。別サーバーにコピーして段階更新し、検証済みの新環境に切り替える構成も選べます。再構築は新規環境に項目や権限を設計し、必要なデータと関連を移す方法です。
| 判断軸 | 現行環境を引き継ぐ段階更新 | 新規環境への再構築 |
|---|---|---|
| 履歴・関連・設定 | レコードの関連や既存の項目・権限を広く維持したい。互換性と更新結果を確認する。 | 必要な情報を選び、項目や権限を整理したい。履歴・添付・独自モジュールの移行方法を定義する。 |
| 独自改修・拡張 | 変更箇所を追え、対応版や置き換えの見通しがある。 | 古い改修や運用を整理し、必要な業務だけを新環境で再現する。 |
| 停止時間・費用 | 各段階の作業時間、エラー修正、最終反映と復元を試算する。 | 項目対応、IDの突き合わせ、関係・履歴の復元、差分取り込みと現場確認を試算する。 |
判断に迷ったら、顧客1社分の案件・活動・添付を使い、保持すべき関連と工数を比較します。CSVで運べる範囲を確認し、コメント、履歴、添付、作成者・日時などが必要なら個別に移行方法を決めます。 CSVインポートとデータ移行の実務ガイド
vtplusへの移行も、引き継ぐ業務とデータから決める
vtplusでは、OSS版VtigerCRMを基盤に、現行環境の確認、移行設計、業務支援アプリの導入を相談できます。日本語表示や帳票などは、旧環境で必要だった改修を洗い出し、既存のアプリで置き換えられる範囲を確認します。商談や問い合わせ履歴をAIで使いたい場合は、残すデータ、利用する機能、外部に送信する情報を決めます。 vtplusの業務支援アプリ一覧 ／ VtigerCRMの生成AI活用例
費用は、履歴・添付・関連の移行範囲と、サーバー保守や更新支援の分担を整理して見積もります。切替後の監視、パッチ適用、バックアップ確認、復旧作業は、誰がどこまで担当するかを契約時に確認します。 vtplusの料金・導入支援 ／ 100名・5年間のTCO比較
vtplus ｜ バージョンアップ・移行支援
現在のVtigerCRMを起点に、移行経路を相談する
VtigerCRM・OS・PHP・DBのバージョン、主な拡張、DBと添付のおおよその容量、停止できる時間をお知らせください。白画面などの障害がある場合は、発生時刻と機密情報を除いたエラー概要から、復旧・段階更新・再構築の検討を始められます。