WordPressのサーバー移転には、移転先の移行機能やプラグインを使う方法と、ファイル・データベースを手動でコピーする方法があります。どちらも、新環境で確認してからDNSを切り替えるという順番は同じです。

移行機能が現在のサイトに対応していれば、手作業を減らせます。ただし、メールやDNS、外部サービスとの連携まで自動で移るとは限りません。この記事は単一のWordPressサイトを対象に、移転前の準備から切り替えまでを説明します。

同じURLなら、URLを書き換えずに移転できる

サーバーだけを変える移転と、ドメインや設置パスも変える移転を分けます。サーバーが変わっても、同じドメインと設置パスなら、閲覧する人が使うURLは変わりません。

同じURLを維持するなら、通常はファイルとDBを移し、DB接続情報とDNSの接続先を変更します。URLも変える場合は、DB内の参照変更と旧URLからの転送も必要になります。移転作業にドメイン変更まで含めるかを、制作会社と先に合意します。

現在のWordPressとPHPのバージョンを控え、テーマやプラグインが移転先の環境に対応するかを調べます。定期処理や外部APIがある場合は、その実行方法も確認します。マルチサイトは構成とURLの扱いが異なるため、この単一サイト向け手順だけで進めないでください。

メールを同時に移すかも別の判断です。メールを残すなら、MXやメール認証のレコードを維持します。ネームサーバーまで変える場合は、Webに関係しないレコードも引き継ぐ必要があります。メール移転の確認事項を分けて管理すると、WordPressの表示とメール配送の問題を混同しにくくなります。

ファイルとDBを一組で戻せるようにする

移転の控えにはファイルとDBの両方が必要です。同じ時点の状態になるように取得し、移転作業に使うコピーとは別に、変更前の控えを安全な場所へ残します。

DBには記事や設定が入り、アップロードした画像などはファイル側にあります。取得の途中で画像や記事が追加されると、DBが参照する画像が移転先にない状態になり得ます。最初のコピー時点を記録し、切り替え直前には更新停止後の最終データを取り直せるようにします。

移行プラグインを使う場合も、対象データと容量上限を確認します。アーカイブが作成できただけで成功とせず、新環境へ復元して記事と画像を照合します。DBの出力や設定ファイルには秘密情報が含まれるため、公開ディレクトリへ置きっぱなしにしてはいけません。

新環境では、ファイルの所有者と書き込み権限を移転先の標準に合わせます。PHPの更新も同時に必要なら、テーマとプラグインを先に検証します。互換性の問題を移転中に初めて発見しないよう、公開画面にエラーを表示させずログから確認します。

新環境の接続先を確認してからURLを直す

DBを複製しても、wp-config.phpが旧DBを向いたままなら本番データを変更する危険があります。DB名と接続ホストを確認し、新環境だけを操作していることを確かめます。

URLが変わらない移転では、原則としてURL置換は不要です。URLを変える場合でも、SQLの単純な文字列置換は避けます。文字列の長さなどを含むシリアライズ形式の設定を壊す可能性があるためです。WordPress公式の移転手順も、この点への注意を案内しています。

WP-CLIを利用できる担当者なら、新環境のDBを退避したうえで、まず次のような確認を行えます。/path/to/new-wordpressと二つのURLは説明用です。必ず新環境の実パスと変更前後のURLに置き換え、旧環境へ接続していないことを確認してください。

wp --path=/path/to/new-wordpress option get home
wp --path=/path/to/new-wordpress option get siteurl
wp --path=/path/to/new-wordpress search-replace \
  'https://old.example.com' 'https://new.example.com' \
  --skip-columns=guid --dry-run

--dry-runではDBを変更せず、置換対象と件数を確認します。GUIDは投稿の識別子として使われるため、移転で一律に変更しません。実際の置換は対象が正しいと確認し、復元可能な控えを確保してから行います。

また、search-replaceの既定対象はWordPressが登録するテーブルです。プラグイン独自のテーブルなどは別に確認します。見つからないデータがあるからといって、別サイトも入ったDB全体へ無条件に対象を広げてはいけません。

DNSを変えずに新サーバーで検証する

