リニューアルでサーバー・ドメインを移転するときの注意点｜メールを止めないDNS切替、ドメイン移管の60日ロック、SSL・GDPRと当日の手順（2026年）

リニューアルの打ち合わせはデザインと CMS の話から始まりますが、公開日に実際に止まるのは、たいていメールと SSL 証明書です。切り替えたら社内にメールが届かない、翌朝ブラウザが警告を出している、という相談は珍しくありません。

原因は、ドメイン・DNS・メール・サーバーという「サイトの土台」の引っ越しにあります。4つは別々の会社と契約していることが多く、1つの設定を写し忘れるだけで止まります。

この記事では、サーバーやドメインを移すときに何を・どの順番で・いつまでにやるかを、一次情報で整理します。URL が変わるときのリダイレクトは「検索順位を落とさないリニューアル」、CMS を乗り換えるかどうかは「WordPressから移行するか続けるかの判断基準」で扱っているので、ここでは URL と CMS 以外の土台に絞ります。

この記事が主に根拠にした情報：ICANN の移管・失効の規則、SIDN と JPRS の規則、Google Search Central、RFC 7208・6376・9989、Google・Yahoo・Microsoft の送信者要件、CA/Browser Forum、欧州委員会とオランダ個人情報保護局の案内。

この記事で分かること	答えの要点
何が止まりやすいか	メール（MX・SPF・DKIM）と SSL 証明書（第1章・第8章・第9章）
ドメイン移管の制約	gTLD は60日ロック、.nl はトークン、.jp は35日有効の認証コード（第3章・第4章）
TTL はいつ下げるか	切替の1週間前。Google は「少なくとも1週間前」と案内（第6章）
GDPR で確かめること	処理契約、サブプロセッサー、バックアップの所在（第10章）
旧サーバーの解約	切替から30日以降、ログでアクセスが消えてから（第13章）

1. リニューアルで「引っ越すもの」は4つある

サイトの土台は別々の契約でできている

ホームページは、1つの箱に見えて、実際には4つの層でできています。ドメイン（example.com という名前そのもの。登録事業者＝レジストラと契約）、DNS（名前をサーバーの住所に変換する台帳。ネームサーバーを持つ会社と契約）、Web サーバー（ページを返す場所）、メールサーバー（受信箱を持つ場所）です。

4つを1つのホスティング会社がまとめて提供していても、サーバーだけを移すと残りの扱いも変わります。ホスティング会社の DNS を解約すれば、そこに書かれていた MX（メールの宛先）も消えます。

図のとおり、DNS は Web とメールの両方の行き先を持っています。サーバーの移転で最も事故が起きやすいのは、この DNS の層です。

層ごとに「変えるか・変えないか」を決める

最初に、層ごとに変えるか残すかを決めます。次の表は、変える理由と影響の範囲です。

層	変える主な理由	変えると影響が出るもの
ドメイン	社名変更、.jp から .com や .nl へ	検索評価、名刺・印刷物、メールアドレス
登録事業者	料金、管理画面、名義の整理	移管中の設定変更の制限
DNS	ホスティングの解約、管理の一元化	Web・メール・認証のすべて
Web サーバー	速度、PHP の版、EU 内へのデータ移転	サイトの表示、フォーム送信、SSL
メール	Microsoft 365 や Google Workspace への統合	受信箱の中身、送信の到達率

ドメインそのものの変更が最も影響が大きく、それ以外は順番を守れば利用者に気づかれずに移せます。

一度に1つだけ変える

Google の URL を伴うサイト移転のガイドも、移転を段階に分けて準備・切替・監視することを前提にしています。土台の移転も同じで、サーバーの移転とドメインの変更とデザインの刷新を同じ日にやらないのが原則です。同じ日に変えると、検索流入やメールの到達率が落ちたときに、どれが原因か切り分けられません。

2. 移転の前の棚卸し：名義・ログイン・レコード

ドメインの名義は誰になっているか

最初に確かめるのは、ドメインの登録者（registrant）が誰になっているかです。前の制作会社や担当者の個人名で登録されていると、移管にも更新にもその人の承認が要ります。SIDN は、登録者が制作会社やレジストラになっているなら、自社の名前に変えるよう案内しています。移管できるのは登録者だけだからです。

WHOIS では GDPR 以降、個人の登録者名が伏せられていることが多いため、登録事業者の管理画面で確かめます。

ログインできる人と画面の一覧を作る

