サーバー移転の実務手順｜メールを止めないための段取り

2026.08.282026.10.03

最終確認：2026年10月3日

サーバー移転は、サイトのデータをコピーしてDNSを変更すれば終わる作業ではありません。メール、SSL、フォーム、定期処理、更新中のデータも引き継ぐ必要があります。まず、Webだけを移すのか、メールやDNS管理も移すのかを決めます。

メールが新旧どちらに届くかが切り替わる期間には、両方で受信を確認できる状態を保ちます。Webも、予約・注文・会員情報を新旧に別々に書き込まない計画が必要です。「必ず無停止」「1週間後なら解約してよい」と一律に決めず、確認結果から終了を判断してください。

移すものと残すものを、最初に分ける

スクロールできます

変更する範囲	主な作業	残す設定・注意点
Webだけを移す	ファイル・DB・PHP・SSL・Webの接続先を準備	メール配送先と認証設定を維持。フォームの送信経路は別途確認
Webとメールを移す	上記に加え、メールアカウント・保存メール・送受信設定を移す	新旧双方の受信、差分メール、端末設定、転送・共有メールを確認
DNS管理も移す	新しいDNSに必要なレコードを用意してからNSを変更	Web、メール、認証・検証用、サブドメイン等を引き継ぐ
登録事業者や契約者を変える	ドメイン移管・契約変更の手続き	サーバー移転とは別。変更の期限・権限・DNS維持条件を確認

同じドメインでも、Webはレンタルサーバー、メールはGoogle WorkspaceやMicrosoft 365、DNSは別のサービスという構成があります。レンタルサーバーの初期設定をそのまま使うと、引き継ぐべき設定と異なることがあります。

管理情報が不明なら、先にドメイン・サーバーの調査を進めます。登録者、契約・請求先、操作権限を区別して確認してください。

移転前の台帳とバックアップ

スクロールできます

台帳に残す項目	確認する内容
DNS	管理サービス、現在のNS、A・AAAA・CNAME・MX・TXT等のレコードとTTL。管理画面のエクスポート等を保存
メール	全アドレス、別名、転送、自動返信、共有先、容量、POP・IMAP、送受信ホスト・ポート・暗号化
メール認証	SPF、DKIM、DMARCと管理担当。Web移転で送信経路が変わる場合の影響
Webの実行環境	WordPress・PHP・DBのバージョン、拡張、独自コード、容量、定期処理、外部接続
データ	ファイル・DB・メール・設定のバックアップ、取得日時、保管先、復元できることの確認
HTTPSとURL	証明書、更新方法、http・www等の転送、サブドメイン、URL一覧、Search Consoleの確認方法
契約・日程	契約者、更新・解約の期限、切り替え担当、連絡先、旧環境の維持費、切り戻しの条件

台帳にはパスワードをそのまま書かず、権限を限定した保管先を参照させます。公開のDNS照会で見える設定だけでは、非公開の設定や契約条件までは確認できません。

例えばMXの調査は nslookup -type=MX example.co.jp で行えますが、DNS管理画面の内容、メールサービスの指定、実際の送受信と照合します。SPFだけでなくDKIM・DMARCや送信サービスの設定も確認してください。

移転の8工程と、次へ進める条件

移転範囲、担当、作業日時、復旧・切り戻しの判断を決め、現状とバックアップを保存します。
新環境を準備し、必要なPHP・DB・SSL・メール・容量・権限・定期処理を設定します。
切り替えるDNSレコードとTTLを確認し、変更できる場合は事前にTTLを短くします。
サイトと必要なメールをコピーします。更新が続くデータは、初回コピー後の差分をどう反映するか決めます。
DNSを切り替える前に、新環境を確認します。表示、ログイン、必要な機能、HTTPS、送信経路を検証します。
更新・注文・予約等の停止や差分反映が必要なら実施し、担当者が切り替え可能と判断します。
計画したDNSだけを変更し、新旧のWeb・メール、外部からの利用、エラーと送受信を監視します。
旧環境の利用、未移行データ、復旧の必要性、契約条件を確認してから、旧環境を終了します。

所要時間はデータ量、メール件数、独自機能、担当者、サービス条件で変わります。工程ごとに「担当」「予定」「確認結果」「未処理」を記入して日程を決めます。休日・平日より、障害時に必要な担当とサポートが対応できる時間を優先してください。

