サーバー移行（引っ越し・移転）の手順を完全解説｜失敗しない全体像とチェックリスト

サーバー移行（引っ越し・移転）は、手順そのものはシンプルですが、Web・メール・ドメイン（DNS）・SSLなど「切り替えが絡む要素」が複数あるため、段取りを間違えると"サイトが見れない""メールが届かない"といったトラブルにつながりやすい作業です。

この記事では、サーバー移行の全体像をまず整理し、事前準備〜事前テスト〜切り替え当日〜移行後確認までをチェックリスト形式で解説します。メール移行や「ドメインそのまま」、WordPress特有の注意点、代行を検討すべき判断基準は各章で触れ、必要に応じて詳細記事へ案内します。

サーバー移行で「やること」は何が変わる？全体像を先に整理

サーバー移行（引っ越し・移転）は、「サーバー会社を変える作業」と思われがちですが、実際は"何を移すのか（対象）"と"どこを切り替えるのか（切替ポイント）"で、やることが大きく変わります。
たとえば、Webサイトだけ移すのか、メールも移すのか、ドメイン（DNS）をどこで管理しているのか――この違いを最初に整理しないと、「移行は終わったはずなのにサイトが表示されない」「メールが届かない」などのトラブルが起きやすくなります。

そこで本章では、まずサーバー移行の全体像を「対象」と「方式」に分解して整理します。ここが理解できると、次章以降のチェックリスト（準備→テスト→切替→確認）を迷わず進められます。

移行対象のパターン（Web／メール／DNS／SSL）

サーバー移行で扱う要素は、大きく分けてWeb（サイト）、メール、ドメイン（DNS）、SSL（https）の4つです。
「サーバーだけ替える」つもりでも、実際はこの4つが連動しているため、どこまでが移行範囲なのかを先に決めておく必要があります。

まずWeb（サイト）は、HTMLや画像などのファイルに加えて、WordPress等のCMSであればデータベース（DB）もセットで移す必要があります。Web移行が完了していても、DNS切替が未実施なら、新サーバーのサイトは外部から見えません。

次にメールは、メールアドレス自体（例：info@〜）が同じでも、実体は「どのサーバーで受信・送信するか」をDNSのMXレコードなどで決めています。ここを理解せずに切替すると、「受信だけ旧サーバー」「送信だけ新サーバー」などの中途半端な状態になり、メール不達の原因になりがちです。

ドメイン（DNS）は、サイトやメールの"行き先"を決める司令塔です。ドメインを管理している場所（レジストラ／DNSサービス／サーバー会社のDNS）によって、切替の画面や操作が変わります。特に「ドメインそのまま」の移行は、ドメイン移管の話ではなく、DNSの向き先を変える話であるケースが多いので、混同しないようにしましょう。

最後にSSL（https）は、移行後に「鍵マークが外れる」「警告が出る」など、見た目で気づきやすいトラブル要因です。SSL証明書を新サーバーで再発行するのか、CDNやWAF側で終端しているのかで対応が変わるため、移行計画の段階で確認しておくと安全です。

移行方式（同時稼働・DNS切替・ダウンタイムの考え方）

サーバー移行は「データを移す」だけでは完了しません。最後に必ずアクセスの向き先（どのサーバーを見に行くか）を切り替える工程があり、ここで採用するのが移行方式です。
方式を決めずに進めると、切替当日に慌ててしまい「サイトが見れない時間が長い」「メールが届かない」といったトラブルにつながりやすくなります。

移行方式は大きく分けて①同時稼働（併用）と②DNS切替をどう組み合わせるか、そしてダウンタイムを許容するかで決まります。ここでは初心者の方でも判断できるように、基本の考え方を整理します。

①同時稼働（旧サーバーと新サーバーを並行運用する）

最も安全性が高いのが、旧サーバーを止めずに、新サーバー側でサイトを先に完成させておき、切替までの間は両方を動かす方法です。
この方式のメリットは、切替前に十分テストでき、問題があればすぐに戻せる（ロールバックしやすい）点です。反対に注意点は、同時稼働中に「どちらで更新が発生するか」を明確にしないと、データがズレることです。例えば、問い合わせフォームの送信先メール、予約・注文・会員登録など、更新が発生する仕組みがあるサイトは、切替直前の扱いを決めておく必要があります。

②DNS切替（A/AAAA/CNAME/MXを切り替えて行き先を変える）

多くのサーバー移行は、最後にDNSのレコードを変更して、アクセスの行き先を旧サーバーから新サーバーへ切り替えます。WebサイトならA/AAAA/CNAME、メールならMXが代表的です。
DNS切替のポイントは反映に時間差があることです。反映中は、見る人・環境によって旧サーバーを見ている人と新サーバーを見ている人が混在します。これが「自分のPCでは見れるのに、他の人は見れない」といった現象の正体です。

ダウンタイムとは？（ゼロにできる／できないの境界）

ダウンタイムは「サイトが見れない時間」だけでなく、実務的には"正しく動いている状態が保証できない時間"も含みます。DNS切替では混在が起きるため、厳密には"切替中は完全なゼロダウンタイムにならない"ケースが多いです。
ただし、サイトが静的（更新がほぼない）で、切替前に新サーバーを完成させておけば、ユーザーの体感としてはほぼダウンタイムなしで移行できることもあります。

ダウンタイムを最小化する基本方針（初心者向けの鉄板）

迷ったら次の方針で進めると安全です。

新サーバーを先に完成させ、事前テストで「動く」状態にする（同時稼働）
切替当日にやるのは「DNSを切り替える」だけにする（作業を集中させない）
切替前後は更新が発生しやすい箇所（フォーム、EC、会員、予約）を重点監視する

この3点を押さえると、作業の抜け漏れが減り、トラブル時も切り分けがしやすくなります。

"同時稼働＋DNS切替"が向いているケース／注意が必要なケース

新旧サーバーを同時稼働しながらDNS切替はほとんどのサイトで有効ですが、次のような場合は注意が必要です。

EC／予約／会員など、切替直前にもデータ更新が頻繁に発生する
メール移行を伴い、切替中の混在でメール不達の影響が大きい（業務メール）
複数ドメイン／サブドメイン／外部サービス連携が多い（設定漏れが起きやすい）

こうしたケースは、切替タイミングや手順の設計（どこから止めるか、併用期間をどう取るか）が重要になります。次章以降のチェックリストで、準備〜テスト〜切替〜確認の流れを具体的に整理していきましょう。

必要な情報・事前に揃えるもの（契約情報／DNS／メール設定等）

サーバー移行でつまずきやすいのは、作業の難しさというよりも、「必要な情報が揃っていない状態で開始してしまう」ことです。
特に、ドメイン（DNS）とメールは、管理画面がサーバーとは別の場所にあることが多く、「どこで設定しているか分からない」「ログインできない」だけで作業が止まります。

ここでは、移行作業に入る前に最低限そろえておきたい情報を整理します。先に集めておけば、準備〜テスト〜切替がスムーズになり、切替当日も慌てません。

まずは必須：契約・管理情報（ログイン関連）

サーバー移行では、最低でも「現行（旧）」「移行先（新）」「ドメイン管理（レジストラ/DNS）」の3箇所にログインできる必要があります。下記を手元にまとめておきましょう。

旧サーバーの管理画面ログイン情報（ID/パスワード、契約IDなど）
新サーバーの管理画面ログイン情報（ID/パスワード、契約IDなど）
ドメイン管理（レジストラ）またはDNS管理サービスのログイン情報
サイトのCMSログイン情報（WordPressの管理画面ID/パスワード等）
FTP/SFTP/SSH接続情報（ホスト名、ユーザー名、パスワード/鍵、ポート）
データベース接続情報（DB名、ユーザー、パスワード、ホスト名）

DNS：今の設定を「現状のまま控える」

DNSは切替の司令塔なので、現行の設定が分からないと、新サーバーへ正しく向けられません。まずはDNS管理画面で、現在のレコードを確認し、控えておきます（スクリーンショットでもOKです）。

A/AAAA/CNAMEレコード（Webの向き先）
MXレコード（メールの向き先）
TXTレコード（SPF/DKIM/DMARCなどメール認証、各種サービス連携）
サブドメインの有無（www、mail、shop、blog など）
TTL値（切替前に調整するか検討するため）

ここで重要なのは、「ドメイン移管（レジストラの変更）」と「DNS切替（向き先変更）」は別ということです。多くのケースではドメイン移管は不要で、DNSの向き先だけを変更します。まずは「DNSをどこで管理しているか」を確定させましょう。

DNSは「切替」と「ネームサーバー変更」「ドメイン移管」が混同されがちです。違いと手順は下記記事でも詳しく紹介しています。

サーバー移転のドメイン設定｜DNS切替・ネームサーバー変更・移管の違いと手順

メール：アカウント情報と運用状況を棚卸し

メール移行を伴う場合、切替後のトラブルが一番大きくなりやすいので、事前に棚卸ししておくと安全です。特に業務メールは影響が出やすいため、抜け漏れなく確認しましょう。

使用中のメールアドレス一覧（部署/担当/用途、転送設定の有無）
メールの方式（IMAP/POP）と利用環境（PC/スマホ/アプリ）
現在の送受信サーバー情報（IMAP/POP/SMTPのホスト名、ポート、暗号化方式）
メールボックス容量、重要メールの保存期間（移行方法の判断材料）
メーリングリスト／共有メールボックス／自動返信など特殊設定の有無

また、メール送信の信頼性に関わるSPF/DKIM/DMARCはTXTレコードで管理されることが多く、DNS設定の控えがそのまま重要になります。切替後に「迷惑メールに入りやすくなった」「送信拒否された」とならないためにも、事前に把握しておきましょう。

Web/CMS：移行作業に必要な素材を揃える

Webサイト側は「ファイルとDBを移して、動作確認する」ための情報が必要です。WordPress等のCMSでは、プラグイン移行か手動移行かで必要情報が少し変わりますが、最低限は下記があるとスムーズです。

サイトの構成情報（ドメイン・サブドメイン・ディレクトリ構造）
現行のPHPバージョン、使用DB（MySQL等）とバージョン目安
フォームの送信先（メールアドレス、外部サービス連携の有無）
外部連携（GA4、Search Console、決済、予約、SNS連携など）
リダイレクトやWAF/CDN、Basic認証などの特殊設定

準備の進め方（迷ったらこの順番）

情報収集は、手当たり次第に集めるより、次の順番にすると抜け漏れが減ります。

ドメインとDNSの管理場所を確定し、現在のDNSレコードを控える
旧サーバー／新サーバーの管理画面にログインできる状態にする
メール移行の有無を決め、メールアドレス一覧と送受信設定を棚卸しする
Web（CMS）の移行に必要な接続情報（FTP/SSH、DB）を揃える
切替当日に影響が大きい箇所（フォーム、EC、予約、会員）を洗い出す