登録事業者、DNS、ホスティング、メール、Search Console の5つの管理画面について、ログインできる人と二段階認証の端末の持ち主を書き出します。あわせて有効期限、自動更新、契約の終了日と解約予告期間も控えます。ログインできないものがあれば、日程を組む前に取り戻します。

DNS のレコードを全部書き出す

最も多い事故は、新しい DNS にレコードを写し忘れることです。管理画面の一覧に加え、dig などで実際に返る値と、サブドメイン（autodiscover など）のレコードも控えます。

レコード	役割	写し忘れたときに起きること
A / AAAA	Web サーバーの IP アドレス	サイトが表示されない
CNAME	別名（www、外部サービス）	ニュースレターや予約システムが止まる
MX	メールの受信先	メールが届かない
TXT（SPF）	送信を許可するサーバー	送信したメールが迷惑メールに入る
TXT / CNAME（DKIM）	署名の公開鍵	署名の検証に失敗する
TXT（DMARC）	認証失敗時の扱い	大量送信の要件を満たさなくなる
TXT（所有権確認）	Google・Microsoft などの確認	所有権が外れ、管理画面に入れない
CAA	証明書を発行できる認証局	証明書の発行が拒否される
SRV	Teams などの自動設定	クライアントの自動設定が失敗する

どれも当日か翌日に表に出る不具合です。新しい DNS に入れたら1行ずつ照合します。

メールを送っている仕組みを洗い出す

問い合わせフォームの自動返信、注文確認、ニュースレター、請求書ソフト、予約システムも、ドメインの名前でメールを送っています。それぞれ SPF と DKIM への記載が必要で、1つ漏れるとそのサービスのメールだけが届かなくなります。

3. ドメインの移管：auth code と60日ロック

移管とは何を変えることか

ドメインの移管（transfer）は、登録事業者を変える手続きで、ドメイン名もサイトも変わりません。.com などの gTLD の移管は、ICANN の Transfer Policy で決まっています。

項目	規則（ICANN Transfer Policy）
認証コード（AuthInfo）	移管元はドメインごとに固有のコードを発行する
コードの提供期限	自分で発行できない場合、依頼から5暦日以内
移管元の承認	5暦日以内に拒否がなければ承認とみなす
有効期限への影響	移管すると1年延長（残期間は最長10年）
移管を拒否できる期間	登録から60日以内、前回の移管から60日以内
登録者変更後のロック	事前に拒否しない限り60日間移管できない

表の最後の2行が、リニューアルの日程に影響します。ドメインを新しく取った直後や、名義を会社名に変えた直後は、60日間は別の事業者へ移せないことがあります。

名義の変更と移管の順番

ICANN のポリシーは、登録者の変更（Change of Registrant）をすると、登録事業者が60日間の移管ロックをかけると定めています。登録者が変更前にこのロックを拒否（opt-out）していれば、かかりません。ポリシーには「移管を予定しているなら、登録者を変える前に移管を済ませる」よう勧める記述もあります。

つまり、前の制作会社の名義のドメインを自社名義に変え、さらに別の事業者へ移したい場合は、先に移管、あとで名義変更の順にすると60日待たずに済みます。ただし、名義が他人のままだと移管の承認自体をその人に頼むことになるため、相手との関係によって順番を選びます。

ポリシーの見直しの動き

ICANN では Transfer Policy の見直しが進んでいます。GNSO（gTLD の方針を決める組織）の作業部会は、移管後のロックを30日に短くすること、登録者変更による60日ロックを廃止することなどを含む勧告をまとめ、2025年4月に ICANN 理事会へ送りました。勧告は18か月程度の実装期間を提案しています。2026年10月31日時点で、新しい規則の発効日は公式の文書で確認できませんでした。実際の日数は、移管の前に登録事業者に確かめてください。

移管中に DNS は止まるか

移管ではネームサーバーの設定が引き継がれるのが一般的です。ただし移管元の無料 DNS を使っていると、移管の完了と同時に使えなくなることがあるため、移管の前に DNS を別の場所へ移しておきます。

4. .nl・.jp・.com・.eu の規則の違い

4つのトップレベルドメインを並べる

日欧に向けたサイトでは、.com・.nl・.jp・.eu を並行して持つことがよくあります。