TTLとDNSの変更で気を付けること

TTLはDNSレコードがキャッシュされる時間の指定です。短くしても、変更前の値で残っているキャッシュがその場ですべて消えるわけではありません。以前のTTLを考慮して準備し、切り替え後も旧環境を維持します。

例えばTTLが86400秒のレコードを、許容される範囲で300秒へ下げる場合、古いTTLで取得したキャッシュが残り得る期間を考慮してから接続先を変更します。これは計画の例であり、すべての変更が5分以内に完了する保証ではありません。NSの委任や端末側のキャッシュは、WebのAレコードと同じ条件とは限りません。CloudflareのTTL説明も、その違いを説明しています。

スクロールできます

作業の例	切り替え前の確認
現在のDNSを維持してWebだけ変更	必要なA・AAAA・CNAME等の変更を確認。古いAAAAだけが残るなどの不一致に注意
NSを新サービスへ変更	必要なDNS一式を新側に用意。MX、DKIM等のサブドメイン、検証用TXTも確認
Webサーバーからメールを送る	移転で送信元・SMTP接続が変わるか確認。認証とフォームの通知・自動返信を検証
問題が起きて旧側へ戻す	DNSを戻すだけで済むか確認。新側で受け付けた予約・注文・メール等の差分を保全

SSLを用意するために、確認前のDNSを不用意に切り替えないようにします。証明書の発行方法と新側の事前検証は、利用サービスの手順に従ってください。

メールを残す場合と、移す場合の手順

Webだけ移し、メールは残す

メールサービスのMXと必要な認証レコードを維持します。NSも変更するなら、新しいDNSにメールの設定を再現します。WebのAレコードだけを変える方法でも、メール用のホストが同じ接続先を使っていないかを調べてください。

フォームは表示できても、通知メールが届くとは限りません。担当者が実施する検証では、外部からの受信、外部への送信、フォームの受付、通知、自動返信を別々に確認します。迷惑メールに入らないか、送信エラーや認証の不一致がないかも調べます。

メールも移す

新側に全アドレスと必要な別名・転送・共有・容量・認証を用意します。
過去メールとフォルダーをバックアップし、初回コピーを行います。移行後の件数だけでなく、期間と代表的な添付・フォルダーも照合します。
新旧へ接続するホスト名、ポート、TLSと認証を確認し、受信先を区別して確認できるようにします。
DNSを変更し、両方で受信を確認します。初回コピー以降に旧側へ届いたメールを、追加移行します。
外部との送受信、フォーム、転送等を確認し、旧側に残ったメールと未処理を回収してから終了を判断します。

エックスサーバーの移転中の受信方法も、新旧両方で受信できる設定を案内しています。具体的なホスト名・証明書・認証の設定は、それぞれのサービスの指定に従います。同じドメインの接続先を両方の設定に使うだけでは、新旧を区別できない場合があります。

スクロールできます

方式	過去メールの扱いで確認すること
IMAP	サーバー上のメール・送信済み・フォルダーを移す。端末の表示だけをバックアップ済みと考えない
POP	各端末に保存されたメール、サーバーに残す設定、複数端末の保存を確認。旧設定を消す前に保存と復元を確認

IMAPの同期はバックアップとは役割が違います。誤った削除が同期される場合もあるため、移行前の保管と復元の方法を決めます。POPでも端末にすべて保存されているとは限らず、サーバーに残るメールの回収が必要な場合があります。

公開後の確認と、旧サーバーを解約する条件

スクロールできます

確認すること	終了を判断するための記録
Web	主要URL・画像・CSS・ログイン・予約等が新側で動く。旧側へのアクセスとエラーを確認
HTTPS・転送	証明書・更新、httpからhttps、www等が意図したURLへ到達する
メール	新旧の着信・差分回収、外部送受信、認証、転送、通知等を確認
定期処理・連携	cron、決済、通知、バックアップ等が新側で動き、重複実行していない
復旧・契約	必要な保管・復元手段、未処理なし、担当の承認、解約期限と料金を確認

URLを維持する移転でも、エラー、速度、クロールの制限などは確認が必要です。Googleのホスティング変更手順は、事前テスト、TTL、Search Consoleの確認、新旧の監視、旧環境の終了を示しています。無停止や順位への影響ゼロを保証するものではありません。