ホスティングの更新・移行前に確認すべきこと

ホスティングを更新、移行する前に、3つをそろえてください。次の契約期間に実際に払う総額、サイトが依存するものの一覧、復元できることを確認した手順です。初回限定の月額表示や、検証していない速度の評判より、判断に役立ちます。

契約更新は、利用状況を見直すよい機会です。ただし、それだけで移行すべきとは限りません。比較には、使い続ける費用だけでなく、事業者を変える作業とリスクも含めます。

実際に契約する期間の料金を確認する

正確なプランと請求期間について、更新時の金額を確認してください。広告に載る月額換算と、前払いする合計金額を区別します。通貨、適用される税金、更新日、解約期限、自動更新の設定を記録します。

ドメイン、メール、バックアップ、ストレージ、移行支援、セキュリティサービス、有料ソフトウェアのライセンスなど、別料金になるものを列挙します。初回の付属サービスのうち何が終了し、バックアップの復元にいくらかかるかを尋ねてください。プラン名に含まれる機能でも、制限や追加料金がある場合があります。

各社を同じ作業量、同じ期間で比較します。一方を3年間のキャンペーン料金、もう一方を1年間の更新料金で比べるなら、その違いを明示してください。条件が曖昧な場合は、金額を判断の前提にする前に、書面で回答を得ます。

自分の移行作業の時間も費用です。新旧アカウントの重複契約、専門家の支援、メールや公開ツールの再設定も含みます。小さな節約にも価値はありますが、これらを含めた計算でも意味があるかを確認します。

このチェックリストは、事業者の順位付けや速度テストを示すものではありません。公開されている料金は変わります。判断に使うべき価格は、その時点で自分のプラン、地域、更新条件に適用される価格です。

制限を、自サイトの作業に置き換える

何がリソースを使っているかを特定します。記事ページ、画像配信、検索、定期処理、バックアップ、インポート、ニュースレター、管理作業などです。ほぼ静的な媒体と、訪問ごとにページを生成しデータベースを照会するCMSでは、要件が異なります。

ストレージ、通信量、CPU、メモリ、同時プロセス数、ファイル数の上限を、事業者がどう定義し、適用するかを尋ねます。上限に達したときに起きることも確認してください。警告、追加請求、速度制限、サービス停止などです。通信量の枠が大きくても、ほかの制約がなくなるとは限りません。

サイトに必要なソフトウェアのバージョンと、事業者が対応バージョンや更新をどう扱うかを確認します。制作会社や開発者がアプリケーションを管理している場合は、ホスティング側の宣伝上の分類に頼らず、互換性を確認してもらってください。

サポートの境界も定めます。公開失敗の調査、データベースの復元、プラグインの競合解消、営業時間外の対応は誰が行いますか。応答についての約束と、問い合わせに返答することと障害を解決することの違いを確認します。

過去に実際の障害があれば、それを使ってください。起きた問題を説明し、そのプランでどこまで対応するかを尋ねます。架空のテスト障害を作ったり、測っていない応答時間を実績として示したりしてはいけません。

復元と管理権限を確かめる

バックアップは、サイトに必要なものが含まれ、誰かが復元できて初めて役立ちます。WordPressの公式バックアップガイドは、データベースとファイルを区別しています。通常、完全な復旧には両方が必要です。

どのプラットフォームでも、復元に必要な要素を一覧にします。コンテンツ、メディア、アプリケーションやビルド用ファイル、設定、リダイレクト、別のデータベースなどです。安全に復旧する必要がある秘密情報も特定しますが、一般公開のダウンロード用アーカイブに入れてはいけません。

最近のバックアップを非公開のテスト環境に復元してください。新しい記事、画像を含む古い記事、サイトに必要な操作を確認します。バックアップの日付、復元したもの、欠けていたものを記録します。バックアップ処理の成功メッセージを見るだけでは、これらは分かりません。

アカウントの所有権も確認します。適切な人が、ドメイン登録、DNS、ホスティングの請求、アカウント復旧の連絡先を管理する必要があります。外注先が離れても、組織や所有者がアクセスできるようにしてください。サービスが対応している場合は、別々のアカウントと適切な権限を使います。

サイト保守の手順では、これらを継続的な作業にします。次の更新時になって初めて、バックアップの場所を探す事態を防げます。

DNSを変える前に移行計画をつくる

ドメインにひも付くサービスをすべて一覧にします。ウェブホスティングとメールは同じ事業者の場合も別々の場合もあるため、置き換える前に関連するレコードを特定してください。現在のDNS設定を保存し、誰が変更と確認を行うかを合意します。

まずコピーを移し、非公開でテストします。URL、リダイレクト、画像、フォーム、ログイン、定期処理、公開工程を比較してください。CMSでは、最初のコピー後に書き込まれたデータも考慮します。そうしないと、新たに公開した記事やフォーム送信が移行先に残らない場合があります。

WordPressの移行ハンドブックは、正しい手順が、URLの変更を含めて何を移すかによって変わると説明しています。サーバー移転とドメイン変更は別の作業です。別の理由と計画がないまま、ホスティング移行にURL構造の変更まで加えないでください。

切り替え時間帯、最終同期、確認手順、元に戻す判断条件を定めます。新環境を受け入れられるか決める担当者を1人割り当ててください。「誰かが問題に気付くだろう」という期待に頼らないことが大切です。

依存関係を確認してから解約する

切り替え後は、通常の読者と編集者の経路で本番サイトを確認します。想定した移動先、安全な接続、影響する場合のメール、旧環境に依存する外部サービスを確認してください。ホームを表示するだけでは見逃す障害がないか、ログや監視結果も見ます。

合意した重複利用期間と復旧期間は、旧サービスを維持します。適切な長さは構成と事業上の必要性によるため、共通の解約日はありません。アカウントを閉じる前に、必要なデータを書き出し、独立したバックアップにアクセスできることを確認します。

移行後にアクセス数が減った場合は、順序立てた調査を行い、アクセス可否、計測、URLの変更から確認してください。すぐに新しいホスティングの検索性能のせいにしてはいけません。

最後に、各アカウントの管理者、復旧用資料の保管場所、変更内容、次の更新日を簡潔に引き継ぎます。ホスティングの判断は、責任を持つ人がサイトを運用し、復旧できる状態になって完了します。