項目	.com（gTLD）	.nl	.jp（汎用JP）	.eu
管理組織	Verisign（ICANN の規則）	SIDN	JPRS	EURid
登録できる人	誰でも	登録事業者経由で誰でも	日本国内に住所がある人・組織	EU・EEA の市民、居住者、組織
移管に使うもの	AuthInfo コード	トークン（移管コード）	認証コード（AuthCode）	移管コード
コードの期限・提供	依頼から5日以内に提供	依頼から5日以内に提供	生成の翌日から35日有効	登録事業者に確認
移管の完了	最長5日程度	条件がそろえば即時	数日程度	登録事業者に確認

同じ「移管」でも、待ち時間とコードの扱いは組織ごとに異なり、.jp と .eu には地域の条件があります。

組織ごとの注意点

.nl は移管元に5日以内のトークン提供義務があり、届かなければ新しい登録事業者から SIDN に連絡できます。DNSSEC（DNS の応答への署名）を使っている場合は、移管先も対応した事業者を選ぶよう SIDN は案内しています。.jp は JPRS の指定事業者を通じて手続きし、指定事業者変更ロックがあれば先に解除します。co.jp は日本で登記した会社が原則1つです。オランダだけで登記した会社が .jp を新しく取るには、日本国内の住所が必要です。.eu は Regulation (EU) 2019/517 にもとづく条件を、登録期間中ずっと満たす必要があります。

5. 更新切れとドメインの失効

更新切れは移転の時期に起きやすい

旧制作会社との契約を終えたら、その会社のカードで払っていた自動更新も止まっていた。更新の通知は辞めた担当者に届いていた。ドメインの更新切れは、リニューアルの前後に起きやすい事故です。失効後に元の登録者だけが取り戻せる猶予の長さは、組織ごとに異なります。

図の期間を過ぎると、同じ名前を第三者が登録できるようになります。廃止したドメインが第三者に取られ、旧サイトへのリンクや旧アドレス宛てのメールが悪用される危険には、JPRS も注意を呼びかけています。

失効の前後で起きること

gTLD の失効は ICANN の Expired Registration Recovery Policy（ERRP）が定めています。.nl と .jp と並べます。

段階	gTLD（ERRP）	.nl（SIDN）	.jp（JPRS）
失効前の通知	約1か月前と約1週間前の2回以上	登録事業者による	登録事業者による
失効直後	5日以内に更新・削除がなければ再通知	—	期限は登録から1年後の月末
サイト・メール	更新できる最後の8日間は DNS を止める	廃止で解決が止まる	廃止で一時凍結
取り戻せる期間	削除後30日（RGP）	隔離期間40日	翌月1日〜20日
取り戻す費用	通常の更新より高いことが多い	登録事業者による	手数料が必要（事業者による）

ERRP の8日間の停止は、登録者に気づかせるための規則です。サイトが突然止まったら、まず有効期限を疑うのが近道です。

更新切れを防ぐ設定

自動更新を有効にして支払いを会社のカードか請求書払いにし、登録者の連絡先を共有アドレス（例：domains@）にし、有効期限の1か月前に確認する担当を決めます。

6. DNS：TTL を先に下げ、ネームサーバーを切り替える

TTL とは何か

TTL（Time To Live）は、DNS の応答をキャッシュが何秒間覚えてよいかを示す値で、RFC 1035 で定められています。TTL が86,400秒（1日）なら、変更後も最長1日は古いサーバーへ案内されます。TTL を短くした変更も元の TTL が過ぎるまで行き渡らないため、1日の TTL を下げたら少なくとも1日待って切り替えます。

Google の案内と実務の値

Google は、URL を変えないサーバー移転の手順で、TTL を「数時間程度の控えめな低い値」に、少なくとも移転の1週間前に下げるよう案内しています。実務では1週間前に300〜3,600秒へ下げ、切替後2〜3日は短いまま様子を見て、安定したら通常の値（3,600〜86,400秒）に戻します。これは規定ではなく実務の目安です。

図の時期は目安で、旧 TTL が長いサイトや、メールボックスの移行に時間がかかるサイトでは前に延ばします。

レコードの切替とネームサーバーの切替は別物

移転には、A レコードの IP だけを書き換える方法と、ネームサーバー自体を変える方法があります。

方法	変えるもの	伝わる速さ	主なリスク
レコードの書き換え	A・AAAA・MX など個別の値	そのレコードの TTL 次第	少ない（変えた行だけ）
ネームサーバーの変更	登録事業者に登録した NS	上位の NS の TTL（.com は2日程度のことも）	写し忘れたレコードが全部消える

