サーバー移転後の「あれが動かない」を防ぐ！本番移行前チェックリスト完全版

サーバー移転後に発生しがちな不具合を未然に防ぐ、実践的な動作確認チェックリストを公開。LaravelやWordPressの移行経験をもとに、見落としやすいポイントを網羅的に解説します。

「移行したら全部壊れた」——その経験、ありませんか？

サーバー移転のプロジェクトが終盤を迎えたとき、担当者が最も緊張するのは「本番切り替えの瞬間」ではないでしょうか。

DNSを向け替えてホッとしたのも束の間、「問い合わせフォームから返信が届かない」「管理画面にログインできない」「画像が全部404になった」——こういった報告が次々に届いてパニックになる。これはWeb制作の現場でよく耳にするシナリオです。

弊社でもかつて、移転直後にメール送信のSMTP設定が旧サーバーのままになっていたことに気づかず、問い合わせが2日間消えていたという苦い経験があります。「テストでは動いていたのに」という焦りの中で原因を探す時間は、精神的にも業務的にも大きなコストになります。

この記事では、**20年以上のWeb制作実績をもとに整理した「本番移行前の動作確認チェックリスト」**を体系的に公開します。Laravel・WordPress・Next.jsそれぞれの観点も交えながら、移行後トラブルをゼロに近づけるための実践手順をお伝えします。

なぜ「テストで動いていたのに」が起きるのか

サーバー移転後のトラブルには、大きく分けて3つの原因があります。

① 環境変数・設定ファイルの取りこぼし

開発・ステージング・本番でそれぞれ異なる設定を使うのが標準的なプロジェクト構成ですが、移転作業の中でこの切り替えが漏れるケースが非常に多いです。特に .env ファイルはGit管理から除外されていることが多く、手動コピーが必要なため見落としが起きやすい。

② パーミッション・ファイル権限の違い

旧サーバーで777など甘い権限設定をしていた場合、新サーバーで正しい権限に戻した結果、ファイルの書き込みやキャッシュ生成が失敗するパターンがあります。逆に権限を引き継いだことでセキュリティリスクが残るケースも。

③ PHPバージョン・拡張機能の差異

旧サーバーがPHP 7.4で新サーバーがPHP 8.2、という組み合わせでは非推奨構文や廃止された関数が原因でエラーが出ます。ローカルやステージングで動作確認していても、本番のPHPバージョンが違えば意味がありません。

これらは「移転すれば自動的に引き継がれるもの」と思い込んでいると見逃してしまいます。チェックリストで一つひとつ明示的に確認するしかありません。

本番移行前チェックリスト：フェーズ別完全版

動作確認は「フェーズ分け」が重要です。一気に全部確認しようとすると抜け漏れが出ます。**「インフラ層 → アプリケーション層 → 機能層」**の順に進めてください。

フェーズ1：インフラ・サーバー環境の確認

まず、アプリケーションが動く土台を確認します。

# PHPバージョンの確認
php -v

# 有効な拡張モジュールの確認
php -m | grep -E 'mbstring|pdo|gd|curl|zip|intl'

# Composerバージョン
composer --version

# Webサーバーの設定確認（Nginx）
nginx -t

# SSL証明書の有効期限確認
openssl s_client -connect your-domain.com:443 -servername your-domain.com 2>/dev/null | openssl x509 -noout -dates

PHPの拡張モジュールは、Laravelでいえばmbstring・pdo_mysql・openssl・tokenizer・xmlが最低限必要です。本番サーバーに不足があると、composerのインストール段階でエラーになります。

フェーズ2：環境設定・接続情報の確認

# .envファイルの内容確認（必ず本番用の値になっているか）
cat .env | grep -E 'APP_ENV|APP_DEBUG|DB_HOST|MAIL_HOST|QUEUE_CONNECTION'

# 期待される出力
# APP_ENV=production
# APP_DEBUG=false
# DB_HOST=本番DBホスト名
# MAIL_HOST=本番SMTPホスト名
# QUEUE_CONNECTION=redis（またはdatabase）

# アプリケーションキーの確認
php artisan key:generate --show

# DBマイグレーション状態の確認
php artisan migrate:status

# キャッシュのクリアと再生成
php artisan config:cache
php artisan route:cache
php artisan view:cache

# wp-config.phpのDB設定確認
grep -E 'DB_HOST|DB_NAME|DB_USER|WP_DEBUG|SITEURL' wp-config.php

# WP-CLIで接続確認
wp db check

# サイトURLの確認・更新
wp option get siteurl
wp option get home

# パーマリンク設定の再保存（.htaccessの再生成）
wp rewrite flush --hard

# プラグインの状態確認
wp plugin list --status=active