ここまで揃っていれば、次章の「移行前の準備チェックリスト」に進んでも、途中で情報不足で止まりにくくなります。特にDNSとメールは「作業当日に探す」と高確率で詰まるので、先に確保しておくのがおすすめです。

移行前の準備チェックリスト（切替前にやること）

サーバー移行の成否は、切替当日の作業量ではなく「切替前にどこまで準備できているか」でほぼ決まります。
逆に言うと、切替当日にトラブルが起きるケースの多くは、実は準備不足（棚卸し漏れ・バックアップ不足・切替手順の未確定）が原因です。

この章では、移行前にやるべきことをチェックリストとして整理します。次の3つを押さえることで、作業の抜け漏れが減り、万一のときも切り戻し（ロールバック）がしやすくなります。

現状の棚卸し（何が動いているか／どこで管理しているかを把握する）
バックアップ（戻れる状態を作ってから手を動かす）
移行計画（切替手順・担当・時間・リスクを決める）

ここで大事なのは、「できそうだから進める」ではなく、準備が揃ってから切替するという順番です。準備が揃っていれば、切替当日はDNSを切り替えて確認するだけに近づけられます。

移行前に"よく起きる詰まりポイント"

準備段階で次のどれかが曖昧なままだと、途中で作業が止まったり、切替後に不具合が出やすくなります。

DNSの管理場所が分からない（どこでA/MX/TXTを変更するのか不明）
メール設定の棚卸しが不十分（アドレス一覧・転送・特殊設定が抜ける）
フォーム・予約・ECなど「更新が発生する箇所」の扱いが決まっていない
バックアップは取ったが、復元できるか検証していない（戻せないバックアップ）
切替当日の段取り（誰が何をいつやるか）が未確定で、作業が集中する

次に上の3つを具体的に落とし込みます。まずは現状の棚卸しから始めて、移行対象と管理場所を明確にしていきましょう。

現状の棚卸し（ドメイン管理／DNS／メール／SSL／CMS）

移行前の棚卸しは、サーバー移行を「作業」ではなく"設計"に変える工程です。
ここが曖昧なまま進めると、切替当日に「DNSがどこで変更できるか分からない」「メール設定が抜けた」「SSLが外れた」など、典型的なトラブルが起きやすくなります。

棚卸しの目的はシンプルで、①何が動いているか、②どこで管理しているか、③切替で影響が出るのはどこかを、切替前に見える化することです。

棚卸しの進め方（迷ったらこの順番）

ドメインの管理場所（レジストラ）を確定する
DNSの管理場所（どこでレコードを編集するか）を確定し、現行レコードを控える
メールの運用（アドレス一覧・転送・特殊設定）を洗い出す
SSL（https）の提供元と設定方法を確認する
CMS/サイト構成（WordPress等）と外部連携を洗い出す

1）ドメイン管理（レジストラ）で確認すること

ドメインの管理場所は「更新期限」「移管ロック」「Whois情報」などの管理主体です。サーバー会社＝ドメイン会社とは限らないので、まずはここを確定させます。

対象ドメイン一覧（メインドメイン、別ドメイン、サブドメインの有無）
ドメインの契約先（レジストラ名）とログイン情報
更新期限（移行直前に期限切れリスクがないか）
ネームサーバー設定（DNSをどこで管理しているかの手がかり）

ここでのポイントは、「ドメインを移す（移管）」の話ではなく、「どこでDNSを触るか」を確定することです。多くの移行は、ドメインはそのままでDNSの向き先だけを変更します。

2）DNS（レコード）で確認すること

DNSは切替の司令塔です。現状を控えずに進めると、切替後に「サブドメインだけ死んだ」「メール認証が消えて迷惑メール化した」といった事故が起きます。
まずは現在のレコードを"そのまま控える"ことが最優先です（スクショでもOK）。

A/AAAA/CNAME（Webの行き先：@、www、各サブドメイン）
MX（メールの行き先）
TXT（SPF/DKIM/DMARC、各種サービス連携用のTXT）
サブドメインの棚卸し（shop、blog、mail、lp、admin など）
TTL値（切替前に調整するかの判断材料）

この段階で「何のレコードか分からないもの」があってもOKです。重要なのは、存在を把握して消さないこと。後で用途を確認しながら整理すれば安全に移行できます。

3）メールで確認すること（業務影響が大きいので丁寧に）

メール移行で困るのは「アカウントが抜ける」「転送が消える」「送信だけ失敗する」など、"設定の抜け漏れ"です。先に運用実態を棚卸ししておきます。

使用中のメールアドレス一覧（個人/部署/用途、不要アドレスも含め現状把握）
転送設定（転送先、条件、二重転送の有無）
共有メールボックス／グループ／メーリングリストの有無
利用方式（IMAP/POP）と利用端末（PC/スマホ/アプリ）
送受信サーバー情報（IMAP/POP/SMTPのホスト名、ポート、暗号化方式）

業務メールの場合は、切替当日に「止められない時間帯」があるはずです。棚卸しと同時に、切替できる日時の制約もメモしておくと、移行計画が立てやすくなります。

4）SSL（https）で確認すること

SSLは移行後に目に見えて不具合が出やすいポイントです。提供元がどこかで対応が変わるため、"どこがSSLを担当しているか"を確定します。

SSLの提供元（サーバーの無料SSL／有料証明書／CDN/WAF側のSSL終端）
対象範囲（メインドメインのみ／www／サブドメインも含む）
リダイレクト方針（http→https、www有無の統一）
証明書の期限・更新方法（自動更新か手動か）

SSLの棚卸しができていると、切替後の「保護されていない通信」警告や混在コンテンツの切り分けが早くなります。

5）CMS/サイト構成（WordPress等）で確認すること

サイト移行は、見た目が表示されるだけでは不十分で、フォーム・管理画面・外部連携など「動く部分」まで含めて移行対象です。ここを先に洗い出すと、切替後の取りこぼしが減ります。

サイト構成（どのドメイン/サブドメインが何に使われているか）
CMSの種類（WordPress等）と管理画面ログイン情報
データ構成（ファイル＋DBの有無、容量の目安）
フォームの送信先・設定（メール/外部サービス/スパム対策）
外部連携（GA4、Search Console、決済、予約、SNS、地図、APIなど）
特殊設定（Basic認証、IP制限、cron、リダイレクト、WAF/CDN）

棚卸しの"ゴール"

最低限、次の3点が言える状態になればOKです。

DNSをどこで変更できるか分かっている
移行対象（Web/メール/SSL/外部連携）の抜け漏れがない
切替当日に影響が出る箇所（フォーム、メール、EC等）を把握している

この棚卸しができたら、次はバックアップに進みます。「戻れる状態」を作ってから移行作業に入るのが安全な進め方です。

バックアップ（Webデータ／DB／メール）

サーバー移行で一番大切なのは、作業スキルよりも「いつでも元に戻せる状態（保険）」を先に作ることです。
バックアップが不十分なまま切替すると、移行後に不具合が出たときに切り戻しができず、復旧までの停止時間が長くなります。

ここでは、移行前に最低限押さえるべきバックアップをWeb（ファイル）／DB（データベース）／メールの3つに分けて整理します。ポイントは、「取る」だけでなく「戻せる」前提で用意することです。

バックアップの基本ルール（これだけは守る）

複数箇所に保管する（PCだけ／サーバーだけの一箇所保管は避ける）
バックアップ日時を明記する（例：2026-02-20_before-migration）
切替直前にももう一度取る（更新があるサイトは特に重要）
可能なら復元テストを一度行う（「戻せるバックアップ」か確認）

1）Webデータ（ファイル）のバックアップ

Webサイトのバックアップは、まず公開ファイル一式を確保します。WordPressの場合はテーマやプラグイン、アップロード画像などがここに含まれます。静的サイトでも画像やCSS/JSが欠けると表示が崩れるため、必ず一式で取ります。

サイトの公開ファイル一式（ドキュメントルート配下）
WordPressの場合：wp-content（themes / plugins / uploads）
独自に設置したファイル（.htaccess、設定ファイル、独自スクリプト等）
サブドメイン／別サイトがある場合は、それぞれの公開領域

注意点として、サーバー会社の「自動バックアップ」は便利ですが、復元範囲や復元方法（申請が必要／日次のみ等）がサービスごとに異なります。移行作業用の保険としては、可能なら自分でも取得しておくと安心です。

2）DB（データベース）のバックアップ

WordPressなどのCMS、予約・問い合わせ履歴、会員情報などはDBに入っています。ファイルだけ移しても、DBが欠けると記事・設定・フォーム内容が消えてしまうため、DBは必ず別でバックアップします。

対象DBのエクスポート（SQL形式が一般的）
DB名・ユーザー名・ホスト名など接続情報の控え
複数サイト/複数DBがある場合は、対象を取り違えないよう一覧化

更新が多いサイト（EC/予約/会員）では、移行準備から切替までの間にもDBが更新されます。ダウンタイムを短くしたい場合でも、最低限切替直前に「最終DBバックアップ」を取り、切替後の差分が戻せる状態にしておきましょう。

3）メールのバックアップ

メールは「設定の移行」と「メール本文データの移行（保管）」が別です。特にIMAP運用の場合はサーバー側にメールが残るため、切替前に誤って削除・上書きしないよう、バックアップ方針を決めておきます。

重要メールの保管方針（サーバー上に残す／ローカルに書き出す／両方）
メールクライアント利用の場合：ローカルデータのバックアップ（端末側）
各メールアドレスの容量・フォルダ構成（移行方法選定の材料）
転送・自動返信・フィルタなどの設定内容の控え（後で再現できるように）

メールは「消えた」よりも、「切替中に届いたメールがどちらに入ったか分からない」が問題になりやすいです。移行当日は、旧・新のどちらで受信する時間帯なのかを明確にし、必要なら併用期間を設けて混乱を防ぎましょう。

バックアップの実行手順（迷ったらこの順番）

Webファイル一式をバックアップし、保管先を2箇所以上に分ける
DBをエクスポートし、ファイル名に日時とサイト名を付けて保管する
メールの保管方針を決め、重要データをローカル/別保管に退避する
切替直前に「最終バックアップ」（Web/DB/必要ならメール）を追加で取る
可能なら復元テスト（最低でもDBが開ける／ファイルが展開できる確認）を行う

バックアップが揃ったら、次は移行計画（切替日時・TTL・影響範囲・ロールバック）を固めます。
「戻せる状態」＋「切替の段取り」が揃うと、移行作業は一気に安全に進められます。

移行計画（切替日時・TTL・影響範囲・ロールバック）

バックアップまで終わったら、次にやるべきは「切替の段取りを決め切ること」です。
サーバー移行は、作業そのものよりも「いつ・何を・誰が・どの順番で切り替えるか」が曖昧なままだと、当日に作業が集中してミスが起きやすくなります。

この章では、切替前に確定させておきたい移行計画を、実務で必要な4要素（切替日時／TTL／影響範囲／ロールバック）に分けて整理します。ここまで決めておけば、切替当日は「DNSを切り替える→確認する」に近い状態で進められます。