ネームサーバーの変更は、親のゾーン（.com や .nl）側の TTL に左右され、自分では短くできません。DNS の会社も変える場合は、先に新しい DNS に全レコードを入れて照合し、そのあとでネームサーバーを変える順にします。Web サーバーの切替は、その後に A レコードの書き換えで行うと、2つの変更を分けられます。

DNSSEC を使っているとき

DNSSEC を有効にしたドメインでネームサーバーを変えるときは、親ゾーンに登録した DS レコード（鍵の指紋）と、新しい DNS の署名鍵を合わせる必要があります。合わないまま切り替えると、DNSSEC を検証するリゾルバーでは名前が引けなくなり、サイトもメールも止まります。

新旧の事業者が鍵の受け渡しに対応していればそれを使い、対応していなければ、切替の前に DS を外して一時的に無効にし、切替後に新しい鍵で有効に戻します。

7. メール：止めないための順番

MX の切替とメールボックスの移行は別の作業

メールの移転は、MX の切替（これから届くメールの行き先）と、メールボックスの移行（過去のメールを写す）の2つです。前者は DNS の1行、後者は容量によって数時間から数日かかります。Microsoft 365 と Google Workspace の IMAP からの移行は、どちらもメールとフォルダが対象で、予定表・連絡先は含みません。

方法	移せるもの	規模の目安	注意点
Microsoft 365 の IMAP 移行	メールとフォルダ	数十〜数百アカウント	予定表・連絡先は別に移す
Microsoft 365 のカットオーバー移行	Exchange のメールボックス一式	最大2,000（推奨150まで）	移行元が Exchange のときだけ
Google Workspace のデータ移行	メールとフォルダ	1回に100アカウントまで	差分の追加取り込みができる

IMAP 移行の規模は目安、それ以外は各社のドキュメントの記載です。

順番：先に移し、MX を切り、差分を取る

1. 新しいメールサービスにアカウントを作り、ドメインの所有権を確認する（TXT レコード）
2. 旧サーバーから過去のメールを移す（初回の移行）
3. MX レコードを新しいサービスに切り替える
4. TTL の時間と少しの余裕を待ち、旧サーバーに届いた分を差分として取り込む
5. 利用者のメールソフトやスマートフォンの設定を新しいサーバーに変える

3と4の間は新旧どちらにも届きうるため、旧サーバーの受信を止めずに差分で拾います。先に旧サーバーを解約すると、その間のメールは失われます。

Web サーバーからの送信を見落とさない

フォームの自動返信は Web サーバーから送られることが多く、移転で送信元の IP が変わります。SPF に新サーバーがないと、自動返信だけが迷惑メールに入ります。Google は全送信者に逆引き（PTR）を求めており共用サーバーでは直せないことがあるため、メールサービスの SMTP 経由で送る方が確実です。

8. SPF・DKIM・DMARC と送信者要件

3つの仕組みの役割

仕組み	規格	確かめること	移転で壊れやすい点
SPF	RFC 7208	送信元の IP がドメインの許可リストにあるか	新サーバーの IP の追加漏れ
DKIM	RFC 6376	メールの署名が公開鍵で検証できるか	公開鍵のレコードの写し忘れ
DMARC	RFC 9989（2026年5月）	SPF・DKIM の結果が From のドメインと揃うか	レポートの宛先が旧アドレスのまま

3つは DNS の TXT（DKIM は CNAME のこともある）に書くため、DNS の移転で一緒に動きます。

SPF の2つの落とし穴

RFC 7208 では、SPF のレコードが2本以上あると評価がエラー（permerror）になります。新しいメールサービスの手順どおりに1本足して2本になる事故がよくあります。もう1つは、DNS の参照（include など）は10回までという上限です。サービスを足し続けると超えるため、移転の機会に使っていない include を外します。

DMARC は2026年5月に標準化された

DMARC は長く情報提供の文書（RFC 7489）でしたが、2026年5月に RFC 9989 として標準化の文書になりました。既存の v=DMARC1 のレコードはそのまま使えます。変更点として、一部だけに方針を当てる pct タグが削除され、組織のドメインを見分ける方法が公開サフィックスのリストから「DNS ツリーウォーク」に変わりました。pct を使っている場合は、新しい規格で無視されることを前提に方針を決め直します。

Google・Yahoo・Microsoft の送信者要件

2024年以降、大手のメールサービスは送信者に認証を求めています。

