まず確認したい移管・移行のパターン
最初に「どこまで移すか」を整理すると、必要な準備が分かりやすくなります。現在の契約内容があいまいでも、まずは近いパターンを選べば十分です。
A
ドメイン管理のみ
現在のWebとメールはそのまま使い、ドメイン管理だけを移すパターンです。AuthCode や登録情報の確認が中心です。
B
Web・メールをまとめて移行
ドメイン管理に加え、Webサイトとメールも新環境へまとめて切り替えるパターンです。準備項目は最も多くなります。
C
Webのみ移行
メールは現在のまま残し、Webサイトだけ新サーバへ移すパターンです。Web構成と DNS 設定の確認が重要です。
D
メールのみ移行
Webサイトは現状維持で、メールだけ新しい環境へ移すパターンです。アドレス作成とメールソフト設定が中心です。
- 現在のドメイン種別、更新時期、契約会社
- Webサイトの構成が HTML / WordPress / 独自システム のどれか
- 現在使っているメールアドレス数と、メールソフト設定の有無
- 現在の管理会社で DNS（ネームサーバー）をどのように変更するか
- 止めたくない業務時間帯や、希望切り替え時期
1. ドメイン移管で必要なこと
ドメイン移管では、現在の管理会社からミームネットへドメイン管理を移すための情報が必要です。.jp 系でも gTLD でも、まず AuthCode や現在の登録情報を確認する流れになります。
移管元
現在の管理会社側で行うこと
AuthCode の発行、登録情報更新、必要に応じたロック解除や確認対応など、移管元としての手続きを行います。
お客様
お客様にご対応いただくこと
登録者メールの受信確認、現在の契約情報確認、弊社への申込、承認操作をご対応いただきます。
移管先
弊社で進めること
AuthCode や確認情報を受け取り、移管申請の受付、移行準備、完了後の管理を進めます。
1管理会社側: AuthCode 発行・登録情報確認
2お客様: 弊社へ移管申込
3弊社: 移管申請
4お客様: 登録者メールで承認
5結果: 管理先が弊社へ切り替わる
STEP 1
現在の契約を確認
管理会社、対象ドメイン、更新時期、Whois / RDAP の登録情報を確認します。
STEP 2
AuthCode を取得
現在の管理会社へ依頼し、移管申請に使う AuthCode を確認します。
STEP 3
登録者メールを確認
承認メールを受け取れるかを確認し、必要なら事前に更新します。
STEP 4
弊社へ申込
AuthCode と確認情報をもとに、弊社側で移管申請の準備を進めます。
STEP 5
承認して完了
登録者メール宛の案内に従って承認後、管理先が切り替わります。
| 主な確認項目 | 内容 |
|---|
| 対象ドメイン | .jp / .co.jp / .or.jp / .ne.jp / .com / .net / .org など |
|---|
| AuthCode | 移管申請時に必要です。.jp 系でも gTLD でも、現在の管理会社へ発行を依頼して確認します。 |
|---|
| 登録者メール | 現在のレジストラの Whois / RDAP 情報で登録者メールを確認し、必要なら事前更新します。承認メールや確認案内の受信先になる場合があります。 |
|---|
| レジストラロック | gTLD ではロック解除が必要な場合があります。現在の管理会社の設定をご確認ください。 |
|---|
| gTLD 特有の注意 | .com / .net / .org などは、新規取得直後や登録情報変更直後などに移管制限がかかる場合があります。 |
|---|
| .jp 系の確認 | 現在の登録情報、管理会社、更新時期、承認手続きの有無を確認します。 |
|---|
| その他 | Whois 公開代行の状況、更新期限間近かどうか、現在のネームサーバ利用状況、管理会社側で事前解約や特別手続きが必要かも確認します。 |
|---|
AuthCode や現在の管理会社が分からない場合は、ドメイン移管の手続きを進められないことがあります。まずは現在の管理会社の管理画面や案内メールを確認し、AuthCode・登録者メール・ロック状態が確認できる状態にしておくことが重要です。
手続き上の整理ポイント
- ドメイン移管は、ドメインの管理会社を変える手続きです。
- Webやメールの移行は、サーバ側のデータや設定を移す作業です。
- ドメイン移管とサーバ移行は別手続きなので、どちらか片方だけ先に進めることもできます。
参考: JPRS ドメイン名の管理指定事業者の変更（JPドメイン向け） / JPRS レジストラトランスファーに関する方針（gTLD向け）
2. Webサイト移行で必要なこと
Webサイトの移行は、現在の構成によって必要な作業が変わります。どの方式で運用しているかが分かると、移行手順と停止リスクの見積もりがしやすくなります。
HTML
静的HTMLサイト
HTML・CSS・画像ファイル中心のサイトです。ファイル一式を移行し、リンクやフォーム動作を確認します。
CMS
WordPressサイト
ファイルだけでなく、データベース、テーマ、プラグイン、管理画面の動作確認が必要です。
APP
独自サイト・独自システム
PHPや独自プログラム、外部連携、会員機能などの動作確認が必要です。仕様確認をしながら移行します。
現行サイトの構成確認
→
新環境へ複製・検証
→
DNS切り替えで公開
- 移行が完了するまでは、移行元サーバの契約を残したまま重複期間を取ると安全です。
- 現在のサーバにしかないファイルや画像がないかを確認する
- 問い合わせフォームや予約フォームが動くかを確認する
- DNS切り替え前に、新サーバ側で表示確認や動作確認ができるかを確認する
- SSL、リダイレクト、アクセス解析の設定が必要かを確認する
- WordPress の場合は管理画面ログイン情報と利用中プラグインを確認する
3. メールサービス移行の流れ
メール移行では、先に新しい環境でメールアドレスを用意し、その後に各端末やメールソフトの設定を進めます。
アドレス一覧を整理
→
新環境で作成
→
メールソフトを再設定
→
送受信確認
- 移行後に使うメールアドレス一覧を整理する
- 新サーバ側で必要なメールアドレスを作成する
- PC・スマートフォンのメールソフトへ新設定を入れる
- 送受信確認を行い、旧環境に残っているメールの扱いを確認する
- 切り替え前に、現在使っているメールアドレス一覧、転送設定、自動返信、メーリングリストの有無を整理しておくと移行漏れを防ぎやすくなります。
- メールアドレスは DNS 切り替え前でも新環境に先に作成できることが多く、事前に Webメールやテスト端末で送受信確認しておくと安心です。
- メールソフトの設定に必要な情報は、メールアドレス、パスワード、受信方式（POP / IMAP）、受信サーバ、送信サーバをそろえておくとスムーズです。
- 切り替え直後は旧環境と新環境の両方にメールが一時的に届くことがあるため、旧サーバの確認手段も一定期間残しておくと取りこぼしを防ぎやすくなります。
- 必要に応じて、旧メールの保存方針や、どの端末から優先して再設定するかも事前に決めておくと移行が安定します。
メールソフトの設定は、Thunderbird、Outlook、Apple Mail、Gmail アプリなど、利用中のソフトに合わせて順番に進めます。特に利用台数が多い場合は、まず代表端末で送受信確認を行い、その後に他端末へ広げる流れにすると切り分けしやすくなります。必要に応じてメール設定ガイドやサポートをご案内します。
4. DNS 切り替えで起こること
ドメイン移管やサーバ移行では、最終的に DNS の向き先を切り替える場面があります。ここで「どこにアクセスしに行くか」の情報が新しい環境へ切り替わります。
1. DNSとは
ドメイン名と、Webサーバやメールサーバの接続先を結びつける情報です。
2. 切り替え直後
すぐに全員が新サーバを見るわけではなく、しばらく旧新が混在することがあります。
3. 影響しやすいもの
Web表示、メール送受信、SSL設定、外部サービス連携の接続先です。
- DNS変更は自動では行われないため、現在の管理会社側で変更方法を事前に確認しておくとスムーズです。
- Webサイトは、閲覧者によって旧サーバと新サーバの見え方が一時的に混在することがあります。
- メールは MX 設定切り替え後、旧環境に届くものと新環境に届くものが短時間混在することがあります。
- TTL やキャッシュの影響で、完全に切り替わるまで時間差が出ます。
- そのため、切り替え前に新サーバ側の確認を済ませておくことが重要です。
5. 移管・移行のご相談から申込まで
ドメインだけの移管、Webサイト移行、メール移行をまとめて進める場合でも、現状が分かる範囲でご連絡いただければ整理しながら進められます。
- 移したいドメイン名
- 現在の管理会社やサーバ会社
- Webとメールの両方を移したいか、どちらかのみか
- 希望時期や、止めたくない業務時間帯
ドメイン移転を申し込む
事前に相談する