1）切替日時（いつ切り替えるか）

切替日時は「空いている時間」ではなく、影響が最小になる時間で決めます。特にメールを伴う場合や、更新が発生するサイト（EC/予約/会員）は慎重に設定しましょう。

アクセスや受注が少ない時間帯（深夜〜早朝、週末など）
業務メールが止まると困る時間帯を避ける（平日昼など）
更新が発生する作業（商品更新、記事更新、フォーム改修等）を切替前後で止められるか
関係者（担当者・制作会社・サーバー会社）に連絡が取れる時間か
切替後の監視時間を確保できるか（最低でも数時間は確認できる余裕）

切替は「作業が終わる時間」ではなく、切替後に問題が起きても対応できる時間に置くのが安全です。

2）TTL（DNS反映の時間差）をどう扱うか

DNS切替のややこしさは、切替直後に全員が同時に新サーバーを見るわけではなく、旧・新が混在する時間が発生することです。TTLは、その混在期間を短くするためのレバーになります。

TTLが長いほど、切替後もしばらく旧サーバーを見る人が増える
TTLを短くすると、切替の反映が早くなる（混在期間を短縮しやすい）
TTLを変更するなら、切替の十分前に短くしておく（変更自体にも反映時間がある）
短くし過ぎるとDNS問い合わせが増えるため、無理のない範囲で設定する

「どのTTLが正解か」は環境次第ですが、重要なのはTTLをどうするかを事前に決めておくことです。切替当日にTTLの存在を思い出すと、混乱しやすくなります。

3）影響範囲（何が止まる・何がズレる可能性があるか）

影響範囲は「サイトが見れるか」だけではありません。実務では、更新が発生する機能と外部連携が影響を受けやすいです。切替前に「何を重点チェックするか」を決めておくと、確認漏れが減ります。

フォーム（問い合わせ・資料請求・採用など）：送信先、スパム対策、外部連携
EC/予約/会員：注文・予約・決済、メール通知、会員ログイン、在庫/予約枠
メール：受信・送信・転送・自動返信、迷惑メール判定（SPF/DKIM/DMARC）
サブドメイン：shop/blog/mail など、メイン以外の向き先の切替漏れ
SSL：証明書の適用、http→https、www有無の統一、混在コンテンツ
外部サービス：GA4、Search Console、CDN/WAF、API連携、決済・予約SaaS

影響範囲の洗い出しができたら、切替後の確認は「とりあえず見た目OK」ではなく、"重要機能から順に確認する"に変わります。

4）ロールバック（切り戻し）を事前に決める

ロールバックは「失敗したら戻す」ではなく、"どの状態になったら戻すか"を事前に決めておくのがポイントです。基準がないと、切替後に焦って中途半端な対処を続け、復旧が遅れます。

ロールバックの判断基準（例：主要ページが表示できない／メール送受信が不可／決済が動かない等）
戻す手順（DNSを旧に戻す／旧サーバーを再開する／メールの行き先を戻す等）
戻した後に確認する項目（旧サーバーで正常に戻ったか、影響が残っていないか）
誰が判断し、誰が実行するか（意思決定者・作業者）
"戻すための前提"が揃っているか（バックアップ、旧サーバー停止しない期間など）

ロールバックが決まっていると、切替当日に問題が起きても「次に何をするか」が明確になり、結果的に停止時間を短くできます。

移行計画のまとめ（切替前に決めるべきこと）

切替日時（影響が少なく、切替後に対応できる時間）
TTL方針（短縮するか／いつ変更するか／混在をどう扱うか）
影響範囲（更新機能・外部連携・メール・サブドメイン・SSL）
ロールバック基準と手順（戻す判断の線引き、DNS戻しの手順、担当者）

ここまで固められたら、移行前準備はかなり盤石です。次章では、新サーバー側の準備と事前テストへ進み、切替当日にやることを最小化していきます。

新サーバー側の準備と事前テスト（切替前に"動く"状態を作る）

移行前の準備（棚卸し・バックアップ・計画）ができたら、次は新サーバー側で「切替前に"動く"状態」を作ります。
ここを丁寧にやっておくと、切替当日にやることがDNSを切り替える→確認するだけに近づき、トラブルとダウンタイムを大幅に減らせます。

逆に、切替当日に新サーバーで初めて動作確認をする進め方は、時間も精神的負荷も一気に上がります。切替前に"ほぼ完成"まで持っていくのが安全な進め方です。

この章でやること（全体像）

新サーバー側の準備は、次の3つのステップに分けると迷いません。

新サーバーの環境を整える（PHP/DB/SSLなど、動作に必要な前提を揃える）
サイトを移して"事前テスト"する（切替前に表示・機能を確認する）
メール移行がある場合は、切替前にやれる準備を済ませる（方式選定・アカウント用意など）

事前テストで確認すべき観点

「トップページが表示できた」だけでは不十分です。移行後に問題になりやすいのは、フォームや管理画面、外部連携など"動く部分"です。事前テストは次の観点で行います。

表示（主要ページ、CSS/画像、文字化け、崩れ）
機能（フォーム送信、検索、ログイン、決済/予約、管理画面操作）
環境差（PHP/DBバージョン差、拡張モジュール、パーミッション）
SSL/URL（https、www有無、リダイレクト、混在コンテンツ）
外部連携（GA4、Search Console、決済/予約SaaS、API連携、メール送信）

ここでの注意：切替前のテストは"本番URLでない"前提

DNSを切り替える前は、原則として本番URL（ドメイン）ではなく、新サーバーの仮URLやhosts等を使ってテストします。
そのため、外部サービス連携やSSLなど、本番ドメインでないと完全には再現できない項目もあります。ここは「切替前にできること／切替後に確認すること」を分けておくと、当日の確認漏れが減ります。

次の小見出し（#s3-1〜）で具体的に進めます
ここから先は、①環境準備、②事前確認（hosts等）、③メール移行の事前準備の順で、切替前に"動く状態"を作っていきます。
切替当日の作業を最小にするためにも、次章以降のチェックリストに沿って、一つずつ確実に進めましょう。

環境準備（PHP/DB/SSLなどの設定確認）

新サーバー側の準備で最初にやるべきことは、サイトデータを移す前に「動作前提となる環境」を揃えることです。
ここを飛ばしてデータだけ移すと、「表示はされるが管理画面でエラー」「フォームだけ送れない」「画像が出ない」など、切り分けが難しい不具合が出やすくなります。

環境準備のポイントは、旧サーバーの状態を"把握"し、新サーバーで"再現"することです。完全一致が難しくても、差分を認識しておけば、後から原因を特定しやすくなります。

まず確認する：旧サーバーの現状（基準点）

新サーバー側で合わせるために、旧サーバーの条件を控えておきます。管理画面で確認できるものはスクリーンショットでもOKです。

PHPのバージョン（例：7.4 / 8.0 / 8.1 など）
DBの種類とバージョン目安（MySQL / MariaDB 等）
文字コード（通常はUTF-8）と照合順序（DBのcollation）
Webサーバーの種類（Apache/Nginx）や動作モード（把握できる範囲で）
PHP設定（memory_limit、upload_max_filesize、post_max_size、max_execution_time など）

特にWordPressは、PHPバージョン差でプラグインやテーマが動かなくなることがあります。移行を機にPHPを上げる場合は、"移行＋アップデート"を同時にやらないほうが安全です（原因切り分けが難しくなるため）。

新サーバー側で整える：PHP設定

次に、新サーバーの管理画面でPHPバージョンと基本設定を揃えます。少なくとも「旧サーバーと同等以上」で動く状態を目指します。

PHPバージョンを設定（まずは旧と同等、検証後に上げるのが安全）
必要なPHP拡張（mbstring、curl、openssl、gd、zip など）
メモリ上限・アップロード上限（大きい画像/バックアップを扱う場合に重要）
タイムゾーンやメール送信設定（環境依存の不具合を減らす）

「バックアップファイルがアップロードできない」「復元に時間がかかってタイムアウトする」などは、上限値の設定不足で起きがちです。事前に上限を見直すと作業がスムーズになります。

DB（データベース）準備：作成・権限・接続情報

DBを使うサイト（WordPress等）は、データを流し込む前に新サーバー側でDBを用意します。ここでのミスは、移行後の「DB接続エラー」に直結します。

DBを新規作成（DB名）
DBユーザー作成と権限付与（ユーザー名・パスワード）
接続ホスト名の確認（localhost なのか専用ホスト名なのか）
文字コード/照合順序を確認（可能なら旧と揃える）

WordPressの場合は、wp-config.phpにあるDB名・ユーザー名・パスワード・ホスト名を新サーバー用に合わせる必要があります。切替前のテスト環境でも、DB接続は早めに通すのがコツです。

ファイル配置の前提：ドキュメントルートと権限

サーバー会社によって、公開ディレクトリ（ドキュメントルート）や初期のパーミッションが異なります。ここがズレると「表示できない」「画像だけ出ない」といった不具合が起きます。

ドキュメントルートの場所（public_html など）
サブドメインの公開場所（自動生成される/手動で作るなど）
ファイル権限（パーミッション）と所有者（サーバー仕様に合わせる）
.htaccessが有効か（Apache系の場合）

SSL（https）の準備：切替前にできること／切替後にやること

SSLは本来「本番ドメイン」で証明書を発行・適用する必要があるため、DNS切替前だと完全に適用できないことがあります。とはいえ、切替前にできる準備はあります。

新サーバーで無料SSLを使えるか（Let's Encrypt等）
証明書の適用対象（@／www／サブドメイン）を整理する
CDN/WAF側でSSL終端している場合は、切替手順を確認する
http→https、www有無の統一方針（リダイレクト方針）を決める

SSLの適用は切替直後に最優先で確認します。事前に方針が固まっていれば、切替後の対応が速くなります。

環境準備ができたかのチェック（次へ進む条件）

次の事前テスト（hosts等）に進む前に、最低限この状態を作っておくと安全です。

PHPバージョンと主要設定が決まっている
DBが作成済みで、ユーザー権限と接続情報が揃っている
公開ディレクトリ（ドキュメントルート）が確定している
SSLの適用方針（切替後に何をするか）が決まっている

ここまで整ったら、次はサイトデータを配置し、hosts等を使って切替前に動作確認を行います。環境を先に揃えておくことで、テストで出た不具合の原因を特定しやすくなります。

hosts等で事前確認（表示・フォーム・管理画面）

新サーバーの環境準備ができたら、次はDNSを切り替える前に「新サーバーでちゃんと動くか」を確認します。
ここを飛ばすと、切替当日に初めて不具合が見つかり、原因切り分けに時間がかかってダウンタイムが長くなりがちです。