要件	Gmail（2024年2月〜）	Yahoo	Outlook.com（2025年5月〜）
全送信者	SPF か DKIM、PTR、TLS	SPF か DKIM、PTR	—
大量送信者の基準	1日5,000通超	大量送信者	1日5,000通超
大量送信者の認証	SPF・DKIM・DMARC（p=none 可）	SPF・DKIM・DMARC（p=none 可）	SPF・DKIM・DMARC（p=none 可）
迷惑メール率	0.3%未満（推奨0.1%未満）	0.3%未満	—
配信停止	ワンクリック解除	簡単な解除	—

Microsoft は当初、要件を満たさない大量送信者のメールを迷惑メールフォルダへ送るとしていましたが、2025年4月29日の更新で受信を拒否する方針に変えました。1日5,000通未満の会社でも、3つをそろえておくのが無難です。Google は DKIM の鍵を1,024ビット以上、推奨2,048ビットとしています。

9. SSL 証明書：短くなる有効期間と切替のすき間

有効期間は段階的に短くなっている

ブラウザが信頼する公開の SSL/TLS 証明書の有効期間は、認証局とブラウザの業界団体 CA/Browser Forum の Ballot SC-081 によって、段階的に短くなっています。

発行日	最長の有効期間	ドメイン確認の再利用
2026年3月15日〜	200日	200日
2027年3月15日〜	100日	100日
2029年3月15日〜	47日	10日

無料の Let's Encrypt は、2027年2月10日に標準の証明書を64日、2028年2月16日に45日へ短くすると告知しています。1年ごとに手で証明書を入れ替える運用は、もう続けられません。新しいサーバーが自動更新（ACME）に対応しているかは、サーバー選びの条件に入ります。

切替のすき間で証明書が切れる

Let's Encrypt などでよく使う HTTP-01 という確認方法は、ドメインが新しいサーバーを指すまで発行できず、切替直後に警告が出ることがあります。避けたいなら、TXT レコードで確認する DNS-01 で切替の前に発行しておきます。CAA レコードで認証局を限定している場合は、新しいサーバーの認証局を足しておかないと発行が拒否されます。

10. サーバー選び：EU 内のデータ所在、GDPR、PHP の版

ホスティング会社は「処理者」になる

フォームの内容や注文履歴をサーバーに置くと、ホスティング会社は GDPR の処理者（verwerker）にあたります。オランダ個人情報保護局（AP）の例示でも、サイトをホスティングする事業者は処理者です。GDPR 第28条は処理の内容・期間・目的などを定めた契約を求め、AP は処理契約（verwerkersovereenkomst）がなければ双方が違反になると案内しています。申し込みの前に標準の契約を入手して読みます。

EU の外に置いてもよいか

EU の外に置くこと自体は禁止されていません。十分性認定のある国（日本は2019年）と、EU-US Data Privacy Framework（2023年7月10日認定）に参加する米国企業へは移転できます。それ以外の国では標準契約条項（SCC）などが要ります。

確かめること	見る場所	なぜ必要か
処理契約の有無	利用規約・DPA	GDPR 第28条の義務
データセンターの所在	契約・管理画面	移転の手当てが要るか判断する
サブプロセッサーの一覧	DPA の付属書	CDN・バックアップ・サポートの所在
バックアップの保存先	仕様書	本番が EU 内でも複製が外にあることがある
解約時のデータ削除	規約	旧サーバーに個人データを残さない
障害時の連絡	SLA	72時間以内の漏えい報告に間に合わせる

見落とされやすいのはバックアップとサブプロセッサーです。本番が EU 内でも、複製が別の国にあればその国を前提に判断します。

PHP などの版を確かめる

WordPress や Laravel では、新サーバーの PHP の版が移転の可否を左右します。公式のサポート期間は次のとおりです。

版	通常のサポート	セキュリティ修正
PHP 8.2	2024年12月31日で終了	2026年12月31日まで
PHP 8.3	2025年12月31日で終了	2027年12月31日まで
PHP 8.4	2026年12月31日まで	2028年12月31日まで
PHP 8.5	2027年12月31日まで	2029年12月31日まで

8.1 以前は修正も終わっています。古い版から上げるとプラグインが動かないことがあるため、新サーバーと同じ版のテスト環境で確かめます。8.2 は2か月後に終わるので、移転先では選ばない方が無難です。

11. 切替当日の手順

当日の4段階

当日の作業は、更新の凍結、最終の同期、DNS の切替、確認の4段階に分けます。直前に、旧サーバーのファイルと DB のバックアップを新旧どちらとも違う場所に取っておきます。