フェーズ3：ストレージ・パーミッションの確認

# Laravelのパーミッション設定
chmod -R 755 /var/www/html
chmod -R 775 storage bootstrap/cache
chown -R www-data:www-data storage bootstrap/cache

# 書き込み可能か確認
php artisan storage:link
ls -la public/storage

# ログファイルに権限エラーが出ていないか確認
tail -n 50 storage/logs/laravel.log | grep -i 'permission\|denied'

よくある落とし穴は、storage/framework/sessions や storage/framework/cache のディレクトリが存在しないケースです。Gitで管理されていないため、新サーバーでは空の場合があります。

# 必要なディレクトリを明示的に作成
mkdir -p storage/framework/{sessions,views,cache}
chmod -R 775 storage

フェーズ4：機能動作確認（手動テスト）

ここからは実際にブラウザ・コマンドラインで動作を確認します。本番DNSを切り替える前に hosts ファイルを使って先行確認するのが鉄則です。

# Macの場合：hostsファイルを編集して新サーバーIPを向ける
sudo nano /etc/hosts
# 末尾に追加
# 203.0.113.1  your-domain.com

# 確認が終わったら必ず元に戻すこと

この状態でブラウザから確認すべき項目は以下のとおりです。

flowchart TD
    A[ホストファイルで新サーバーを向ける] --> B[トップページの表示確認]
    B --> C{正常表示？}
    C -->|No| D[エラーログ確認・修正]
    C -->|Yes| E[ログイン・認証確認]
    E --> F[フォーム送信・メール到達確認]
    F --> G[ファイルアップロード確認]
    G --> H[外部API・決済連携確認]
    H --> I[SSL・httpsリダイレクト確認]
    I --> J[DNS切り替え本番反映]
    D --> B

よくある失敗パターンと対処法

❌ 失敗1：メールが届かない（SMTP設定漏れ）

発生状況：移転後、問い合わせフォームへの自動返信メールが届かない。

原因：.env の MAIL_HOST が旧サーバーのローカルSMTPのまま。または新サーバーの25番ポートが外部向けにブロックされている。

対処法：SendGridやAWS SESなどのメール配信サービスを利用し、SMTPの認証情報を明示的に設定する。移転タイミングでSendGrid等へ移行するのが安全策です。

# Laravelでメール送信テスト
php artisan tinker
>>> Mail::raw('テスト送信', function($m){ $m->to('[email protected]')->subject('移転テスト'); });

❌ 失敗2：画像・メディアファイルが全部404

発生状況：テキストは表示されるが画像が軒並みブロークン。

原因：WordPressのメディアファイルをrsyncで転送する際、wp-content/uploads の転送が漏れていた。またはLaravelの storage:link を実行していなかった。

対処法：移転後すぐに find /var/www/html/public -name '*.jpg' -o -name '*.png' | wc -l などでファイル数を旧サーバーと比較する。

❌ 失敗3：Cronジョブが止まっている

発生状況：移転後2〜3日で「自動集計されない」「バッチ処理が動いていない」と連絡が来る。

原因：新サーバーのcrontabにLaravelスケジューラーやWordPressのWP-Cronが登録されていなかった。

# 新サーバーのcrontabを必ず確認
crontab -l

# Laravelスケジューラーの登録例
* * * * * cd /var/www/html && php artisan schedule:run >> /dev/null 2>&1

まとめ：移転は「切り替える瞬間」ではなく「準備8割」

サーバー移転で本当に怖いのは、DNS切り替え後の1〜2時間です。この時間帯は旧サーバーと新サーバーの両方が稼働しており、ユーザーによって見えている環境が異なります。問題が発覚しても「どちらのサーバーで起きているのか」の切り分けに時間を取られがちです。

「本番切り替え後に直す」ではなく、「切り替え前に完璧にする」——この意識が、移転プロジェクトの成否を分けます。

弊社では移転案件において、必ずDNS切り替え前日にステージング環境でのフルチェックを実施し、担当者・クライアント双方が確認してから本番反映する運用を徹底しています。それでも想定外が起きることはありますが、チェックリストの徹底によってトラブル発生率は大幅に下がりました。

まず取り組むべきは、自社の環境に合わせたチェックリストをドキュメント化しておくことです。移転のたびにゼロから確認項目を思い出すのではなく、蓄積した知見を形式知として残してください。

サーバー移転の計画段階からサポートが必要な場合や、「移転後に不具合が出てしまった」という緊急対応のご相談は、Fivenine Designまでお気軽にどうぞ。インフラ構成の見直しから移転作業の代行まで、状況に応じてご提案します。

本番移行前チェックリスト（保存版）