サーバー移転では、Webサイトのファイルをコピーするだけでは不十分です。DNS、SSL、データベース、会社メール、フォーム、外部サービスを計画的に切り替えなければ、サイト停止やメール未着が起こります。
完全な無停止を保証することは難しくても、旧環境と新環境を並行稼働し、戻せる状態を保てばリスクを大幅に減らせます。安全な移転手順を解説します。
最初に移転範囲を決める
何を変更し、何を維持するかを整理します。
- Webサーバーだけ
- WordPressとデータベース
- 会社メール
- DNS管理
- ドメイン登録事業者
- SSL・CDN・WAF
- バックアップ・監視
- フォームや外部連携
ドメイン移管、サーバー移転、DNS変更は別作業です。同時実施が必要か判断します。
現行環境を棚卸しする
- サーバー会社・契約プラン
- PHP・データベース・容量
- WordPress・テーマ・プラグイン
- 独自設定・定期処理
- DNS全レコード
- メールアカウント・転送・メーリングリスト
- SSL・CDN・WAF
- GA4・GTM・Search Console
- 外部API・フォーム・予約・決済
- バックアップと復元手順
分からない設定を移転直前に調べると遅れます。
責任者と連絡経路を決める
自社責任者、旧サーバー担当、新サーバー担当、制作会社、メール管理者の役割を決めます。切り替え判断と、問題時に戻す判断をする人を明確にします。
会社メールが止まった場合でも連絡できる、別系統の電話・チャットを用意します。
移転前にバックアップする
WordPressのファイルとデータベース、DNS設定、メール設定を保存します。バックアップ日時と取得者を記録し、検証環境へ復元できることを確認します。
切り替え直前にも差分バックアップを取ります。
新サーバーを先に構築する
旧サイトを公開したまま、新サーバーへデータを複製します。PHP、データベース、SSL、ファイル権限、キャッシュなどを設定します。
本番ドメインを切り替える前に、hosts設定や検証用URLを使って新環境を確認します。
新環境で確認すること
- 全主要ページ
- スマートフォン表示
- WordPress管理画面
- 画像・PDF・検索
- 問い合わせフォーム
- 予約・決済・会員
- 外部API・地図・動画
- URLとリダイレクト
- 表示速度・エラーログ
- バックアップ・監視
本番と同じ条件でできない項目は、切り替え直後の優先テストに入れます。
更新差分を止める・同期する
移転準備中も記事、問い合わせ、注文が増えるサイトでは、最初のコピー後に差分が生まれます。切り替え前に更新停止時間を設けるか、データを同期する方法を決めます。
担当者へ更新停止の開始・終了時刻を案内します。
DNSのTTLを確認する
DNS情報が各所に保持される時間をTTLで制御します。移転前にTTLを短くすると切り替えが早まる場合がありますが、変更が反映されるまで時間が必要です。
現在値と変更時刻を記録し、移転後に適切な値へ戻します。
メール移転は別計画にする
Webとメールが同じドメインでも、接続先と作業は別です。現在のMX、SPF、DKIM、DMARC、メールアカウント、転送、容量を確認します。
Webだけ移すなら、既存メールのDNSレコードを維持します。
メールデータを移す
メールサーバーも変える場合は、アカウント、パスワード、過去メール、フォルダー、連絡先、転送を移行します。端末・スマートフォンの再設定手順も用意します。
IMAP同期など方法は環境によって異なります。保持対象と移行できないデータを事前に伝えます。
新旧メールを並行して確認する
DNS切り替え後も、送信者側の参照先が一斉には変わらない場合があります。旧・新の両メールボックスを一定期間確認し、未着を防ぎます。
旧環境をすぐ解約せず、転送や同期が必要か判断します。
SSLを準備する
新サーバーで本番ドメインの証明書を発行・設定します。DNS切り替え前に発行できない場合は、切り替え直後の手順を決めます。
httpからhttps、www有無のリダイレクトも確認します。
DNS切り替え
アクセスが少なく、担当者が対応できる時間帯に実施します。WebのA・AAAA・CNAME、メールのMX・TXTなど、変更対象だけを正確に更新します。
変更前後の画面と値を保存します。
切り替え直後の確認
ホームページ
- 別回線・複数端末で新環境へ到達する
- 主要ページと管理画面
- フォーム送信と受信
- SSL・リダイレクト
- 予約・決済・外部連携
- GA4・GTMの発火
メール
- 社内から社外へ送信
- 社外から社内へ受信
- 複数アカウント・転送
- SPF・DKIM・DMARC
- 迷惑メール判定
- 旧メールボックスへの着信
テスト時刻と結果を記録します。
問題時の切り戻し
戻す条件と担当者を事前に決めます。新環境の修正に時間がかかり、業務影響が大きい場合はDNSを旧環境へ戻します。
ただし切り替え後に新環境で増えたデータを失わないよう、差分を保全します。
旧サーバーをすぐ解約しない
DNSの浸透、メールの旧環境着信、未発見機能を確認する期間を置きます。一般的には数日から数週間、サイト特性と契約に合わせます。
安定確認後に最終バックアップを取り、個人情報を適切に削除して解約します。
Search ConsoleとSEOの確認
URLを変えないサーバー移転でも、クロールエラー、表示速度、robots.txt、サイトマップ、リダイレクトを確認します。Search Consoleの所有権確認がDNSに依存する場合、TXTレコードを維持します。
URL変更を伴う場合は、旧新対応表と301リダイレクトが別途必要です。
GA4・GTMの確認
移転時にタグが欠落したり、旧実装と新実装が重複したりすることがあります。Tag AssistantとGA4 DebugViewまたはリアルタイムで、ページビューと主要イベントが一回だけ発火することを確認します。
Cookie同意や外部フォームも対象です。
移転スケジュール例
2〜4週間前
棚卸し、新環境契約、データ複製、メール計画、TTL確認。
1週間前
新環境テスト、社内案内、バックアップ・切り戻し確認。
前日
差分同期、更新停止、最終設定確認。
当日
最終バックアップ、DNS切り替え、サイト・メール・計測テスト。
翌日以降
ログ、旧メール、Search Console、問い合わせを監視。
安定後
TTLを戻し、最終バックアップと権限整理後に旧契約を終了。
制作会社へ確認する質問
- Webとメールの影響範囲を調査したか
- DNS全レコードを保存したか
- 新環境を切り替え前にテストできるか
- 更新差分をどう同期するか
- SSL発行のタイミングはいつか
- 切り戻し条件と所要時間は何か
- 新旧環境を何日並行稼働するか
- 移転後の監視と保証は何か
- GA4・GTM・Search Consoleを確認するか
まとめ
サーバー移転でホームページとメールを止めないためには、現行環境を棚卸しし、新サーバーを先に構築・検証してからDNSを切り替えます。
Webとメールを別々に計画し、新旧環境を並行稼働させ、問題時に戻せる状態を保ちましょう。移転後はフォーム、メール、SSL、計測、検索を確認し、安定してから旧サーバーを解約します。