図の3に進む前に、元に戻す手順（どのレコードを、どの値に戻すか）を紙か共有の文書に書いておきます。問題が出たときに、その場で考えずに戻せるからです。

時刻ごとの作業表

次の表は作業の例です。日欧の両方に利用者がいれば、両方で利用の少ない時間を選びます。

時刻（例）	作業	確かめること
切替の2時間前	CMS の更新・注文の受付を止める旨を告知	社内の担当者に連絡が届いたか
1時間前	DB とアップロードファイルの最終同期	件数と最新の投稿が一致するか
0分	A（と AAAA）レコードを新サーバーへ	新旧どちらのサーバーにも正しい中身
0分	MX を変える場合は同時か、別の日に	新サービスで受信できるか
30分後	複数の回線・端末で表示を確認	証明書、フォーム、画像、ログイン
2時間後	フォームの送信と自動返信を確認	迷惑メールに入らないか
翌朝	エラーログ、Search Console の確認	5xx・404 が増えていないか

日英のサイトなら両方の言語のフォームを試し、日本の携帯キャリアのアドレスに自動返信が届くかも確かめます。

12. Search Console：アドレス変更ツールを使う場面

サーバーだけの移転では使わない

アドレス変更ツールは、ドメインやサブドメインを変える移転のためのものです。HTTPS 化、www の有無、パスだけの変更、URL を変えないホスティングの変更には使いません。

移転の種類	アドレス変更ツール	主にやること
サーバーだけを移す（URL は同じ）	使わない	TTL、確認ファイルの移し替え、クロールの監視
HTTP から HTTPS へ	使わない	301 リダイレクト、canonical
www の有無を変える	使わない	リダイレクトと canonical
ドメインを変える	使う	301 リダイレクト、両方の所有権の確認
サブドメインを変える	使う（ドメインのプロパティ単位）	同上

URL が変わる移転のリダイレクトの作り方は、「検索順位を落とさないリニューアル」に詳しく書いています。

ドメインを変えるときの条件

新旧両方のプロパティで同じ Google アカウントが所有者である必要があります。送信すると Google は180日間、新サイトのクロールを優先してシグナルを移します。リダイレクトは少なくとも180日、旧ドメインは少なくとも1年残すよう勧められています。

サーバーだけを移すときに見ること

URL を変えない移転では、Googlebot のクロールが移転直後に一時的に減り、数日で戻ると Google は説明しています。新サーバーにも所有権確認のファイルやメタタグを置き、robots.txt やファイアウォールが Googlebot を遮っていないか確かめます。

13. 旧サーバー・旧契約の解約時期

解約は「アクセスが消えてから」

Google は、旧サーバーのログでアクセスがゼロになるまで旧環境を残すよう案内しています。TTL を守らないリゾルバーや、IP を直接指定した古い設定が残ることがあるためです。

契約	解約の目安	先に確かめること
旧 Web サーバー	切替から30日以降	アクセスログ、バックアップの取得、個人データの削除
旧メールサーバー	MX 切替から30日以降	差分の取り込み、受信が止まったか
旧 DNS	ネームサーバー変更から数日以降	新 DNS で全レコードが返るか
旧ドメイン（変える場合）	少なくとも1年は残す	リダイレクトと流入
旧登録事業者（移管した場合）	移管完了後	自動更新の課金が止まったか

「30日」は実務の目安です。ホスティング契約には解約予告期間があるため、申し込みの期限から逆算して切替日を決めます。

解約の前に個人データを消す

旧サーバーには問い合わせや注文の個人データが残っています。処理契約は終了時の削除か返却を定めるので、解約の前に削除を依頼し、確認をもらいます。

14. 費用と工数の幅

規模別の目安

サーバー・ドメインの移転作業だけを切り出した公的な相場はありません。以下は制作の現場での整理にもとづく目安で、統計ではありません。オランダの時間単価の調査（フリーランスのWeb開発者€73、制作会社の平均€106、BTW 抜き）を掛け、1ユーロ＝175.97円（欧州中央銀行の2026年10月22日の参照レート）で換算しました。単価の出典は「リニューアルの費用相場と見積もりの読み方」にあります。

規模	工数の目安	ユーロ換算	円換算の目安
サイトのみ、メールは移さない	4〜10時間	€292〜€1,060	約5万〜19万円
サイトとメール10アカウントまで	10〜24時間	€730〜€2,544	約13万〜45万円
ドメイン変更・多言語・EC を含む	24〜60時間	€1,752〜€6,360	約31万〜112万円

