メールへの影響を抑えてウェブサイトを移行する

ウェブとメールの管理範囲を分けて記録する

名古屋の設計事務所が、メールの契約先を変えずにウェブサイトだけを移す場面を想定します。ドメイン管理、権威DNS、ウェブ、メール、フォーム送信の担当を個別に記録してください。必要な管理画面へ実際にアクセスできるかを確認し、作業中に判断できる責任者を決めます。外部の予約画面やサブドメインも一覧に含めましょう。

現在のMX、SPF、DKIM、DMARCは値を変えずに保存します。ウェブ用の名前とメールの宛先を区別し、両方が同じ名前に依存していないか点検してください。新しい管理画面に表示される例を、そのまま既存の値に置き換えないことが大切です。記録には値だけでなく、使うサービスと変更権限のある担当も添えます。

作業担当が変わっても分かるように、管理先と連絡方法を一覧にまとめます。公開サイトの担当だけではメール側の変更を判断できない場合があります。事前に担当者同士で作業範囲を確認し、問題が出た際に誰へ連絡するかを決めておきましょう。

公開前にアプリケーションを復元する

必要なファイル、データベース、設定を保存し、隔離した検証環境へ復元します。ページ、ログイン、添付資料、フォーム処理を確認してください。試験から顧客に通知が送られないように配慮します。代表的な文書とデータを元環境と比較すれば、トップページが開くことと、内容が完全に引き継がれたことを区別できます。

移行中に追加された情報の扱いも決めます。更新の少ない紹介サイトなら編集時間を調整できる場合がありますが、問い合わせを受け続けるシステムでは取り込み方法が必要です。最後のデータ取得時刻、確認担当、次の段階へ進む条件を記録しましょう。検証環境で問題が残っている状態では、公開先の変更を急がないようにします。

既存の問い合わせ一覧と添付資料を対応させて点検すると、データだけ戻ってファイルが欠ける状態を発見しやすくなります。確認する件数と選び方を事前に決め、誰が結果を承認したか残してください。試験結果は移行後の照合にも使える形で保管します。

DNSの変更を必要な項目に限定する

TTLの調整が必要なら事前に計画し、以前の値がキャッシュに残る時間を考慮します。新しいサイトが準備できてから、対象となるウェブ用A、AAAA、CNAMEだけを切り替えます。従来IPv6を使っていた場合も確認し、メール関連の値は維持してください。変更前の値と変更後の値を並べた作業表を用意します。

ネームサーバーの変更が必要なら、ゾーン全体の引き継ぎを独立した作業として点検します。サイト移行のついでに扱うと、別サービスの設定が抜けることがあります。戻す際の値も作業前に保存し、変更対象の名前にメールが依存している場合は、その影響を解決してから進めてください。各変更がどの機能に対応するかを確認します。

切り替え作業では開始時刻と実施者を記録し、確認が済むまでは別の担当による設定変更を控えます。複数の変更が重なると原因を追いにくくなるためです。作業表を共有しておけば、どの時点の設定を調べるべきかを関係者がそろえて判断できます。

送受信と旧環境への戻し方を確認する

切り替え後は独立した外部の試験用メールボックスを使い、受信と送信を確認します。ウェブフォームからの通知も別に試してください。メールヘッダーで送信経路や認証結果を確認し、予定外の経路になっていないか調べます。ブラウザーの送信完了表示だけでは、目的の受信箱に届いたことまで確認できません。

旧ウェブ環境は、合意した切り戻し期間中に利用できる状態で残します。戻す判断をする担当と、新環境で増えたデータの保存方法を決めておきましょう。DNSだけを元へ戻しても、二つの環境の情報が食い違う場合があります。旧契約を終了する前には、必要なメール処理や別の機能が残っていないかも確かめます。

戻す条件は、例えば重要な画面が利用できない場合など、業務への影響から決めます。担当者が迷わず判断できるよう、確認手順と連絡先を同じ資料にまとめてください。再度切り替える場合には、最初の失敗原因を確認してから新しい計画を作ります。

注文確認と作業完了の記録を残す

移行日を決める前に、ドメインの管理権限、移行先プランの提供可否、提供元が確認した注文をそろえます。Hightideの表示価格はUSDで、支払いはUSDTとUSDCのみです。注文を送ったことと、環境が利用可能になったことは別に確認してください。公開先の変更は、実際の準備が確認できてから計画します。

完了後は変更履歴、復元の確認結果、送受信の記録を保管します。未解決事項と次の点検日を担当者へ共有しましょう。準備によって防げる問題は減らせますが、遅延や中断の可能性も想定した運用が必要です。