サーバー移行の手順と注意点まとめ（DNS切り替えまでの全体像）

サーバー移行は「ファイルとデータベースをコピーして DNS を切り替える」作業ですが、失敗の多くはコピーそのものではなく、事前準備と切り替えの段取りで起きます。この記事では、WordPress などの Web サイトを旧サーバーから新サーバーへ移すときの全体の流れを、計画・コピー・動作確認・DNS 切り替え・切り替え後の確認の順に説明します。プラグインに頼らず手作業で移す前提ですが、考え方はツールを使う場合も同じです。

移行前の計画：何を移すかを洗い出す

最初に、旧サーバーで動いているものを一覧にします。Web サイトのファイルとデータベースだけを移して、ほかの機能が止まるケースがよくあるためです。

• Web サイトのファイル（WordPress なら wp-content 一式と wp-config.php、.htaccess）
• データベース（名前・文字コード・サイズ）
• メール（同じサーバーでメールを受けているか。MX レコードの向き先）
• cron（定期実行のバックアップ・バッチ処理）
• SSL 証明書の取得方法（Let's Encrypt か、購入した証明書か）
• PHP のバージョンと拡張モジュール、php.ini の上限値（アップロードサイズ、メモリ）
• サーバー固有の設定（Basic 認証、IP 制限、リダイレクト）

新サーバーでは、PHP やデータベースのバージョンを旧サーバーと同じか、サイトが対応している新しいバージョンに合わせます。移行と同時に PHP のメジャーバージョンを上げると、不具合が出たときに原因が移行なのかバージョンなのか切り分けにくくなります。可能なら、移行とバージョンアップは別の日に分けてください。サイトが対応している PHP のバージョンは、WordPress 本体・テーマ・主要プラグインの公式情報で確認します。推奨される PHP のバージョンは WordPress.org の要件ページに掲載されています（2026年10月現在）。

DNS の TTL を先に短くしておく

DNS の切り替えは、設定を変えた瞬間に全員へ反映されるわけではありません。各地の DNS キャッシュが、レコードに設定された TTL（キャッシュしてよい秒数）の間、古い IP アドレスを返し続けます。

移行日の1〜2日前までに、対象の A レコード（と AAAA レコード）の TTL を300秒程度に下げておきます。こうすると、切り替え後に古い情報が残る時間が短くなり、問題があったときに戻すのも速くなります。TTL の変更自体も、元の TTL の時間が過ぎるまでは行き渡らないので、直前に下げても効果が出ない点に注意してください。

ファイルとデータベースをコピーする

作業前に、旧サーバーのフルバックアップを取ります。コピー作業中の操作ミスで旧環境を壊すと、戻る場所がなくなるためです。

ファイルのコピー

サーバー間で SSH が使えるなら、rsync が便利です。転送が途中で切れても続きから再開でき、2回目以降は差分だけを送ります。

# 新サーバー側で実行する例（パスは環境に合わせて変更）
rsync -avz --progress \
  olduser@old.example.com:/var/www/example.com/ \
  /var/www/example.com/

コピー元パスの末尾に / を付けるかどうかで、ディレクトリそのものを作るか中身だけを送るかが変わります。最初は --dry-run を付けて、どこに何がコピーされるかを確認すると安全です。コピー後は、Web サーバーの実行ユーザーがファイルを読めるよう、所有者とパーミッションを確認します。

データベースのコピー

MySQL・MariaDB では mysqldump でエクスポートし、新サーバーでインポートします。WP-CLI が使えるなら wp db export / wp db import でも同じことができます。

# 旧サーバー：エクスポート（InnoDB ならロックを抑えて取得できる）
mysqldump --single-transaction --default-character-set=utf8mb4 \
  -u dbuser -p dbname > dbname.sql

# 新サーバー：空のデータベースを作成してからインポート
mysql -u dbuser -p dbname < dbname.sql

文字コードの指定を誤ると、日本語や絵文字が「?」に化けることがあります。旧データベースの文字コード（多くは utf8mb4）に合わせてください。新サーバーのデータベース名・ユーザー名・パスワードが変わる場合は、wp-config.php の DB_NAME などを書き換えます。

DNS を切り替える前に新サーバーで確認する

DNS を切り替える前に、新サーバーで正しく表示されるかを確かめます。手元の PC の hosts ファイルに新サーバーの IP アドレスとドメイン名を書くと、自分の PC だけが新サーバーを見に行くようになります。

# 例：Windows は C:\Windows\System32\drivers\etc\hosts
#     macOS / Linux は /etc/hosts
203.0.113.10  example.com  www.example.com

この状態で、トップページ、固定ページ、画像、問い合わせフォーム、管理画面へのログインを一通り確認します。確認が終わったら、hosts の記述は消してください。残したままにすると、後で自分だけ古い表示を見続ける原因になります。

SSL 証明書は注意が必要です。Let's Encrypt の一般的な HTTP 認証は、ドメインが新サーバーを向いていないと通りません。DNS 認証で事前に取得するか、切り替え直後に取得するか、手順を決めておきます。

ドメインが変わる移行では、データベース内の URL も置き換えます。WordPress の設定値には PHP のシリアライズ形式で保存された値があり、単純な文字列置換では壊れることがあります。WP-CLI の wp search-replace はこれを考慮して置換するので、まず --dry-run で件数を確認してから実行します。

wp search-replace 'https://old.example.com' 'https://new.example.com' \
  --all-tables --skip-columns=guid --dry-run

DNS の切り替えと更新停止期間

コピーした時点から切り替えまでの間に、旧サーバーで投稿・コメント・注文・会員登録があると、その分は新サーバーに入りません。更新が多いサイトでは、次の段取りにすると差分の取りこぼしを防げます。

1. 切り替え時刻を告知し、その時間帯は投稿やコメントを止める（EC サイトならメンテナンス表示にする）
2. 直前にもう一度 rsync とデータベースのエクスポート・インポートを行い、最新の状態にそろえる
3. DNS の A レコードを新サーバーの IP アドレスに変更する

切り替え後もしばらくは旧サーバーにアクセスが届くことがあるので、旧サーバーはすぐに解約せず、少なくとも数日は残しておきます。旧サーバーのアクセスログが止まったことを確認してから停止するのが安全です。

切り替え後に確認すること

• dig example.com +short などで、DNS が新サーバーの IP アドレスを返しているか
• HTTPS で表示され、証明書の有効期限と更新設定（自動更新の cron や systemd タイマー）が動いているか
• パーマリンクが機能しているか（個別記事が404にならないか。WordPress なら設定画面でパーマリンク設定を保存し直すと書き換えルールが再生成される）
• メールの送受信。MX レコードや SPF レコードの向き先が変わっていないか
• cron やバックアップが新サーバーで動いているか
• 問い合わせフォームの送信、会員ログイン、決済などの重要な機能

確認が終わったら、DNS の TTL を元の値に戻します。

まとめ

• 移行前に、ファイル・データベース以外のメール・cron・SSL・サーバー設定まで洗い出す。
• DNS の TTL は移行の1〜2日前までに短くしておく。
• 旧サーバーのバックアップを取ってから、rsync と mysqldump（または WP-CLI）でコピーする。
• 切り替え前に hosts ファイルで新サーバーを確認し、URL の置換は wp search-replace を --dry-run から。
• 更新停止の時間を決めて差分をそろえ、切り替え後もしばらく旧サーバーを残す。

• サーバー移行後に404エラーが出るときの対処法
• Let's Encryptの証明書を自動更新する方法