「サポート終了」の通知が来て焦っている担当者・経営者へ。実案件をもとに、ダウンタイムを最小化しながら安全に移行するための手順と注意点を解説します。
こんな悩みはありませんか？
「ホスティング会社から『CentOS 7のサポートが2024年6月で終了します』というメールが届いた。でも何をどうすればいいかわからない…」
この記事を開いてくださった方の多くは、おそらくそういった状況にいるのではないでしょうか。「サポート終了」という言葉は耳にするものの、具体的に何が危険なのか、いつまでに何をすればいいのか、自分たちだけで対応できるのか——判断材料がなければ、誰だって不安になります。
結論から言うと、正しい手順を踏めば、中小企業でも十分に乗り越えられます。 ただし「気づいたら対応できていた」とはならないのがサーバー移行の難しいところ。計画なき移行は、本番サービスの停止という最悪の結果を招くこともあります。
今回はFivenineが実際に支援したクライアントの事例をもとに、「パニックにならない移行計画の立て方」を実践的に解説します。
あわせて読みたい
なぜ「サポート終了」がそれほど危険なのか
OSのサポート終了とは、ベンダー（Linuxディストリビューターやマイクロソフトなど）がセキュリティパッチの提供を打ち切ることを意味します。
一見「今まで通り動いているから問題ない」と思えるかもしれません。しかし現実はそれほど甘くない。
- 新たに発見された脆弱性が修正されなくなる：悪意ある攻撃者はサポート終了後のOSを意図的に狙います。パッチが出ないということは、穴が開いたままの状態が続くということです。
- PHPやNginxなどの依存ソフトウェアも更新できなくなる：古いOSでは新しいパッケージが動かないケースが増え、結果としてアプリケーション全体が時代遅れになります。
- PCI DSSやISMSなどのコンプライアンス違反になる：決済機能を持つサイトなどは、サポート切れOSの使用が規約違反になる場合があります。
実際にFivenineが支援したある製造業のクライアントでは、CentOS 6が稼働し続けていた問題を放置した結果、Webサーバーへの不正アクセスが発生し、問い合わせフォームのデータが一時的に外部送信されるという事態になりました。発覚から対処まで72時間。その間、Webサイト全体を閉鎖せざるを得ませんでした。
移行計画の全体像：4フェーズで考える
サーバー移行で最もやってはいけないのは「勢いで本番を切り替える」こと。段階を踏んで進めることで、リスクを劇的に下げられます。
flowchart TD
A[フェーズ1: 現状調査] --> B[フェーズ2: 新環境の構築]
B --> C[フェーズ3: 動作検証・ステージング]
C --> D{問題なし？}
D -->|No| E[修正・再検証]
E --> C
D -->|Yes| F[フェーズ4: 本番切り替え・DNS変更]
F --> G[旧環境の監視・保留期間]
G --> H[旧環境の廃止]フェーズ1：現状調査——「何が動いているか」を把握する
移行の失敗の多くは、この最初のフェーズが甘いことに起因します。「なんとなくLaravelが動いている」だけでは情報不足です。以下のコマンドで現状をすべて書き出してください。
# OSバージョン確認
cat /etc/os-release
# カーネルバージョン
uname -r
# PHP バージョンと拡張モジュール
php -v
php -m
# インストール済みパッケージ一覧
rpm -qa > installed_packages.txt # RHEL/CentOS系
dpkg -l > installed_packages.txt # Debian/Ubuntu系
# Webサーバーのバージョン
nginx -v
apache2 -v
# MySQL/MariaDBのバージョン
mysql --version
ここで注意したいのは、「動いているから大丈夫」と思っていたサードパーティ製ライブラリが、新しいPHPバージョンでは非推奨関数を使っていて動かなくなるケースです。composer outdated を実行し、更新が必要なパッケージを事前に把握しておきましょう。
フェーズ2・3：新環境の構築と検証
新サーバーはいきなり本番に使うのではなく、まずステージング環境として立ち上げます。以下はUbuntu 22.04 LTS（現在の推奨環境）を前提にした基本セットアップの例です。
# パッケージを最新化
sudo apt update && sudo apt upgrade -y
# PHP 8.2とよく使う拡張をインストール
sudo apt install -y php8.2 php8.2-fpm php8.2-mysql php8.2-xml \
php8.2-curl php8.2-mbstring php8.2-zip php8.2-bcmath
# Composerのインストール
curl -sS https://getcomposer.org/installer | php
sudo mv composer.phar /usr/local/bin/composer
# Nginxのインストール
sudo apt install -y nginx
# MariaDB（MySQL互換）
sudo apt install -y mariadb-server
sudo mysql_secure_installation
アプリケーションを新環境に配置したら、php artisan config:cache や php artisan route:cache などのキャッシュクリアを忘れずに実行してください。また、ストレージのパーミッション設定ミスはよくあるトラブル原因のひとつです。
# Laravelのパーミッション設定
chown -R www-data:www-data /var/www/your-project
chmod -R 755 /var/www/your-project/storage
chmod -R 755 /var/www/your-project/bootstrap/cache
検証フェーズでは、本番データのコピー（個人情報はマスキングを忘れずに）を使って、実際の操作を一通り確認します。「表示されている」だけでなく、フォーム送信・メール送信・ファイルアップロード・外部API連携まで漏れなくテストするのが鉄則です。
フェーズ4：本番切り替え——「TTL短縮」を忘れるな
本番切り替えの前に必ず行うべき準備が、DNSのTTL値を短縮しておくことです。
TTLとは「DNSの情報をキャッシュしておく時間」のこと。通常は3600秒（1時間）などに設定されていますが、これが長いと切り替え後も古いIPアドレスにアクセスが来てしまいます。切り替え24〜48時間前にTTLを300秒（5分）程度に変更しておきましょう。
# DNSレコードのTTL確認
dig your-domain.com +noall +answer
# 切り替え後、新サーバーのIPに変更されたか確認
nslookup your-domain.com 8.8.8.8
DNS切り替え後は旧サーバーをすぐに削除しないこと。最低1〜2週間は旧環境を維持し、万が一のロールバックに備えます。
よくある失敗パターンと対処法
自分でやる vs 専門家に依頼する
| 比較項目 | 自社対応 | 専門会社に依頼 |
|---|---|---|
| コスト | 人件費のみ（数万円〜） | 15万〜50万円程度 |
| ダウンタイムリスク | 高め（経験値による） | 低め（実績・手順書あり） |
| 対応スピード | 余裕があれば柔軟 | スケジュール管理が確実 |
| PHP・設定の最適化 | 難しい場合も | 同時対応可能 |
| 移行後のサポート | ||
| セキュリティ強化の提案 |
Web担当者がいてサーバー操作の経験がある場合は、本記事の手順で十分に自社対応できます。一方で「担当者が一人しかいない」「移行中の障害が怖い」「LaravelやWordPressのバージョンも同時に上げたい」という場合は、専門会社への依頼がトータルコストを抑える選択肢になります。
サーバー管理、丸ごとお任せください
サーバー保守・運用
監視・障害対応・パフォーマンス改善まで、安定稼働をサポートします
※ 通常1営業日以内にご返信します
まとめと次のステップ
サーバーのOS移行は、確かに複雑な作業です。しかし「現状調査 → 新環境構築 → 検証 → 本番切り替え」という4フェーズを丁寧に踏むことで、中小企業でも安全に乗り越えることができます。
大切なのは**「期限から逆算して計画を立てること」**。サポート終了日の2〜3ヶ月前には動き始めているのが理想です。
Fivenineでは、こうしたサーバー移行の計画立案から実作業まで、神奈川の中小企業を中心にご支援しています。「うちの環境でどう進めればいいかわからない」という方は、まず無料相談からお声がけください。現状を整理するだけでも、不安はぐっと軽くなるはずです。