一般の訪問者を旧環境へ向けたまま、確認用の端末だけ新環境へ接続します。IPアドレスを直接開くのではなく、本番と同じホスト名で確認することが重要です。

例えばcurlを使える環境なら、次の方法で接続先だけを指定できます。www.example.comは自社のホスト名、192.0.2.10は移転先のIPへ置き換えます。記載のIPは文書用であり、実在の移転先ではありません。

curl --resolve www.example.com:443:192.0.2.10 \
  -I https://www.example.com/

この確認では、URLのホスト名を保ったままHTTPSの応答ヘッダーを取得します。証明書エラーが出ても、検証を無効化する-kを加えて合格扱いにしません。移転先で証明書を事前に用意する方法を事業者へ確認します。事前発行できない条件なら、切り替え時の停止時間も含めて手順を組み直します。

ただし、このコマンドではページ全体やフォームの動作までは分かりません。ブラウザでは確認端末のhosts設定などを使い、同じホスト名で新環境を操作します。試験後は端末の設定を戻し、公開DNSでどちらへ接続するかを確認します。

切り替え前に確認したい主な機能は次のとおりです。フォームや決済はテスト用の宛先・モードを用意し、実際の顧客へ通知や請求を出さない状態で確認してください。

確認する機能実際に行う確認切り替えを止める状態
公開ページ下層記事と画像、転送先をPC・スマホで開く画像欠落、転送ループ、証明書エラー
管理画面ログインし、テスト用下書きと画像を保存する保存失敗、権限エラー、PHPエラー
問い合わせ・予約テスト送信し、保存先と通知の到着を照合する画面上は成功でもデータや通知がない
定期処理・外部連携テスト環境で実行経路と結果を確認する二重実行、旧環境への通知、未処理データ

確認端末のhosts変更は、決済サービスや外部Webhookの接続先を変えません。外部からの処理は引き続き公開DNSを参照するため、別のテスト設定や切り替え後の確認が必要です。ブラウザでは正常でも、外部サービスからの通知だけ旧サーバーへ届く場合があるのはこのためです。

書き込みを止めて最終データを切り替える

初回コピーと動作確認が済んだら、最後に増えたデータをそろえます。停止の対象は記事編集だけでなく、予約やフォームなどDBを書き換える処理も含みます。

業務担当と停止時間を合意し、旧環境の更新受付と必要な定期処理を止めます。その状態でファイルとDBの最終データを取得し、新環境へ反映します。差分反映の仕組みがない場合は、更新停止後に一組を取り直す方が手順を明確にできます。新環境へ入れたテストデータやテスト用設定が混ざっていないかも確認します。

新環境の確認後にDNSを変更します。Aレコードだけでなく、AAAAやCDN経由の接続が残っていないかも確認します。TTLを短くする場合は事前に行いますが、すでに保存された古い回答が即座に消えるわけではありません。

切り替え中は旧環境を残しても、新旧の両方で注文や予約を受け付ける状態にはしません。旧環境へ来た人には受付停止を案内するなど、業務データの保存先を一つに保ちます。再開後は社外回線とアクセスログで新環境への到達を確認し、最初の受付データと通知を照合します。無停止が必須のサービスは、この手順だけでなくデータ同期を含む個別の移行設計が必要です。

切り戻す前に新環境へ入ったデータを守る

不具合が起きても、DNSを旧環境へ戻すだけではデータを元に戻せません。新環境で受け付けた注文や問い合わせがあるかを確認してから、切り戻しを判断します。

新環境で書き込みを再開する前なら、旧環境を復帰させる判断は比較的しやすくなります。再開後は新しい受付を止め、増えたデータを退避します。どちらを正しいデータとして扱うかを業務担当と決め、旧環境へ戻す場合は差分の移行や重複確認を先に行います。新しいDBを古い控えで上書きしてはいけません。

旧サーバーの解約は、DNSの到達確認とは別の工程です。メールや外部連携が旧環境へ依存していないことを確認し、新環境のバックアップから復元できる状態を整えます。移転直前の控えは保持し、契約情報と復元手順を自社が取り出せる場所へ引き継いでから旧契約を終了します。