ドメイン移管の手順と費用を実務目線で解説【個人開発のサイト引っ越し・ダウンタイム回避チェックリスト2025】
結論:移管でサイトが落ちる原因はDNSであって、移管手続きではない
ドメイン移管(レジストラ変更)そのものは、実はサイトの表示に直接は影響しない。落ちるのは、移管と同時にネームサーバー(NS)まで切り替えて、レコードの移し漏れが出たときだ。
だから鉄則は1つ。
NS切替とレジストラ移管を、同じ日にやらない。
先にDNSだけ新しい事業者へ移して安定を確認し、後日レジストラを移管する。これだけでダウンタイムのリスクはほぼ消える。以下、時系列の手順・費用・詰まりどころを実務順に整理する。
まず整理:移管で「何が」動くのか
個人開発者がごちゃ混ぜにしがちな3つを分けておく。
| 対象 | 動くもの | サイトへの影響 |
|---|---|---|
| レジストラ移管 | ドメインの管理事業者・更新料の請求先 | 原則なし(NSはそのまま引き継がれる) |
| DNS移管(NS切替) | 権威DNSサーバーとゾーンレコード | 大きい。移し漏れると即障害 |
| サーバー移転 | 実際の配信先IP/CNAME | Aレコード等の変更で発生 |
「ドメイン移管したらメールが死んだ」という事故は、ほぼ2番目でMXレコードを写し忘れているだけである。
費用の目安(必ず公式の最新価格を確認)
- gTLD(.com / .net / .dev など): 移管費用として1年分の更新料相当がかかり、その分だけ有効期限が1年延長される。実質「更新の前払い」で、捨て金にはなりにくい。
- .jp(汎用JP): 指定事業者変更として扱われ、料金体系がgTLDと異なる。移管手数料が無料の事業者もあれば有料のところもある。
- プレミアムドメイン・一部の新gTLD: 更新料自体が高額な場合があり、移管時にその金額が請求される。
価格改定は頻繁なので、移管前に移管元・移管先の両方の公式ページで金額を確認すること。「登録が安いが更新が高い」パターンは今も普通にある。長期運用する個人開発サイトなら、比較対象として更新料の安定した事業者を1つ持っておくと判断が早い。国内でサポート込みで選ぶなら
あたりが候補になる。
移管できない条件を先に潰す
着手前にこれを確認しないと、申請してから弾かれて数日溶ける。
- 新規登録から60日以内は移管できない(ICANNのルール。gTLD共通)
- 前回の移管完了から60日以内も同様に不可
- Whois登録者情報を変更した直後も60日ロックがかかることがある(事業者によってオプトアウト可否が違う)
- 有効期限が近すぎるとNG。移管には申請から完了まで5〜7日程度かかるうえ、事業者によっては「期限のN日前を過ぎたら申請不可」という独自の締切を設けている。俗に63日ルールなどと呼ばれるが、この日数はレジストラごとに定義が違うので鵜呑みにしない。
- ドメインステータスが
clientTransferProhibitedのままだと不可。移管元の管理画面でロック解除が必要。
実務的な結論としては、有効期限の2〜3か月前に着手するのが安全マージンになる。期限ギリギリで動くと、失効 → 復旧料金(RGP期間の再有効化は高額になりがち)という最悪コースに乗る。
時系列チェックリスト
| タイミング | やること |
|---|---|
| T-14日 | 現行DNSレコードを全件エクスポート。移管元のロック状態とWhois連絡先メールが受信可能か確認 |
| T-10日 | 移管先アカウント開設。先にDNSゾーンだけ作成し、レコードを1:1で再現 |
| T-7日 | 現行レコードのTTLを300秒に短縮しておく |
| T-5日 | NSを新DNSへ切替。dig で新旧の応答一致を確認し、48時間放置して様子を見る |
| T-3日 | メール・サブドメイン・SSL証明書の自動更新が正常か確認 |
| T-0日 | 移管元でロック解除 → **AuthCode(認証コード / EPPコード)**を取得 → 移管先で申請 |
| T+0〜1日 | 移管元に届く承認メールを承認(放置でも5日程度で自動承認されるが、待つ理由はない) |
| T+5〜7日 | 移管完了。有効期限の延長を確認し、Whois情報と自動更新設定を再設定 |
AuthCodeは有効期限付き(発行から数日程度)のことが多い。取得したらその日のうちに申請まで済ませる。
ダウンタイムを出さないDNS作業
移管前に、現行レコードを機械的に吸い出しておく。管理画面の目視コピーは必ず漏れる。
# 主要レコードを一括で控える
for t in A AAAA CNAME MX TXT NS CAA SRV; do
echo "=== $t"
dig +noall +answer example.com $t
done
# サブドメイン・認証系は個別に忘れやすい
dig +noall +answer www.example.com CNAME
dig +noall +answer _dmarc.example.com TXT
dig +noall +answer _acme-challenge.example.com TXT
特に落としやすいのが以下。
- SPF / DKIM / DMARC の TXT(メールが静かに迷惑メール行きになる)
- 各種サービスのドメイン所有権確認用 TXT
- CAAレコード(証明書の自動更新が失敗する)
- ワイルドカードや、開発用サブドメインのCNAME
NS切替後の検証は、キャッシュ越しではなく権威サーバーに直接聞く。
# 新旧の権威サーバーが同じ答えを返すか照合
for ns in ns1.new-dns.example ns1.old-dns.example; do
echo "--- $ns"
dig @$ns example.com A +short
dig @$ns example.com MX +short
done
# ステータスと有効期限の確認
whois example.com | grep -iE 'registrar|expiry|status'
ホスティング側の設定も合わせて見直すこと。Cloudflare Pagesのように外部レジストラのままCNAMEやNSで繋ぐ構成なら、Cloudflare Pages カスタムドメイン設定手順【外部レジストラ対応】の流れがそのまま使える。
正直に言うデメリット・注意点
- 移管中はWhois情報の変更やNS変更が制限されることがある。急ぎの変更予定があるなら移管を後ろにずらす。
- 移管元で購入したオプション(無料SSL・メール転送・DNSホスティング)は引き継がれない。無料メール転送に依存していると、移管日にメールが止まる。事前に代替を用意する。
- 自動更新設定は移管先で入り直し。ここを忘れて失効させる事故が一番多い。
- SEOへの影響は基本ない。URLが変わらないためだ。ただしDNS設定ミスで長時間503/名前解決不能が続けばクロールに影響する。移管後はAstroでやるべきSEO対策まとめで触れているようなsitemap配信やcanonicalが生きているかも軽く確認しておくといい。
DNSまわりで毎回検索し直しているなら、一度体系的に押さえたほうが結局早い。

まとめ
- NS切替を先、レジストラ移管を後に分ける
- 60日ロックと有効期限の締切を着手前に確認する(日数は事業者の公式情報を確認)
- レコードは
digで機械的に控え、TXT・CAA・MXを最優先で照合する - 移管完了後、自動更新とWhois連絡先を必ず再設定する
手続き自体は30分で終わる。時間がかかるのは待ち時間だけなので、余裕を持って着手すれば個人開発サイトの引っ越しは無停止で完了できる。