事前確認の代表的な方法が「hosts（ホスト）ファイルで自分のPCだけ行き先を新サーバーに向ける」やり方です。これなら、外部の人には影響を出さずに、本番ドメインのまま（見た目のURLはそのまま）動作確認ができます。
ただし、SSL（https）は証明書の状況によって警告が出ることがあるため、切替前はhttpで確認したり、仮ドメイン・プレビューURLを併用して確認するのが現実的です。

事前確認の方法（よくある3パターン）

hostsで確認：自分のPCだけ新サーバーへ（本番ドメインの動作確認に強い）
仮URL/プレビューURLで確認：サーバー会社が用意するテスト用URLで確認（手軽）
検証用サブドメインで確認：stg.example.com等で新サーバーを公開して確認（外部連携のテストがしやすい）

どれを選んでも目的は同じで、「切替前に主要機能が動く状態」を作ることです。できればhosts等で本番ドメイン相当の確認をしつつ、SSLや外部連携は検証用サブドメインで補完、のように組み合わせると抜け漏れが減ります。

事前確認の進め方（迷ったらこの順番）

新サーバーにサイトデータ（ファイル/DB）を反映し、最低限表示できる状態にする
hosts・仮URL・検証用サブドメインのいずれかで、新サーバーを表示できる状態にする
表示確認（主要ページ・デザイン崩れ・画像/CSS/JS）を行う
動作確認（フォーム・ログイン・管理画面・検索・アップロード等）を行う
外部連携（メール送信・計測・API連携など）を"できる範囲で"確認する
問題があれば「環境差（PHP/DB/権限）」→「設定（URL/SSL/リダイレクト）」の順で切り分ける

チェックリスト：最低限ここは見ておく（表示）

トップページ／主要下層ページが表示される
画像・CSS・JSが読み込まれている（表示崩れがない）
404ページやリンク切れが多発していない
日本語が文字化けしていない
スマホ表示（レスポンシブ）が大きく崩れていない

チェックリスト：最低限ここは見ておく（フォーム/機能）

問い合わせフォームが送信でき、テスト用メールアドレスに届く
フォーム送信後の完了画面・サンクスページが正しく表示される
自動返信メールがある場合は文面が崩れていない
検索機能、会員ログイン、予約/決済など主要機能が動く（該当する場合）
画像アップロード等、管理側の操作でエラーが出ない

フォーム確認は特に重要です。切替後に「サイトは見れるが問い合わせが届かない」は致命的になりやすいため、必ずテスト送信→受信確認まで行いましょう。

チェックリスト：最低限ここは見ておく（管理画面）

WordPress等の管理画面にログインできる
記事の新規作成・更新ができる（テスト用に下書きでOK）
プラグイン/テーマの画面で致命的エラーが出ない
メディア（画像）アップロードができる
パーマリンク設定やキャッシュ系設定が原因で表示が崩れていない

よくある注意点（切替前テストで混乱しやすいところ）

hostsは自分のPCだけに効くため、他の端末では確認できない（確認端末を揃える）
httpsが警告になる場合がある（切替前はhttpで確認、切替後にSSLを最優先確認）
reCAPTCHA等、ドメイン制限のある外部連携は検証環境で動かないことがある
キャッシュ（ブラウザ/プラグイン/CDN）で旧表示が残ることがある（キャッシュ削除で切り分け）
検証用URLを公開する場合は、検索エンジンにインデックスされない対策（Basic認証等）を入れる

事前確認で「表示」「フォーム」「管理画面」が問題なく動く状態になったら、新サーバー側はかなり完成に近づいています。
WordPressは「ドメインそのまま」で移す際の注意点（URL/DB/SSL/リダイレクト等）が多いので、手順をまとめて確認したい方は下記記事も参考にしてください。

WordPressサーバー移行｜ドメインそのまま（URLを変えずに）移す手順と注意点

次は、メール移行がある場合の事前準備（方式選定・アカウント準備・併用方針）を進め、切替当日に慌てない状態を作っていきましょう。

メール移行の事前準備（IMAP/POP・移行方法の選択）

メール移行はサーバー移行の中でも、特に業務影響が大きい工程です。サイトは一時的に見られなくてもリカバリーできますが、メールが止まると「問い合わせが届かない」「取引先と連絡が取れない」など、直接の損失につながりやすくなります。

そのため、切替当日にいきなり作業するのではなく、切替前にIMAP/POPの運用状況と移行方法を決め、必要な準備を済ませておくのが安全です。

まず整理：IMAPとPOPで「移行の考え方」が変わる

IMAP/POPは、どこにメールが保存されるかが違います。これを理解すると、移行方法の選択がブレません。

IMAP：メールは基本的にサーバー側に保存され、端末は"閲覧する"イメージ（複数端末運用に向く）
POP：メールは端末側にダウンロードして保存する運用が多い（端末にしか残っていないメールがあり得る）
同じ会社でも、担当者ごとにIMAP/POPが混在していることがある（棚卸しが重要）

IMAP運用の場合は「サーバーを替える＝保存場所が変わる」ので、過去メールを新サーバーへ移すのか／旧サーバーに残すのかを決める必要があります。POP運用の場合は、端末にしかないメールがある可能性があるため、端末側のバックアップが重要になります。

移行方法の選択（代表的な3パターン）

メール移行にはいくつか方法があります。サイトの重要度・メール量・停止許容時間に合わせて選びます。

設定だけ移行（過去メールは移さない）：新サーバーで同じアドレスを作り、以後は新サーバーで受信
過去メールも移行（IMAP同期などで引っ越し）：旧→新へメールボックスを移す
併用期間を設ける（混在リスクを下げる）：一定期間は旧も参照できるようにして段階的に移行

スピード重視なら「設定だけ移行」ですが、業務上過去メール参照が必須なら「過去メールも移行」を検討します。メール量が多い場合は移行に時間がかかるため、併用期間を設けるとトラブルと混乱を減らせます。

切替前にやっておく準備（ここが本番）

切替前にできる準備を済ませておくと、切替当日はMX切替と確認に集中できます。

メールアドレス一覧を確定（漏れ防止：部署/用途/転送/共有含む）
現行メールの接続情報を控える（IMAP/POP/SMTPホスト、ポート、暗号化方式）
新サーバー側でメールアカウントを事前作成（同じアドレス・同じパスワード方針など）
転送・自動返信・フィルタ等の特殊設定を再現できるよう控える
SPF/DKIM/DMARCなどDNS（TXT）設定の現状を控える（送信信頼性の要）
切替後の各端末設定変更が必要かを確認（スマホ/PC/アプリの影響）

送信トラブルを防ぐ：DNS（TXT）と送信認証の扱い

メール移行で"受信"は気づきやすい一方、問題になりやすいのが"送信"です。切替後に「送れるが届かない」「迷惑メールに入る」「送信拒否される」などが起きることがあります。
これは多くの場合、SPF/DKIM/DMARCなど送信ドメイン認証（TXT/DKIM）が旧サーバー前提のまま、もしくは切替で消えてしまったことが原因になります。

切替前にやるべきことは難しくなく、現行のTXTレコードを控える→新サーバー側で必要なTXT/DKIMを用意することです。どのTXTが必要かはサービスごとに違うため、まずは「消さない」「控える」を徹底しましょう。

切替当日の混乱を減らす：併用と周知
メールはDNS切替（MX）により、切替中に旧・新へ分散する可能性があります。業務影響を減らすため、事前に方針を決めておくのが安全です。

切替当日の連絡ルール（誰が受信確認するか、緊急連絡手段）
併用期間を設けるか（一定期間は旧メールも参照できる状態にする）
切替後の端末設定変更が必要な人（スマホ設定変更が必要な担当者など）
重要メールのテスト送受信計画（社内/外部宛にテストする）

次に進む前のチェック（メール移行の事前準備のゴール）

最低限、次が揃っていれば切替当日のメール移行はかなり安全になります。

IMAP/POPの運用が把握できている
移行方法（設定だけ／過去メールも移行／併用）を決めている
新サーバー側のメールアカウントが準備できている（必要分）
DNSのメール関連レコード（MX/TXT等）の現状を控えている

ここまでできたら、切替当日は「MXを切り替える→送受信テスト→問題があれば切り分け」に集中できます。
メール移行はトラブルが出やすいので、送受信できない原因と設定手順（IMAP/SMTP）を先に押さえておくと安心です。下記記事も参考にしてください。

サーバー移転のメール移行｜送受信できない原因と設定手順（IMAP/SMTP）

次章では、いよいよ切替当日の手順（DNS切替）と、反映時間・混在への対処を整理していきます。

切替当日の手順（DNS切替のやり方と注意点）

切替当日は、基本的には「DNSの向き先を旧→新に切り替える」日です。
ここまでに新サーバー側で"動く状態"を作れていれば、当日の作業はシンプルになり、トラブルやダウンタイムも最小化できます。

ただしDNS切替には、反映時間（旧・新の混在）がつきものです。切替直後に「全員が一斉に新サーバーを見る」わけではないため、焦って設定を何度も触ると状況が悪化しやすくなります。
切替当日は、やることを絞り、"変更→待つ→確認→切り分け"の順で冷静に進めるのがコツです。

切替当日の全体の流れ（ざっくり）

実際の操作画面はサービスごとに違いますが、流れは共通して次のイメージです。

切替前の最終確認（新サーバーで"動く"状態／バックアップ／ロールバック手順）
DNSを切替（Web：A/AAAA/CNAME、メール：MX など）
反映待ち（混在を前提に、確認を段階的に行う）
切替直後の優先チェック（Web表示・フォーム・管理画面・メール送受信・SSL）
問題があれば切り分け（DNS反映か／新サーバー不具合か／設定漏れか）

切替当日にやりがちな失敗（先に知っておくと防げます）

反映待ちの途中で、焦ってDNS設定を何度も変える（混乱が増える）
「自分のPCで見れた/見れない」だけで判断してしまう（キャッシュ・混在の影響）
Webだけ見て安心し、フォームやメールを確認しない（機会損失につながりやすい）
SSL（https）やwww有無の統一を後回しにして警告・表示崩れが起きる
ロールバック基準がなく、ズルズル調査して停止時間が伸びる

切替当日の"準備物"チェックリスト（作業前に手元に置く）

当日の判断が速くなるよう、最低限これだけはすぐ見られる状態にしておきましょう。

DNSの現行値（切替前のA/AAAA/CNAME/MX/TXTの控え）
新サーバーの接続情報（管理画面、FTP/SSH、DB情報）
確認するURL一覧（トップ、主要下層、フォーム、管理画面、決済/予約など）
メールのテスト手順（送信元/送信先、確認すべきアドレス）
ロールバック手順（どのレコードをどう戻すか、判断基準、担当者）

次の小見出し（#s4-1〜）では、切替当日に触ることが多いDNSレコード（Web：A/AAAA/CNAME、メール：MX）と、反映時間・混在の考え方、切替直後の優先チェックを、より具体的に整理していきます。

DNS切替（A/AAAA/CNAME）と反映時間の目安

