VPS移行はDNS変更だけでは終わらない：書込みと切戻しの計画表
VPSの移行では、DNSの向き先とデータを書き込む先を別々に決める。新旧の両方へ利用者が届く間に、どちらのデータを正とするかが必要になる。
TTLを下げても、既存キャッシュは消えない
CloudflareのTTL資料は、DNS回答がキャッシュされる期間としてTTLを説明している。変更前の回答がキャッシュされていれば、TTLを下げた操作だけで全員の向き先がその場で更新されるとは限らない。
そのため、「切替時刻にDNSを書き換える」「失敗したらすぐDNSを戻す」だけでは、停止時間や切戻しを保証する計画にならない。どの回答がどこで観測できたかと、アプリのデータの状態を分けて記録する。資料確認日: 2026年9月14日。
切替え前に埋める移行票
当サイトでは、操作の順番だけでなく、中止条件を同じ行に置く。
| 段階 | 担当が確認すること | 次へ進まない条件 |
|---|---|---|
| 新環境の準備 | OS、アプリ版、設定、証明書、接続先 | 必須機能が未確認 |
| 保存物の復元 | DB・添付・設定を隔離して照合 | 件数や内容が合わない |
| 書込みの整理 | 新旧どちらを正とするか、同期方法 | データの分岐が解消できない |
| 処理の停止 | 定期処理、キュー、受信の扱い | 二重実行や取りこぼしが不明 |
| 最終反映 | 最後の差分、停止中の受付 | 差分がそろわない |
| DNS等の変更 | A/AAAA、旧経路、新経路を確認 | 想定外の向き先が残る |
| 再開 | 読む・書く・処理する機能を確認 | 業務側が再開を確認できない |
| 旧環境の終了 | 保持期限と切戻しの要否 | 新しい保存物を戻せない |
この表は移行の設計用で、特定アプリを無停止で移す手順ではない。書込み停止が必要か、同期が使えるか、DBの版を変えられるかは対象アプリの公式手順と保守担当の確認が要る。
切戻しで「新しいデータ」を失わない
架空の例として、切替え後に新環境へ10件の受付が入り、その後に旧環境へDNSを戻す場面を考える。旧環境にその10件がなければ、名前の向き先を戻しても受付データは戻らない。二重に受け付けたものがあれば、重複の扱いも必要だ。
切戻すか判断する人には、確認済みのデータ、止める処理、照合方法、再開の条件を渡す。許容する欠損や停止の範囲が決まらなければ、切替えを始める前に業務側と詰める。
旧環境は「念のため起動」のまま放置しない
残す理由と期限を決め、定期ジョブや外部送信が動かない状態を確認する。退避として残すことと、本番として二重に動かすことは違う。旧環境にも料金と認証情報が残るため、終了時のデータ退避、アクセス権、契約期限まで担当を割り当てる。
到達の切り分けはIPv4/IPv6と公開ポート、停止を知らせる経路は監視と通知へ。別環境に戻す訓練の例は復元記録にある。ただし、そこではDNSを含む本番移行は試していない。
最終的な移行負担が分かったら、現契約と候補の比較で、料金差だけでなく継続・変更・乗換えを選ぶ。旧契約の終了は解約前の退避を終えてから判断する。