工数には、棚卸し、テスト環境での確認、当日の作業、30日間の監視を含みます。ホスティング・メールサービス・ドメインの利用料は別です。メールボックスの容量が大きい場合や、DNSSEC・独自の送信サービスがある場合は上限に近づきます。

見積もりで確かめること

「サーバー移転一式」とだけある見積もりでは、DNS の棚卸し、メールボックスの移行、SPF・DKIM・DMARC、証明書の発行方法、旧サーバーの解約とデータ削除、切替後の監視の期間が含まれるかを確かめます。

15. よくある失敗例

公開日に起きる失敗

当日か翌日に表に出る失敗は、ほとんどが DNS と証明書の写し忘れです。

失敗	原因	防ぎ方
社内にメールが届かない	ネームサーバーの変更で MX が消えた	新 DNS に全レコードを写して照合
フォームの返信が迷惑メールへ	SPF に新サーバーがない	送信元を洗い出し、SMTP 経由にする
ブラウザが警告を出す	証明書が未発行、CAA の不一致	DNS-01 で事前発行、CAA を確認
一部の人だけ旧サイトが見える	TTL を下げていなかった	1週間前に TTL を下げる
サイトもメールも全部止まる	DNSSEC の DS と鍵の不一致	切替前に DS を外すか鍵を引き継ぐ

表の5つのうち4つは、第2章の棚卸しと第6章の TTL で防げます。

数週間〜1年後に起きる失敗

時間がたってから出る失敗は、ドメインの失効（支払い元が旧制作会社）、名義変更による60日ロック、Search Console の確認用 TXT の写し忘れ、解約予告期間を過ぎた旧サーバーの請求です。どれも作業の「最後の10%」で起きるため、チェックリストを最後まで使い切ることが対策になります。

16. ケースで考える（架空の例）

以下は、よくある状況を組み合わせた架空の例です。実在の会社ではありません。

ケースA：日本の製造業、旧制作会社の名義のドメイン

日本の部品メーカー（30人）の .com は、登録者が10年前の制作会社のままでした。先に自社の選んだ登録事業者へ移管し、その後に名義を変えて60日ロックを避け、サーバーの移転とデザインの公開も3週間ずらしました。

ケースB：オランダの日系サービス会社、メールの統合

デン・ハーグ周辺の日系サービス会社（8人）は、Microsoft 365 への移行とサーバーの移転を同時に考えていました。フォーム・請求書ソフト・ニュースレターも送信しているため、SPF を1本にまとめ、DKIM を各サービスで有効にし、DMARC を p=none で始め、MX の切替は別の週にしました。

ケースC：EU 向けの通販、PHP の版とバックアップ

EU 向けに日本の食品を売る通販（月300件）は、PHP 8.1 から 8.4 のサーバーへ移るにあたり、決済プラグインの対応が不明でした。

ケース	主な論点	選んだ順番	工数の目安
A：製造業	名義と移管	移管→名義変更→サーバー→デザイン	10〜24時間
B：日系サービス	メールの統合	DNS→メール→サーバー	10〜24時間
C：EU 通販	PHP と注文データ	テスト環境→注文停止→切替	24〜60時間

ケースCは同じ版のテスト環境で決済まで通し、受付を1時間止めて最終同期し、30日後に旧サーバーの個人データの削除を依頼しました。

17. 移転前後のチェックリスト

2週間前まで

• ドメインの登録者・有効期限・自動更新・支払い方法を確かめた
• 登録事業者・DNS・ホスティング・メール・Search Console にログインできる
• 旧 DNS の全レコードを書き出した（サブドメイン、TXT、CNAME を含む）
• ドメインの名前でメールを送るサービスを一覧にした
• 新サーバーの処理契約、データの所在、バックアップの保存先を確かめた
• 新サーバーと同じ PHP の版のテスト環境で動作を確かめた

1週間前〜前日

• TTL を短くした（元の TTL の時間以上前に）
• 新 DNS に全レコードを入れ、1行ずつ照合した
• SPF を1本にまとめ、新サーバーを加えた。参照は10回以内
• 証明書を事前に発行したか、発行方法を決めた。CAA を確認した
• DNSSEC の扱い（鍵の引き継ぎか、DS を一時的に外すか）を決めた
• 元に戻す手順を書いた

当日〜30日後