Webサイトの切替は、DNSのレコード（主にA/AAAA/CNAME）を変更して、アクセスの行き先を旧サーバーから新サーバーへ向ける作業です。
「DNSを切り替えたのに表示が変わらない」「人によって見える内容が違う」といった混乱は、ほとんどがDNS反映の時間差（旧・新の混在）が原因です。

この章では、A/AAAA/CNAMEの役割と、反映時間の目安、切替当日に混乱しないための確認手順を整理します。

A / AAAA / CNAMEとは？（まず役割をざっくり把握）

DNSレコードは種類によって役割が違います。Web切替でよく使うのは次の3つです。

Aレコード：ドメインをIPv4アドレス（例：xxx.xxx.xxx.xxx）に向ける
AAAAレコード：ドメインをIPv6アドレスに向ける
CNAMEレコード：ドメインを別のホスト名に向ける（例：wwwを@へ、CDNのホスト名へ等）

つまり切替当日は、「いま旧サーバーに向いている先を、新サーバーに向け直す」作業になります。
どのレコードを変更すべきかは、#s2-1で控えた現行DNS設定（@、www、サブドメイン等）を見れば判断できます。

どれを切り替える？（よくある切替対象）

実務では「@だけ」「wwwだけ」ではなく、サイト構成によって切替対象が増えます。切替漏れが起きやすいので、対象を先に並べてから作業します。

メインドメイン（@ / example.com）
www（www.example.com）
サブドメイン（shop / blog / lp / admin など、運用しているもの）
CDN/WAFを使っている場合：その向き先（CNAME先）が変わるか

特に「wwwはCNAME」「@はA」のように、レコード種別が異なることがあります。"表示されている先（A/AAAA/CNAME）をそのまま新に差し替える"のが基本です。

DNS反映時間の目安（混在が起きる理由）

DNSは世界中のDNSサーバーや端末側のキャッシュによって結果が保持されるため、切替直後は旧サーバーを見る人と新サーバーを見る人が混在します。これが反映待ちの正体です。

TTLが長いほど混在が長引きやすい（切替後もしばらく旧を参照する人が出る）
TTLを短くしていても、端末や回線側のキャッシュで差が出ることがある
「自分のPCで見れた/見れない」だけでは判断できない（環境差が出る）

そのため、切替直後に表示が変わらなくても「失敗だ」と判断せず、混在を前提に確認を進めるのが重要です。

切替当日の確認手順（焦らないための流れ）

DNS設定を変更したら、まず変更内容を記録（何をどの値に変えたか）
数分〜一定時間は反映待ちし、むやみに再変更しない
複数の環境で確認（自分のPC＋スマホ回線など）して混在を把握する
新サーバーが表示され始めたら、優先チェック（主要ページ・フォーム・管理画面）を行う
切替後も旧サーバーが残る前提で、切替完了の判断は"段階的"に行う

切替完了の判断基準（いつ「OK」と言える？）

切替が完了したかは、見た目だけでなく、「新サーバーに到達している」ことを確認して判断します。
例えば、事前に新サーバー側で分かりやすい差（テスト用の目印）を用意しておくと、切替確認が速くなります。

新サーバー側でのみ表示される目印（例：テスト文言や一時的なバナー）を用意しておく
管理画面のサーバー情報や、サーバー会社のアクセスログ等で到達先を確認する
複数回線（自宅Wi-Fi/スマホ回線）で表示先が揃ってくるかを見る

※目印は切替後に必ず戻す（削除する）前提で運用しましょう。

よくある落とし穴（DNS切替の注意点）

サブドメインの切替漏れ（メインは新でも、shop/blogは旧のまま）
wwwの統一が崩れる（wwwあり/なしのリダイレクト不備で評価分散や表示不具合）
CDN/WAF利用時にCNAME先を誤る（直サーバーIPへ向けてしまう等）
切替直後にキャッシュの影響で旧表示が残り、誤って「戻す」判断をしてしまう

サーバー移転のドメイン設定｜DNS切替・ネームサーバー変更・移管の違いと手順

Web（A/AAAA/CNAME）の切替が進んだら、次はメール切替（MX）です。メールは混在の影響が"見えにくく"業務影響も大きいので、次の章で切替手順と「届かない」を防ぐ考え方を整理します。

メールの切替（MX）と「届かない」を防ぐ手順

メール切替は、DNSのMXレコードを変更して「どのサーバーで受信するか」を新サーバーへ切り替える作業です。
Webと違って、メールは「見た目」で切替状況が分かりにくく、切替中に届かなかったり、どこに入ったか分からなくなりやすいのが難点です。

ここでは、MX切替の基本と、切替当日に起こりがちな「メールが届かない」を防ぐための段取りを、実務目線で整理します。

MX切替で起きる"混在"を先に理解する

MX切替もWebのDNS切替と同じく、反映までの間は旧・新が混在します。さらにメールには次の特性があり、混乱しやすくなります。

送信元サーバーは、DNSキャッシュの都合で旧MXへ送信し続けることがある
受信は「届いた時点のMX」に従うため、切替中は旧/新の両方に分散し得る
送信はSMTP設定や認証（SPF/DKIM/DMARC）の影響も受けるため、受信よりトラブルが長引くことがある

だからこそ、MX切替当日は"届かない可能性がある前提"で、受信確認の体制と手順を作っておくのが重要です。

切替当日の前提：新サーバー側の受信準備を100%にする

MXを切り替える前に、新サーバー側で受信できる状態を作れていることが絶対条件です。具体的には次が揃っている状態です。

必要なメールアカウント（info@など）が新サーバー側に作成済み
パスワード方針が決まっている（旧と同じ/変更する、担当者への周知）
転送・自動返信・共有設定など特殊設定が再現できる状態
メール送受信（IMAP/SMTP）の設定値（ホスト/ポート/暗号化）が確認できる

この準備が不完全なままMXだけ切替すると、受信先が新サーバーに切り替わった瞬間にメールが受け取れず、業務影響が大きくなります。

MX切替の手順（基本の流れ）

切替直前の最終確認（新サーバー側のアカウント作成・設定値・監視体制）
DNS管理画面でMXレコードを新サーバーの指定値に変更する
反映待ち（混在を前提に、旧/新どちらで受信しているかを確認する）
テスト受信（外部→自社、社内→自社など複数ルートで試す）
テスト送信（自社→外部、外部→自社の返信などで確認する）
一定時間の監視（重要アドレスの受信箱・転送先・迷惑メールも確認）

「届かない」を防ぐコツ：切替直後の"受信確認"を仕組み化する

受信不達は、発生しても気づくのが遅れがちです。切替当日は次の方法で、届いているかを見える化します。

重要アドレス（info@等）は、切替当日は複数人で監視する
受信箱だけでなく迷惑メールも確認する（判定が変わることがある）
転送設定がある場合は、転送先でも受信確認する（転送が抜けると気づきにくい）
テストメールは「外部サービス（Gmail等）→自社」「自社→外部」「外部→自社へ返信」の3パターンで行う

「届かない」原因の切り分け（まず見るべき順番）

もしメールが届かない場合、闇雲に設定を変えるのではなく、次の順で切り分けると早いです。

MXが新しい値になっているか（DNS設定の見直し・入力ミス確認）
新サーバー側に該当アカウントが存在するか（作成漏れ、容量上限、受信拒否等）
受信ルール/転送/迷惑メール判定で別フォルダに入っていないか
反映待ちの混在ではないか（しばらく旧へ届いている可能性）
送信側（相手側）の問題や遅延ではないか（しばらく待って届くケースもある）

切替中は、旧サーバーにも届いている可能性があります。トラブル時は「届いていない」と断定する前に、旧サーバー側の受信箱も確認し、分散していないかを見ましょう。

送信で詰まりやすいポイント（受信より注意）

受信ができても、送信で「拒否される」「迷惑メールになる」などが起きることがあります。切替時に見落としやすいのは、DNSのTXTレコード（SPF/DKIM/DMARC）や、SMTPサーバーの設定です。

SPF（TXT）を旧サーバー前提のままにしている（送信元が変わって不整合）
DKIM（TXT）設定が新サーバー側で必要なのに未設定
SMTP認証の設定値（ホスト/ポート/暗号化）が端末側で旧のまま
送信制限（レート制限、送信元アドレス制限）が新サーバー側である

切替当日は「受信OK」で安心しがちですが、業務影響としては送信トラブルも大きいです。必ず送信テストまで行いましょう。

混在期間の運用（併用・周知があると安全）

可能なら、切替直後〜一定期間は「旧サーバーの受信箱も確認できる状態」を残すと安全です。
また、切替後に端末設定変更が必要な人（スマホ等）がいる場合は、切替当日に慌てないよう、事前に手順を共有しておきましょう。

メール切替が落ち着いたら、次は切替直後に最優先で行う確認（Web/メール/SSLなど）です。次の章で、切替後に「何から確認するか」を整理して、確認漏れを防ぎます。

「切替後にメールが届かない／送れない」ときは、原因の切り分け順が重要です。詳しい対処は下記で整理しています。

サーバー移転のメール移行｜送受信できない原因と設定手順（IMAP/SMTP）

切替直後の最優先チェック（Web／メール／SSL）

DNS切替が完了（または切替が進行）した直後は、旧・新が混在している可能性があるとはいえ、"いま止まると致命的なもの"から優先して確認するのが鉄則です。
ここでの目的は、完璧な総点検ではなく、機会損失（問い合わせが届かない・決済できない等）を防ぐことです。

チェックは「Web」「メール」「SSL」の3つに絞り、さらに重要度の高い順で行います。切替直後の混乱を減らすため、できれば事前に確認URLやテスト方法を準備しておきましょう。

切替直後のチェック手順（迷ったらこの順番）

Web：主要ページが見れるか（トップ→主要下層→フォーム/決済/予約）
メール：受信・送信ができるか（重要アドレスを中心に）
SSL：httpsで警告が出ないか／リダイレクトが正しいか
問題があれば「DNS反映中か／新サーバー側の不具合か」を切り分ける

1）Webの最優先チェック（見れる＋動く）

Webは「表示」だけでなく、"問い合わせが届く/決済できる/予約できる"など、動く部分の確認が重要です。特にフォームが死んでいると機会損失が大きいため最優先で確認します。

トップページが表示される（表示崩れ、画像/CSS/JSの欠落がない）
主要下層ページが表示される（サービス/料金/会社概要/ブログ等）
フォーム送信テスト（送信→完了画面→通知メール受信まで確認）
管理画面ログイン（WordPress等）：ログインでき、致命的エラーがない
更新があるサイトの場合：EC/予約/会員など主要導線が動く（該当する場合）

フォームのテストは、切替直後に「外部のGmail等から送る」のも有効です。自社内だけでテストすると、キャッシュや混在の影響で「送れているつもり」になってしまうケースがあります。

2）メールの最優先チェック（受信＋送信）

