【PR】本記事は広告(アフィリエイト)を含みます。料金・仕様は目安で変動します。最新情報は各公式でご確認ください。
コーポレートサイトや業務システムのサーバー移転は、インフラ担当者にとって緊張を伴う作業です。コーポレートサイトが数時間落ちれば問い合わせフォームや採用ページが止まり、メールも届かなくなれば商談や請求のやり取りに影響します。経営層から見れば、移転は「失敗が許されないのに成果が見えにくい」典型的なバックオフィス作業です。本記事は特定の移転先を推すのではなく、ダウンタイムを最小限に抑えるための段取りを、DNS切替と事前検証を軸に実務手順として整理します。自社の構成に当てはめて、移転計画のチェックリストとしてご活用ください。
なお「ダウンタイムなし(ゼロ)」をうたう情報も見かけますが、現実には停止時間を厳密にゼロへ抑えきるのは難しく、目指すべきは「体感ゼロに近い最小化」です。本記事もその前提で手順を組み立てます。
結論:停止時間はDNSキャッシュ(TTL)の時間差に起因する。最小化の要点は4つ——切替の2〜3日前にTTLを600秒程度へ短縮、hostsで公開前に新サーバーを先行検証、アクセスの少ない時間帯に切替、旧サーバーを残して並行運用し浸透完了後に撤去。切り戻し前提で段取りを組むのが安全です。
なぜダウンタイムが発生するのか——DNSの仕組み
結論:ブラウザはDNSキャッシュを参照し、その情報はTTLの分だけ保持される。レコードを書き換えてもTTLが切れるまで一部の利用者は旧サーバーを見続け、この時間差(DNS浸透)がリスク時間帯になります。
サーバー移転で停止時間が生まれる主因は、DNSの切替に時間差があることです。利用者のブラウザは、ドメイン名をIPアドレスに変換する際、DNSキャッシュサーバーの情報を参照します。このキャッシュはTTL(Time To Live)という有効期限の分だけ保持されるため、レコードを新サーバーへ書き換えても、TTLが切れるまで一部の利用者は旧サーバーを見続けます。この時間差が「DNS浸透」と呼ばれ、旧新どちらに振り分けられるか混在する期間が、実質的なリスク時間帯になります。
移転手順を時系列で——5つのフェーズ
結論:移転は「TTL短縮・新サーバー構築・先行検証・DNS切替・並行運用と撤去」の5段で進める。当日作業はDNS切替だけで済むよう、数日前から準備を前倒しするのが定石です。
ダウンタイムを最小化する移転は、当日だけでなく数日前から段取りを始めるのが定石です。下表は標準的な進め方の目安です(構成・サービスにより前後します。2026年時点の一般的な流れ)。
| フェーズ | 時期の目安 | 主な作業 |
|---|---|---|
| (1)TTL短縮 | 切替の2〜3日前 | TTLを600秒など短い値へ変更 |
| (2)新サーバー構築 | 数日前〜前日 | データ移行・SSL証明書・設定の複製 |
| (3)先行検証 | 切替前 | hostsで自端末だけ新サーバーを確認 |
| (4)DNS切替 | アクセスの少ない時間帯 | Aレコード等を新サーバーへ変更 |
| (5)並行運用・撤去 | 切替後 数日〜1週間 | 旧サーバーを残し浸透完了後に停止 |
構成別の進め方の目安:(1)WordPressなど一般的なCMSのサイトは、上の5フェーズをそのまま適用できます。(2)メールも同ドメインで運用している場合は、MXレコードの切替を忘れず工程に加えます。(3)データベースの書き込みが頻繁なサイト(会員制・EC)は、移行タイミングで一時的に更新を止めるか、切替直後の二重更新を防ぐ段取りが要ります。自社がどれに当たるかで、追加すべき確認項目が変わります。
カギは「事前のTTL短縮」
結論:当日ではなく事前にTTLを短くするのが最大のポイント。86400秒(24時間)のまま当日切替すると直前にキャッシュした端末は最大24時間旧を見続けるため、2〜3日前に600秒程度へ下げてから本番に臨みます。
停止時間を縮める最大のポイントは、当日ではなく事前にTTLを短くしておくことです。たとえばTTLが86400秒(24時間)のまま当日に切り替えると、直前にキャッシュした端末はその後最大24時間旧サーバーを見続けます。切替の2〜3日前にTTLを600秒程度へ下げ、変更前の長いTTLが切れるのを待ってから本番切替に臨むと、古い情報が短時間で破棄され、新サーバーへ速やかに振り分けられます。なお、引っ越し元のネームサーバーでTTLを変更できない契約もあるため、自社の管理画面で可否を事前に確認しておきましょう。
切替前の「先行検証」を省かない
結論:PCのhostsファイルに「新サーバーのIP ドメイン名」を一時記述すると、作業者の端末だけが新サーバーへ向く。公開前に表示・フォーム・ログイン・SSL・メールを実地点検でき、不具合の利用者影響を防げます。
DNSを切り替えてしまうと、不具合が見つかっても利用者に影響が及びます。そこで、切替前に新サーバーが正しく動くかを作業者の端末だけで先に確認するのが定石です。具体的には、PCのhostsファイルに「新サーバーのIP ドメイン名」を一時的に記述すると、その端末からのアクセスだけが新サーバーへ向き、世界に公開する前に表示・フォーム送信・ログイン・決済導線などを実地で点検できます。確認すべき観点は、(1)全ページの表示崩れ、(2)フォームやお問い合わせの送信、(3)ログイン・会員機能、(4)SSL証明書の有効性、(5)リダイレクト設定、(6)メールの送受信です。
当日の運用——アクセスの谷を狙い、後戻りできるように
結論:本番切替はアクセスの最も少ない時間帯を選び、複数地点から表示と浸透状況を確認する。旧環境を消さず残す「ロールバック前提」で進め、想定停止時間・並行運用期間・切り戻し手段を経営層へ事前共有します。
本番のDNS切替は、サイトのアクセス解析を見て利用者が最も少ない時間帯(深夜・早朝など)を選ぶと影響を抑えられます。切替後は、複数の地点からの表示確認や、DNSの伝播状況を確認できるツールで浸透の進み具合を観察します。万一新サーバーに問題が出た場合に旧サーバーへ戻せるよう、旧環境を消さずに残しておく「ロールバック前提」の段取りが、リスクを下げる実務上の要点です。CFO・経営層への報告では、想定停止時間・並行運用期間・切り戻し手段の三点を事前に共有しておくと、合意形成がスムーズになります。
サイト構成別・あなたに必要な段取り(モデルケース)
同じ「サーバー移転」でも、サイトの構成で追加すべき確認項目は変わります。自社に近いタイプから段取りに足してください。
タイプA:WordPressなど一般的なCMSのコーポレートサイト(Web公開が中心・更新は編集部が時々)
おすすめは5フェーズ(TTL短縮・新サーバー構築・先行検証・DNS切替・並行運用)をそのまま適用することです。切替の2〜3日前にTTLを600秒程度へ下げ、当日作業はDNS切替だけで済むよう前倒しします。
タイプB:同じドメインでメールも運用している(問い合わせ・請求のやり取りがメール中心)
おすすめはMXレコードの切替を工程に組み込むことです。Webだけ移してメールの切替を忘れると着信が止まります。Web・メール・サブドメインを一覧化し、切替漏れを防ぎます。
タイプC:書き込みが頻繁な会員制・ECサイト(注文や会員情報が常時更新される)
おすすめは移行タイミングで一時的に更新を止める段取りです。切替直後の二重更新を防ぐため、書き込みの一時停止やメンテナンス告知をあらかじめ計画に入れます。
どのタイプでも、旧環境を消さずに残す「ロールバック前提」と、想定停止時間・並行運用期間・切り戻し手段の経営層への事前共有が要点です。複数のタイプに当てはまる場合は、該当する確認項目をすべて段取りに足してください。
編集独立性——移転先は要件で選ぶ
結論:移転先は提携の有無ではなく、移行サポート・TTL変更の可否・SSL引き継ぎ・メール移行の手厚さで選ぶ。自社サイトの構成(CMSの種類・メールの有無・トラフィック規模)に合うかを公式情報で確認します。
本記事は広告を含みますが、移転先は提携の有無で選ぶものではありません。法人サイトの移転先としては、エックスサーバー(XServerビジネス)・さくらのレンタルサーバ・CPI・カゴヤ・ConoHa・ロリポップなど複数の選択肢があり、移行サポートの有無、TTL変更の可否、SSLの引き継ぎ方法、メール移行の手厚さがそれぞれ異なります。移行代行サービスを用意している事業者もあります。提携の有無を問わず、自社サイトの構成(WordPressか独自システムか、メールの有無、トラフィック規模)に合うかを公式情報で確認して選定してください。
よくある質問
サーバー移転でダウンタイムはなぜ生じますか。
DNSキャッシュ(TTL)の時間差が主因です。レコードを新サーバーへ書き換えても、TTLが切れるまで一部の利用者は旧サーバーを見続けます。この「DNS浸透」の期間が実質的なリスク時間帯になります。
ダウンタイムを最小化する一番のコツは。
当日ではなく事前にTTLを短くしておくことです。切替の2〜3日前にTTLを600秒程度へ下げ、古い長いTTLが切れるのを待ってから本番切替に臨むと、新サーバーへ速やかに振り分けられます。
切替で失敗しないための備えは。
公開前にhostsで作業者の端末だけ新サーバーを先行検証し、アクセスの少ない時間帯に切り替え、旧サーバーを数日〜1週間ほど並行運用してから撤去します。切り戻せる「ロールバック前提」で進めるのが安全です。
まとめ
サーバー移転のダウンタイムは、DNSのキャッシュ(TTL)の仕組みに起因します。最小化の要点は、(1)切替の2〜3日前にTTLを短縮しておく、(2)hostsを使って公開前に新サーバーを先行検証する、(3)アクセスの少ない時間帯に切り替える、(4)旧サーバーを残して並行運用し、浸透完了後に撤去する、の四つです。「ゼロ」を目指すより「体感ゼロに近い最小化」を現実的な目標に置き、切り戻し手段を用意したうえで段取りを組むことが、失敗の許されない移転を着実に進めるコツです。移転先の見極め基準は法人サーバー契約前チェックリスト|SLA・サポート・バックアップを確認、安さ偏重で移転費用がかさむ落とし穴はレンタルサーバー選びで失敗する原因|安さ重視が招く運用リスクもあわせてご覧ください。手順や料金は目安で変動するため、移転先の最新情報をあわせてご確認ください。
次に読む
移転先の選定に役立つ関連記事です。検討段階に近いものからご覧ください。
- コーポレートサイト向けレンタルサーバーの選び方|稼働率と表示速度で選ぶ
- WordPress運用に向くサーバーの選び方|高速化と安定運用の基準
- 法人レンタルサーバーの料金相場|共用・VPS・専用の費用構造を比較
【PR】本記事は広告(アフィリエイト)を含みます。掲載のサービスには当サイトと提携関係にあるものと、提携関係にないものの双方が含まれます。料金・仕様・サポート条件は目安で変動するため、契約前に各公式の最新情報をご確認ください。
