サーバー移転は、ファイルを新しい場所へコピーする作業だけではありません。Web・メール・DNS・証明書の管理先を整理し、利用者の向き先を旧環境から新環境へ切り替えるプロジェクトです。作業順より先に、何を移し、何を現在の管理先へ残すかを確定します。

現在の契約から移転範囲を切り出す

最初に、現在のサーバーが提供しているものを洗い出します。Webサイトだけでなく、メール・DNS・バックアップ・SSL・定期処理が同じ契約に含まれている場合があります。サーバーを解約した後に消える機能を特定し、新しいサーバーへ移すものと外部サービスへ残すものを分けます。

ドメインの登録先とDNSの管理先も別々に確認します。制作会社の管理画面から操作できても、契約名義が自社とは限りません。移転先の準備より前に、現在のサーバー・ドメイン・DNSへ継続してログインできる状態を作ります。この時点でメールの管理先が別なら、Web移転の対象から外してDNSレコードを維持します。

新旧環境を並行して動かす工程を作る

移転期間中は、新しい契約を開始しても旧サーバーを解約しません。新環境へデータを置き、限定した端末から動作確認した後に公開先を切り替えます。問題があれば旧環境へ戻せるよう、切り替え前のDNS設定とデータを保存します。併用費は無駄ではなく、戻れる時間を確保する費用です。

工程表には担当と完了条件を置きます。「データ移行」ではなく、誰が何を確認すれば完了かを書きます。

フォームなら送信者と受信者の両方、予約なら登録と通知まで確認します。サイトの更新が続く場合は、最終コピーの時刻と公開担当への停止依頼も決めます。新旧へ更新が分かれる期間を短くします。

DNSを変える前に新環境の合否を出す

新サーバーでは、実際のドメインを使う前提で表示と機能を確認します。サーバーが提供する確認URLだけでは、HTTPSやドメイン依存の設定を再現できないことがあります。hosts設定や事業者の検証機能を使う場合は、確認端末だけが新環境へ向いていることを記録します。確認後に設定を戻す担当も決めます。

合否には、主要ページ・管理画面・フォーム・画像・リダイレクト・定期処理を含めます。WordPressならファイルとデータベースが同じ時点かを確認します。メールを移す場合は別の切り替え計画を用意します。SSL証明書をDNS切り替え後にしか発行できないサービスでは、その条件を工程へ入れ、警告を出さない代替手順を事業者へ確認します。

DNS切り替えは変更点を最小にする

Webだけを移すなら、メールのMXや送信認証を不用意に変えません。ネームサーバーごと変更する場合は、現在のDNSレコードを新しい管理先へ再現してから委任を切り替えます。AやAAAAだけを変える場合も、wwwなど関連する名前を確認します。どの方式を使うかは現在のDNS管理と移転先の案内に合わせます。

TTLを短くすると古い情報がキャッシュされる時間を減らせますが、変更前のTTLが残っている間は直ちに効きません。固定の反映時間を前提にせず、複数の接続元から新旧どちらへ到達するかを確認します。切り替え時刻・変更前後の値・実施者を記録し、問題時に戻す値をすぐ使える状態にします。

切り替え後は利用者の結果まで確認する

DNSが新しい値を返しただけでは移転完了ではありません。社外回線から主要URLを開き、証明書とリダイレクトを確認します。

フォームやログインは実際に操作し、通知メールや保存データまで追います。監視サービスの通知先も新環境を見ているか確認します。管理者だけの表示確認で業務処理を代用しません。

旧サーバーのアクセスと更新も一定期間確認します。古い向き先へ利用者が到達している間に投稿や注文が入る構成なら、差分を新環境へ反映する方法が必要です。エラーログと問い合わせを見ながら完了条件を満たしたか判定します。問題があれば、原因と業務影響からDNSを戻すか新環境で直すかを決めます。

旧契約は回収と記録を終えてから止める

旧サーバーを解約する前に、最終バックアップと設定記録を取得します。請求データや過去メールなど、Web以外の保存物が残っていないかも確認します。新環境で一定期間の業務確認を終え、旧環境へ接続する必要がなくなった時点で解約します。日数は固定せず、サイトの利用周期と契約期限から決めます。

最後に台帳のサーバー名・契約名義・DNS・連絡先を更新し、旧アカウントを無効にします。移転作業者だけが新しい認証情報を持つ状態を残しません。バックアップから復元する手順と次回更新日も記録します。移転の完了は新サイトが表示された瞬間ではなく、旧環境なしで運用と復旧を続けられる状態になったときです。