メールは受信だけOKでも安心できません。業務上は「送信できるか」が同じくらい重要です。切替直後は、重要アドレス（info@等）に絞って確実に確認しましょう。

受信テスト：外部→自社（重要アドレス宛）で受信できる
送信テスト：自社→外部へ送信でき、相手側で受信できる
返信テスト：外部から返信しても受信できる（往復確認）
転送がある場合：転送先でも受信できる
迷惑メールフォルダも確認（切替直後に判定が変わることがある）

受信できない場合は、反映待ちの混在で旧側に届いている可能性もあるため、旧サーバー側の受信箱も同時に確認して、分散していないか見ましょう。

3）SSL（https）の最優先チェック（警告・リダイレクト・www統一）

SSLはユーザーが最も気づきやすい問題で、警告が出ると離脱要因になります。切替直後は、httpsで正常に閲覧できる状態を最優先で作ります。

httpsで開いて鍵マーク（警告なし）になっている
http→httpsのリダイレクトが正しく動く
wwwあり/なしの統一ができている（どちらに揃えるか方針通り）
混在コンテンツ（http画像/JS等）が原因で警告が出ていない
サブドメインもhttps化が必要なら証明書対象に含まれている

SSL警告が出る場合は、証明書の適用漏れ、リダイレクト設定、混在コンテンツが原因になりやすいです。まずは「証明書が当たっているか」を確認し、その後に混在やリダイレクトを見直します。

切替直後に"異常"が出たときの考え方（切り分けのコツ）

切替直後は混在があるため、問題が起きたときに「DNS反映の問題」か「新サーバーの不具合」かを切り分けるのが重要です。

環境によって表示先が違うなら：反映待ち（混在）の可能性が高い
新サーバーに到達しているのに不具合が出るなら：新サーバー側の設定/環境差の可能性が高い
フォームやメールだけ不具合なら：設定漏れ（送信設定/DNS/TXT/SMTP）を優先確認

切替直後の最優先チェックで「Web・メール・SSL」が問題なく動く状態になったら、当日の山場はほぼ越えています。
次章では、移行後の確認とトラブル対処（よくある落とし穴を潰す）に進み、旧サーバー停止前にやるべき最終確認まで整理します。

移行後の確認とトラブル対処（落とし穴を潰す）

切替直後の最優先チェック（Web／メール／SSL）が通っていても、サーバー移行は「はい終了」ではありません。
DNSの混在が落ち着くまでの間に、細かい不具合や設定漏れが見つかったり、数時間〜数日後に「一部の人だけ表示がおかしい」「メールが迷惑メールに入る」などの問題が出ることがあります。

この章では、移行後に起きやすい落とし穴を事前に把握し、確認項目を"優先度順"に潰すための進め方を整理します。
目的は、完璧な点検ではなく、機会損失・信用毀損につながる問題を早期に見つけて解消することです。

移行後の確認の考え方（まずは「重要→全体」）

移行後の確認は、次の順番で進めると漏れが減ります。

重要導線の再確認（フォーム／決済／予約／会員／メール）
表示・機能の広範囲チェック（主要ページ、内部リンク、404等）
外部連携・計測（GA4、Search Console、API、メール認証）
パフォーマンス・運用（速度、バックアップ、監視、セキュリティ）
旧サーバー停止前の最終確認（いつ停止するかの判断）

移行後に"よくある落とし穴"

ここで挙げるのは、実務で起きやすく、かつ見落とすと影響が大きいものです。次の小見出し（#s5-1〜）で、それぞれ対処の考え方も具体的に整理します。

表示崩れや画像欠落（CSS/JS/画像パス、権限、キャッシュ）
500エラー／DB接続エラー（PHP/DB設定差、wp-config、権限）
SSL警告・https問題（証明書、リダイレクト、混在コンテンツ）
フォームは送れたが通知が届かない（送信設定、SMTP、迷惑メール）
メールは受信できるが送信が不安定（SPF/DKIM/DMARC、SMTP制限）
特定の人だけ旧サーバーを見ている（DNSキャッシュ、TTL、回線差）
サブドメインだけ死んでいる（DNS切替漏れ、証明書対象漏れ）
計測が止まった/二重計測になった（タグ設置位置、GTM/GA4設定差）

移行後は「直ったつもり」より「再現確認」

不具合が出たときは、対処したら必ず再現しないことを確認します。移行直後はキャッシュや混在の影響で「たまたま直って見えた」だけのケースもあるため、複数環境（PC/スマホ、別回線）で確認するのが安全です。

次の章から、移行後によくあるトラブルをパターン別に整理し、何を優先して確認し、どう切り分けるかを具体的に解説していきます。

よくあるトラブル（表示崩れ／エラー／SSL警告／メール不達）

移行後のトラブルは、原因が「DNS反映の混在」なのか、「新サーバー側の設定/環境差」なのかで対処がまったく変わります。
まずは焦って設定を触る前に、"どこで起きている問題か"を切り分けるのが最短ルートです。

ここでは、移行後によくあるトラブルを4カテゴリ（表示崩れ／エラー／SSL／メール）に分け、典型原因→確認ポイント→対処の方向性を整理します。

まず最初の切り分け：DNS混在か？新サーバー不具合か？

人や回線によって症状が違う（見える/見えないがバラバラ）→ DNS混在・キャッシュの可能性が高い
どの環境でも同じ症状が出る → 新サーバー側の設定/環境差の可能性が高い
WebはOKだがフォーム/メールだけNG → 送信設定・DNS（MX/TXT）・SMTPを優先疑う

この切り分けができるだけで、無駄な設定変更（状況悪化）をかなり減らせます。

1）表示崩れ（CSS/画像が出ない、レイアウトが崩れる）

表示崩れは、移行直後に最も起きやすいトラブルの一つです。「HTMLは出ているのに見た目だけ変」なら、CSS/JS/画像の読み込み不具合を疑います。

URLがhttpになっていないか（https移行後に混在でブロックされることがある）
画像やCSSのパスが変わっていないか（相対パス/絶対パスの不整合）
ファイル権限（パーミッション）や所有者が原因で読み込めない可能性
キャッシュ（ブラウザ/プラグイン/CDN）が旧状態を保持していないか
サブドメイン配信の静的ファイル（例：cdn.example.com）が切替漏れしていないか

対処の方向性としては、まずSSL（https）と混在を疑い、その次にパスと権限、最後にキャッシュを疑うとスムーズです。

2）エラー（500エラー／DB接続エラー／真っ白）

500エラーや真っ白は、PHPやDB周りの不整合で起きやすいです。WordPressなら「DB接続エラー」「致命的なエラー」などで表面化します。

PHPバージョン差（旧より新が高く、プラグイン/テーマが非対応）
DB接続情報（DB名/ユーザー/パスワード/ホスト名）が新環境と一致していない
wp-config.php等の設定ファイルが新環境用に更新されていない
ファイル権限やディレクトリ所有者が原因で読み込めない
.htaccessやリダイレクト設定が新環境と相性が悪い（Apache/Nginx差）

対処はまずサーバー側のエラーログを見るのが近道です。ログが見られない場合でも、「PHPを旧と同等に下げる」「プラグインを一時停止して切り分ける」など、原因を一つずつ潰す進め方が有効です。

3）SSL警告（鍵マークが出ない／保護されていない通信／混在コンテンツ）

SSL警告はユーザーの離脱要因になりやすく、移行後は優先度が高いです。原因は大きく3つに分かれます。

証明書がまだ適用されていない（発行/設定待ち、対象ドメイン漏れ）
http→httpsのリダイレクトが崩れている（www有無の統一も含む）
ページ内にhttpの画像/JS/CSSが残っている（混在コンテンツで警告）

対処は、まず証明書が当たっているかを確認し、次にリダイレクト、最後に混在コンテンツの順で潰すのが効率的です。
サブドメイン（shop/blog等）もhttps化している場合は、証明書対象に含まれているかも確認しましょう。

4）メール不達（受信できない／送信できない／迷惑メールに入る）

メールは「届かない」の原因が複数あり、さらに切替中は旧/新混在もあるため、切り分けが大切です。

MX切替の反映待ちで、旧側に届いている（まず旧受信箱も確認）
新サーバー側にアカウントがない/容量オーバーで受信できない
転送設定の漏れで別の場所に届いていない
送信だけ失敗：SMTP設定が旧のまま、または送信制限（レート/認証）
迷惑メール判定：SPF/DKIM/DMARC（TXT）不整合、送信元変更の影響

切替直後は、受信テスト（外部→自社）＋送信テスト（自社→外部）＋返信をセットで行い、さらに迷惑メールも確認します。
送信の信頼性は、DNSのTXT（SPF/DKIM/DMARC）に依存することが多いので、移行前に控えたTXTレコードが役に立ちます。

トラブル時の基本方針（焦って弄らない）

移行直後のトラブルで一番避けたいのは、焦って複数箇所を同時に変えてしまい、原因が分からなくなることです。
迷ったら次の方針で進めると安全です。

症状の再現条件を整理（どの端末/回線で起きるか、再現率）
DNS混在か新サーバー不具合かを切り分ける
ログ（サーバー/メール）や設定（DNS/SMTP）を確認して原因候補を絞る
変更は1つずつ行い、都度再確認する
致命的ならロールバック基準に従って戻す

次の章では、旧サーバーを止める前に必ずやっておきたい確認（切替後の安定化チェック）を整理します。移行直後に問題がなくても、旧サーバー停止は急がないのが安全です。

旧サーバー停止前に必ず確認すること

移行後に「Webもメールも動いている」ように見えても、すぐに旧サーバーを解約・停止するのは危険です。
DNSの混在やキャッシュの影響で、一定期間は旧サーバーへアクセスしているユーザーが残ることがありますし、メールも切替中に旧側へ届いている可能性があります。

旧サーバーは、万一のときのロールバック先（保険）でもあります。停止は急がず、「確認できたら止める」順番で進めましょう。

旧サーバー停止前のチェックリスト（最低限これだけ）

DNS切替が安定している（旧への到達がほぼなくなっている）
Webの重要導線が安定稼働（フォーム／決済／予約／会員など）
メールが安定稼働（受信／送信／転送／迷惑メール含む）
SSL・リダイレクトの統一が完了（https、www有無）
外部連携・計測が正常（GA4等、必要な範囲で）
最終バックアップを保存（新サーバー側の現状も含めて）

1）DNS切替の安定（旧サーバーにアクセスが残っていないか）

旧サーバーを止めてよいかの判断で一番大きいのが、旧サーバーへの到達が残っていないかです。
可能なら、旧サーバー側のアクセスログやサーバー管理画面の統計で、切替後もしばらくアクセスが来ていないかを確認します。

旧サーバーのアクセスログに、切替後もしばらくアクセスが来ていないか
wwwやサブドメインなど、切替漏れがないか（旧へアクセスが残る典型）
社内の特定回線だけ旧を見ていないか（キャッシュ/プロキシの影響）