• 更新を止め、最終同期をしてから A・MX を切り替えた
• 複数の回線でページ、フォーム、自動返信、ログインを確かめた
• Search Console の所有権とクロールの状況を確かめた
• 2〜3日後に TTL を戻した
• ログでアクセスが消えたことを確かめてから旧サーバーを解約し、データの削除を依頼した

まとめ

• 土台はドメイン・DNS・メール・サーバーの4層。一度に1つずつ変え、デザインの公開とも日をずらす
• 最初にドメインの名義とログインを自社の手元に戻す。名義変更は gTLD で60日ロックの原因になるので、移管が先
• .nl はトークンで即時、.jp は35日有効の認証コードと国内住所の条件、.eu は EU・EEA の条件がある
• TTL は1週間前に下げ、ネームサーバーを変える前に新 DNS へ全レコードを写して照合する
• MX の切替とメールボックスの移行は別の作業。SPF は1本・参照10回まで、DMARC は2026年5月から RFC 9989
• 証明書の有効期間は200日から100日、47日へ短くなる。自動更新と事前発行を前提にする
• サーバーは処理契約・所在・バックアップで選び、旧サーバーは30日以降、アクセスが消えてからデータを消して解約する

参考にした情報源

ドメイン（ICANN・SIDN・JPRS・EURid）

• Transfer Policy — ICANN：AuthInfo の提供期限
• Transfer Policy Review — GNSO：見直しの勧告と理事会への送付
• Expired Registration Recovery Policy — ICANN：失効前後の通知
• Transferring your domain name — SIDN：トークン
• FAQ — SIDN：登録者を自社名義にする理由
• Undoing the cancellation of a domain name — SIDN：40日の隔離期間
• ドメイン名の管理指定事業者の変更 — JPRS：認証コードの35日の有効期限
• 種類と対象 — JPRS：汎用 JP と co.jp の登録資格
• JPドメイン名のライフサイクル — JPRS：有効期限、一時凍結、登録回復
• ドメイン名の廃止に関する注意 — JPRS：廃止後に第三者に取られる危険
• Who can register a .eu domain name? — EURid：.eu の登録資格

DNS・メールの規格と送信者要件

• RFC 1035: Domain Names — IETF：TTL の定義
• RFC 7208: SPF — IETF：レコードは1本
• RFC 6376: DKIM — IETF：署名の仕組み
• RFC 9989: DMARC — IETF：2026年5月の標準化
• Email sender guidelines — Google Workspace 管理者ヘルプ：全送信者と1日5,000通超の要件
• Sender Best Practices — Yahoo：大量送信者の要件
• Outlook's New Requirements for High-Volume Senders — Microsoft Tech Community：2025年5月からの要件と拒否への変更

メールボックスの移行

• Ways to migrate multiple email accounts to Microsoft 365 — Microsoft Learn：IMAP・カットオーバー・段階的移行
• Cutover migration to Exchange Online — Microsoft Learn：最大2,000、推奨150
• Migrate from IMAP servers to Google Workspace — Google Workspace 管理者ヘルプ：IMAP からの移行の範囲
• Import email from an IMAP account — Google Workspace 管理者ヘルプ：1回100アカウント

SSL 証明書

• Ballot SC081v3 — CA/Browser Forum：200日・100日・47日への短縮
• Decreasing Certificate Lifetimes to 45 Days — Let's Encrypt：64日・45日への移行の日程

Google 検索

• Site moves without URL changes — Google Search Central：TTL を1週間前に下げる
• Site moves with URL changes — Google Search Central：移転の段階
• Change of Address tool — Search Console ヘルプ：使える条件

サーバー・GDPR

• Supported Versions — PHP：各版のサポート期間
• Adequacy decisions — European Commission：十分性認定の国・地域
• EU-US data transfers — European Commission：Data Privacy Framework（2023年7月10日）
• Verwerkers — Autoriteit Persoonsgegevens：処理契約の義務と内容
• Voorbeeldlijst verwerker of verwerkingsverantwoordelijke — Autoriteit Persoonsgegevens：ホスティング事業者は処理者

いずれも2026年10月31日に確認したものです。規則・要件・画面の名称は変わることがあるため、作業の前に最新の文書と、利用している登録事業者・ホスティング会社の案内を確認してください。図1・図3・図4の時期、第6章の TTL の値、第13章の30日、第14章の工数、第16章のケースは DevNJ の整理で、規定や統計にもとづく基準ではありません。