ログが見られない場合でも、複数環境（PC/スマホ、別回線）で表示先が揃っていることを確認し、少なくとも「旧へ戻ってしまうケース」がない状態を目指します。

2）Webの重要導線（"見れる"ではなく"成果が出る"）

旧サーバー停止前に確認すべきは「見た目」より、機会損失に直結する動作です。特にフォームは必ず再確認しましょう。

フォーム送信→通知メール受信まで正常（外部Gmail等からもテスト）
管理画面で更新ができる（WordPress等）
EC/予約/会員がある場合：購入/予約/ログインなど主要操作が正常
404やリンク切れが大量に出ていない（主要導線の遷移）

3）メールの安定（切替中に旧へ届いたメールが残っていないか）

旧サーバー停止で一番怖いのが「旧側に届いていたメールに気づかず消える」ことです。停止前に、旧側の受信箱を確認し、分散が起きていないかを潰します。

旧サーバー側の受信箱に、切替後に届いたメールが残っていないか
重要アドレスで、受信・送信・返信が安定しているか
転送設定や共有設定が新側で再現できているか
迷惑メール判定が極端に悪化していないか（取引先からの不達報告がないか）

4）SSL/リダイレクト/統一（ユーザー体験とSEOの土台）

旧サーバーを止める前に、httpsとドメイン表記（www有無）を統一し、警告やループがない状態にします。ここが不完全だと、旧サーバー停止後に一気にエラー化することがあります。

httpsで警告が出ない（証明書適用、混在コンテンツ）
http→https、wwwあり/なしのリダイレクトが意図通り
サブドメインも含め、必要な範囲でSSLが適用されている

5）外部連携・計測（最低限の確認）

すべてを完璧に確認しなくてもよいですが、最低限「移行で止まると困るもの」はチェックします。

GA4等の計測タグが動いている（主要ページの計測）
Search Console等で致命的なエラーが出ていない（必要に応じて）
決済・予約・外部フォームなど、重要SaaS連携が正常

6）最終バックアップ（"新サーバー側の現状"も残す）

旧サーバー停止前に、旧のバックアップだけでなく、新サーバー側の現状（動いている状態）もバックアップしておくと、万一の復旧が楽になります。

新サーバー側のWebファイル／DBのバックアップ
DNS設定の最終版（現在のA/AAAA/CNAME/MX/TXTの控え）
移行作業メモ（変更した箇所、設定値、切替日時、担当者）

旧サーバー停止の目安（急がない）

停止タイミングの絶対解はありませんが、少なくとも切替直後に問題がないことと、一定期間安定していることを確認してからが安全です。
旧サーバーを止める＝ロールバックの保険が消える、ということなので、「止めても困らない」状態になってから進めましょう。

ここまで確認できたら、移行作業はほぼ完了です。最後に、記事のまとめとして「この手順で進めれば安全に移行できる」という要点を整理し、必要なら移行代行/サポートへの導線を設置すると、CVにもつながりやすくなります。

移行後にやるべき運用（監視・バックアップ・更新）

サーバー移行は「切り替えて終わり」ではなく、移行後の運用で初めて安定します。
せっかく移行しても、監視やバックアップが弱いままだと、障害や改ざん、更新トラブルが起きたときに復旧が遅れ、結果的に損失が大きくなります。

ここでは、移行後に最低限やっておきたい運用を監視／バックアップ／更新の3つに分けて整理します。
「全部完璧に」ではなく、まずはやるべきことを仕組み化して習慣化するのがポイントです。

1）監視：異常を早く気づける仕組みを作る

一番のリスクは「止まっているのに気づけない」ことです。特に問い合わせフォームやメールが止まると機会損失が大きいため、移行後は監視を入れておくのが安全です。

サイトの死活監視（トップページが定期的に開けるか）
フォームの簡易監視（週1などでテスト送信し、通知が届くか確認）
メールの簡易監視（重要アドレスで送受信テストを定期的に実施）
サーバー通知（障害通知、容量警告、WAF検知など）が届くように設定
アクセス急減/急増のアラート（可能ならGA4等で異常検知）

監視は「24時間監視体制」を作らなくてもOKです。最低限、止まったら連絡が来る状態にして、気づきの遅れを減らすことが目的です。

2）バックアップ：復旧できる状態を"常に"維持する

移行前はバックアップを丁寧に取ったはずですが、運用では「定期バックアップ」と「復元できることの確認」が重要になります。特にWordPressは更新や攻撃の影響を受けやすいため、バックアップがあるかどうかで復旧コストが大きく変わります。

定期バックアップの設定（自動バックアップがあるか、頻度は十分か）
保管先の分散（サーバー内だけでなく外部保管を検討）
保持期間（過去に遡れる期間：直近だけだと不具合に気づけないことがある）
DBも含むか（ファイルだけでなくDBがバックアップ対象になっているか）
復元手順の確認（いざという時に戻せるか、手順をメモしておく）

バックアップの理想は、「何かあったら◯日前の状態に戻せる」ことです。少なくとも「復元方法が分からない自動バックアップ」にならないよう、復元手順を一度確認しておくと安心です。

3）更新：移行後の"更新トラブル"を防ぐ運用

移行後に起きやすいのが、WordPressやプラグイン更新をきっかけに不具合が出るケースです。移行直後は環境が変わったばかりなので、更新は慎重に運用すると安全です。

移行直後は大きな更新を急がない（安定稼働を優先）
更新前にバックアップを取る（自動でも手動でもOK）
更新はまとめてではなく、段階的に行う（原因切り分けしやすくする）
更新後に最低限の動作確認（表示・フォーム・管理画面）を行う
可能なら検証環境（stg等）で先に更新して確認する

特にフォームは「気づきにくく、損失が大きい」ため、更新後の確認項目に必ず含めるのがおすすめです。

移行後の運用で"やっておくと強い"追加ポイント

余力があれば、移行を機に次のような整備も進めると、トラブル耐性が上がります。

管理情報の整理（ログイン情報、DNS設定、移行メモを一箇所にまとめる）
セキュリティ強化（WAF、ログイン保護、不要アカウント削除、二要素認証等）
容量・速度の定期チェック（ディスク逼迫や遅延の兆候を早めに掴む）
障害時の連絡ルール（誰が判断し、どこに連絡するか）を決める

ここまでできれば、移行後の運用はかなり安定します。
次は記事のまとめとして、今回の流れ（準備→事前テスト→DNS切替→確認→運用）を短く整理し、必要なら「移行サポートの相談窓口」への導線を入れると、検索ユーザーの不安を解消しつつCVにもつながりやすくなります。

自分でやる？代行に頼む？判断基準と見積の考え方

サーバー移行は、手順さえ分かれば自分でも進められます。
ただし現実には、「途中で詰まって時間が溶ける」「メールだけ止まって業務に影響」「切替が怖くて先延ばし」など、心理的ハードルと業務影響が大きい作業でもあります。

この章では、自分でやるべきケースと代行に頼んだ方がよいケースを判断できるように、具体的な基準と、見積（費用感）の考え方を整理します。
「高い/安い」ではなく、止まった時の損失・自分の時間・リスクを含めて考えると判断しやすくなります。

「止められない」「メールが不安」「複数ドメインで怖い」など、少しでも不安がある場合は、切替当日の立ち会い・部分サポートも含めて相談できます。

サーバー移転代行｜WordPress・メール・DNS/SSLまで一括対応

1）自分でやりやすいケース（条件が揃っている）

次の条件が揃っていれば、手順に沿って自力移行できる可能性が高いです。

サイトが小規模（ページ数が少なく、機能もシンプル）
メール移行がない、またはメールを使っていない/外部サービス利用（例：Google Workspace等）
更新が少なく、切替時間を選びやすい（深夜に止めても問題ない等）
DNSの管理場所が明確で、A/CNAME/MXの意味が何となく分かる
最悪の場合、旧サーバーへ戻しても業務に致命傷が出ない

この場合でも、最低限バックアップとロールバック手順だけは決めてから切替しましょう。これがあるだけで"怖さ"が減ります。

2）代行を検討した方がよいケース（リスク・工数が増える）

次のどれかに当てはまる場合は、移行の難易度かリスクが上がります。自力でやる場合でも「部分的にサポートを受ける」選択肢が有効です。

業務メールを使っている（止まると困る、アドレス数が多い、転送や共有がある）
EC/予約/会員など更新が発生するサイト（切替中のデータ整合が難しい）
サブドメインが多い（shop/blog/mail等が複数ある）
外部連携が多い（決済、予約SaaS、API、フォーム連携、WAF/CDN等）
DNSやサーバーの管理情報が散らばっていて、棚卸しに時間がかかる
切替に失敗した時の損失が大きい（問い合わせ/売上が止まる、信用に影響）
自分の作業時間を確保できない（止まると焦って判断ミスが起きやすい）

特に「メール＋フォーム」が絡むと、切替後に気づきにくい不達が起きやすいので、代行/サポートの価値が出やすい領域です。

3）代行の"範囲"を決める（全部丸投げ以外もある）

代行＝全部お任せ、だけではありません。コストを抑えつつ、リスクの高い部分だけ外注するのも現実的です。

スポット相談：棚卸し・計画だけ一緒に作る（切替は自分）
切替当日の立ち会い：DNS切替・確認・切り戻し判断をサポート
メールだけ代行：MX/TXT含めてメール移行を重点対応
丸ごと代行：棚卸し〜移行後確認まで一括対応

「どこが怖いか」を分解すると、必要なサポート範囲が見えます。多くの方は、DNS切替とメールが不安の中心になりやすいです。

4）見積の考え方（料金が変わるポイント）

サーバー移行の見積は、作業量だけでなく「リスク」と「確認工数」で上下します。費用感を理解するには、見積が増える要素を知っておくのが近道です。

サイト数（メイン＋サブドメイン＋別サイトの数）
CMSの種類（WordPress等）と規模（容量、プラグイン数、独自改修）
DBの数・容量（更新頻度が高いほど難易度UP）
メールアカウント数・運用の複雑さ（転送、共有、特殊設定）
外部連携の数（決済、予約、フォーム連携、WAF/CDN等）
切替可能な時間帯の制約（深夜対応、立ち会い時間）
リスク管理（ロールバック設計、事前テスト、検証環境の有無）

同じ「WordPress移行」でも、ブログ1つと、業務メール＋EC＋複数サブドメインでは、必要な確認量がまったく違います。見積の差は、"作業の量"より"安全に終わらせるための確認量"で出ることが多いです。

5）判断の結論：迷ったら「損失」と「時間」で考える

迷った時は、次の2軸で考えると判断しやすいです。

止まった時の損失：問い合わせが止まる/売上が止まる/信用に影響する
自分の時間：調査・切替・復旧まで含めて確保できるか

「自分でやる自信がない」＝代行一択ではなく、スポット相談や切替立ち会いのように、リスクの高い部分だけ支援を受けると、コストと安全性のバランスが取りやすくなります。

次はまとめとして、この記事の要点を短く整理し、サーバー移行で悩む人が「次に何をすべきか」が分かる形で締めると、問い合わせにもつながりやすくなります。

代行をおすすめするケース（停止リスク・メール・複数ドメイン等）

サーバー移行は自力でも可能ですが、条件によっては「自分でやること」自体がリスクになります。
特に、停止や不達が起きたときの損失が大きいケースでは、移行作業の費用よりも止まった時の損失・復旧コストの方が高くつくことが少なくありません。

ここでは、代行（または切替立ち会い/スポット支援）をおすすめしやすい典型ケースを整理します。
当てはまる項目が多いほど、代行の価値が出やすいと考えてください。

1）停止リスクが大きい（止まると困る）

「止まっても深夜に直せばいい」では済まないサイトは、代行の優先度が上がります。

問い合わせ・見積が主要なCV（止まると機会損失が大きい）
EC/予約/会員など、リアルタイムに売上・予約が動く
広告を回している（PPC/LP）ため、停止＝広告費の無駄が出る
繁忙期・キャンペーン中で、切替失敗が許されない
社内外の関係者が多く、切替が遅れると調整コストが増える

このタイプは、切替当日の対応スピードが重要になります。代行や立ち会いがあると、判断と復旧が速くなりやすいです。

2）業務メールを使っている（不達が致命的）

メールはWebよりも「届かない」に気づきにくく、気づいた時には損失が発生していることがあります。以下に当てはまるなら、メール移行を含む代行を検討する価値があります。

info@や代表メールが止まると困る（問い合わせ・受注・取引先連絡）
メールアドレス数が多い／部署別アドレスが複数ある
転送・共有・自動返信など、運用が複雑
メールの過去データ（IMAP）を移行する必要がある
SPF/DKIM/DMARCなど送信認証（TXT）が絡む（迷惑メール化のリスク）

メールは「受信OK」でも「送信が迷惑メールに入る」などが後から出ることがあります。DNS（MX/TXT）とSMTPを含めて切り分けできるかが、代行価値の分かれ目になります。

3）複数ドメイン／サブドメインがある（切替漏れが起きやすい）

「メインは表示できたのに、blogやshopだけ旧のまま」などは典型的な落とし穴です。構成が複雑だと、切替対象の棚卸しだけでも時間がかかります。

サブドメインが複数ある（shop/blog/lp/mailなど）
別ドメインのLPやキャンペーンサイトがある
CDN/WAF（Cloudflare等）を使っていて、DNSが二重構造になっている
DNSの管理が分散（ドメイン会社/サーバー会社/外部DNS）している

このタイプは、切替漏れが起きると「一部だけ死ぬ」ため気づきにくいです。代行で棚卸しと切替対象の整理から入れると、安全性が上がります。

4）外部連携が多い（動いて初めて気づく系）

外部連携は、表示だけでは分からず、動作テストしないと不具合が見えません。以下に当てはまると確認工数が増え、代行メリットが出やすいです。

決済、予約、会員、在庫連携などのSaaSがある
フォームが外部連携（CRM、Slack通知、スプレッドシート連携等）している
API連携やWebhookなど、サーバー起点の通信がある
メール送信がSMTP経由（外部SMTP、WP SMTP等）になっている

5）自分の時間が確保できない／判断が苦手

移行は「調べながら進める」と、想定より時間がかかりやすいです。特に切替当日は、判断の連続になります。

平日に時間が取れず、切替後の監視ができない
DNSやメール設定の経験が少なく、切り分けに不安がある
社内の責任として"失敗できない"プレッシャーが大きい
過去に移行で失敗した経験がある

この場合は、全部代行ではなくても、切替当日の立ち会いやスポット相談だけでも価値が出ます。

代行を頼むなら「何を任せるか」を明確に

代行の費用は、作業量よりも「安全に終わらせるための確認量」で変わります。見積を取りやすくするには、次を整理しておくとスムーズです。

サイトの種類と数（WP/静的/EC等、サブドメイン含む）
メールアドレス数と運用（IMAP/POP、転送、共有、過去メール移行要否）
DNSの管理場所（どこでA/MX/TXTを管理しているか）
切替可能な時間帯（夜間対応が必要か）
外部連携の有無（決済/予約/フォーム連携等）

次の章では、代行に依頼する場合の「依頼時に伝えるべき情報」や「見積の見方（比較ポイント）」を整理すると、読者の不安がさらに減り、問い合わせにもつながりやすくなります。

依頼時に必要な情報（見積を早く出すチェックリスト）

サーバー移行の見積が遅くなる一番の原因は、作業そのものではなく、「現状が分からない」ことです。
逆に言えば、依頼前に情報を揃えておくと、見積は早く・正確になり、移行計画も立てやすくなります。

この章では、移行代行やサポートに依頼する際に、最低限伝えるとスムーズな情報をチェックリストとしてまとめます。
全部が分からなくてもOKですが、分かる範囲で埋めるほど、見積の精度が上がります。

1）サイト情報（何を移すのか）

対象ドメイン（例：example.com、www、サブドメイン一覧）
サイトの種類（WordPress／静的HTML／EC／予約／会員制など）
サイト数（メイン＋サブドメイン＋別ドメインのサイトがあるか）
容量の目安（Webファイル容量、DB容量、画像が多い等）
更新頻度（移行中に更新が発生するか：EC/予約/ブログ更新など）

2）旧サーバー情報（現状の環境）

旧サーバー会社名・契約プラン（分かる範囲で）
管理画面ログインの有無（契約者/管理者が誰か）
FTP/SSHの有無（接続方法、制限があるか）
PHPバージョン・DBの種類（分かる範囲で）
バックアップ取得方法（自動/手動、取得できる範囲）

3）新サーバー情報（移行先の条件）

まだ移行先が未決定でも大丈夫ですが、決まっている場合は先に共有すると見積がブレにくくなります。

新サーバー会社名・プラン（決まっていれば）
新サーバーの初期状態（WordPress簡単インストール等の利用有無）
CDN/WAFの利用有無（Cloudflare等）
無料SSLの提供有無（Let's Encrypt等）
メールを新サーバーで運用するか（外部メールにするか）

4）DNS情報（どこで何を管理しているか）

DNSは「切替当日に必ず触る場所」なので、管理場所が分かるだけでも作業が一気に進みます。

ドメインの管理会社（例：お名前.com等）
DNSをどこで管理しているか（ドメイン会社／サーバー会社／外部DNS）
現在のDNSレコードの控え（A/AAAA/CNAME/MX/TXT）※分かる範囲で
ネームサーバーを変更しているか（分からなければ「不明」でOK）
サブドメインの有無（shop/blog/mail等）

DNSの画面が分からない場合でも、「どこでドメインを契約しているか」だけでも分かれば、調査が進みやすくなります。

5）メール情報（移行で一番事故りやすい）

メールが絡む場合は、見積の工数が大きく変わります。分かる範囲で整理しておくと、代行側の確認が速くなります。

メール運用の有無（サーバー付属メール／Google Workspace／Microsoft 365など）
メールアドレス数（代表/部署/個人、共有アドレス含む）
IMAP/POPの利用状況（端末側保存か、サーバー側保存か）
転送・自動返信・フィルタ等の特殊設定があるか
過去メールの移行が必要か（必要/不要）
SPF/DKIM/DMARC（TXT）の設定有無（分からなければ不明でOK）

6）外部連携・重要機能（動かないと困るもの）

見積の精度を上げるには、「何を守るべきか」を伝えるのが有効です。特に"動いて初めて気づく"系があると確認工数が増えます。

フォーム（通知先、外部連携：CRM/Slack/スプレッドシート等）
決済・予約・会員機能（該当する場合）
外部SaaS連携（決済/予約/在庫/チャット等）
メール送信方式（SMTPプラグイン、外部SMTP等）
広告/計測（GA4、GTM、コンバージョン計測の重要性）

7）希望条件（スケジュール・停止許容・立ち会い）

同じ移行でも、条件が変わると工数と費用が変わります。見積を早く出すには、ここを先に共有するとスムーズです。

希望の移行時期（いつまでに）
切替できる時間帯（深夜/休日のみ等）
停止許容（できれば無停止/数分ならOK/多少止まってもOK等）
立ち会いの要否（当日の連絡手段、担当者）
サポート範囲の希望（丸ごと/切替のみ/メールのみ/相談のみ）

このチェックリストの使い方

依頼時は、上記を「分かる範囲で箇条書き」で送るだけで十分です。分からない項目は「不明」でOKです。
代行側が必要な調査を進めやすくなり、結果として見積が早く・ブレにくくなります。

次はまとめ（#end）として、この記事の要点を短く整理し、読者が「自分で進めるなら次に何をするか」「不安ならどこを相談すべきか」が分かる形で締めると、行動につながりやすくなります。

まとめ：サーバー移行は「全体像→準備→テスト→切替→確認」の順で進める

サーバー移行は、作業の手数そのものよりも、「抜け漏れ」と「切替当日の混乱」で失敗しやすい作業です。
だからこそ、いきなり切り替えるのではなく、全体像→準備→テスト→切替→確認の順で進めることで、ダウンタイムとトラブルを最小化できます。

この記事の要点（5ステップ）

全体像を整理：移行方式（同時稼働/DNS切替）と、必要情報（DNS/メール/契約）を先に揃える
移行前の準備：棚卸し→バックアップ→切替計画（TTL/切替日時/ロールバック）で"事故りにくい状態"を作る
新サーバーで事前テスト：環境準備（PHP/DB/SSL）→hosts等で表示/フォーム/管理画面を確認し、切替前に"動く状態"へ
切替当日はDNSを切り替える：Web（A/AAAA/CNAME）とメール（MX）を順序立てて変更し、混在を前提に冷静に確認する
移行後に落とし穴を潰す：Web/メール/SSLの優先チェック→トラブル切り分け→旧サーバー停止前の最終確認で安全に完了

特に重要：フォームとメールは「動作確認」までがセット

移行後に一番困るのは、サイトは見れているのに問い合わせが届かない状態です。
フォームは必ず「送信→完了画面→通知メール受信」まで確認し、メールは「受信＋送信＋返信」まで確認しましょう。

代行を検討する目安

業務メールが絡む、サブドメインが多い、外部連携が多い、停止が許されない...といった条件がある場合は、丸投げでなくても、切替当日の立ち会いやスポット相談だけでもリスクを大きく減らせます。

もし「DNSやメールが不安」「途中で詰まりそう」「止められないサイトで失敗できない」などがあれば、無理に一人で抱えず、状況を棚卸ししたうえで、必要な範囲だけサポートを活用するのがおすすめです。
サーバー移行は、順番さえ守れば、必要以上に怖い作業ではありません。この記事の流れに沿って、"切替前に動く状態を作る"ことを意識して進めてみてください。

移行に不安がある場合は、状況の棚卸しから一緒に対応できます（スポット相談・切替立ち会いも可）