公開後のホームページ運用
全面停止を避けたいサーバー・システム移行で、更新や申込みをどう一時停止するか
サーバー移行でもシステム移行でも、「サイトを丸ごと止めるしかない」と感じることがあります。しかし、すでに受け付けた予約や注文の確認まで止める必要があるとは限りません。大切なのは、移行中に新しいデータが旧環境と新環境へ分かれて残らないように、更新や申込みの操作だけを必要な期間止め、閲覧や最低限の利用をどう維持できるかを先に計画することです。
HOW TO PLAN
ここから、全面停止を避けながらデータを守るための考え方を順に見ていきます。01
最初に考えるのは、「サイトを止めるか」ではありません
移行で避けたいのは、サイトが一時的に表示されないことだけではありません。移行元と移行先の両方へアクセスが届く間に、申込みや更新が別々のデータベースへ記録されると、どちらが正しいか後から判断しにくくなります。
まずは、移行中に作成・変更されると困る情報を洗い出します。予約、注文、会員・顧客情報、問い合わせ、在庫、見積り、CMSのお知らせなど、重要な情報は事業によって異なります。
書込みを止める期間は、データ移行の開始から切替までだけではありません。告知、開始待ち、切替後の確認までを一つの流れとして計画します。
-
01 事前告知
止める操作を知らせる
利用者・運営者へ、止まる操作と継続する閲覧機能を案内します。 -
02 一時停止
更新や申込みを止める
旧新の環境にデータが分かれないよう、書込みを受け付けない状態にします。 -
03 データ移行・切替
待機時間も含めて進める
データ移行の開始待ち、移行作業、切替の間も、停止状態を維持します。 -
04 保護期間
新環境への到達を待つ
切替後もアクセス先が混在し得る間は、書込みを再開しません。 -
05 最終確認
データと機能を比べる
件数・最新情報・表示・メール・ログを確認し、再開を判断します。 -
06 再開・監視
新環境だけで再開する
一時停止した操作を確認し、短期間の監視を経て完了します。
実際の期間と確認項目は、移行サービスの仕様、扱うデータ、外部連携の有無によって変わります。
02
維持する機能と、一時停止する操作を分けます
全面停止を避ける場合でも、すべてを通常どおり使えるわけではありません。データを増減させる操作は一時停止し、確定済みの内容を確認するための閲覧機能は維持できる場合があります。
どこまで分けられるかは、サイトやシステムの作り、外部連携によります。実装前に、利用者側、管理者側、フォームやAPI、メール、定期処理まで確認します。
| 扱い | 例 | 確認したいこと |
|---|---|---|
| 維持を検討する | 一般ページ、商品・サービスの案内、確定済みの予約や注文の照会、発行済み書類の閲覧 | データを変更せずに表示できるか。閲覧のための認証やPDF表示は新環境でも動くか。 |
| 一時停止を検討する | 新規申込み、予約・注文の変更やキャンセル、会員登録・情報変更、領収書や帳票の発行、管理画面の公開・編集 | 旧新どちらの環境へ記録されても、あとから差分を解消できるか。解消できないなら停止する。 |
| 個別に確認する | 問い合わせフォーム、決済、メール配信、外部サービス連携、定期処理、Webhook | 画面に見えなくてもデータや通知を動かす経路がないか。停止方法と再開後の確認方法を決める。 |
維持を検討する
例
一般ページ、商品・サービスの案内、確定済みの予約や注文の照会、発行済み書類の閲覧確認したいこと
データを変更せずに表示できるか。閲覧のための認証やPDF表示は新環境でも動くか。一時停止を検討する
例
新規申込み、予約・注文の変更やキャンセル、会員登録・情報変更、領収書や帳票の発行、管理画面の公開・編集確認したいこと
旧新どちらの環境へ記録されても、あとから差分を解消できるか。解消できないなら停止する。個別に確認する
例
問い合わせフォーム、決済、メール配信、外部サービス連携、定期処理、Webhook確認したいこと
画面に見えなくてもデータや通知を動かす経路がないか。停止方法と再開後の確認方法を決める。「閲覧できるか」と「データを書き換えないか」は別の確認です。画面上のボタンを隠すだけではなく、サーバー側でも更新を受け付けない状態にできるかを確かめます。
03
停止の告知は、移行直前ではなく前もって行います
一時停止が必要な機能を急に使えなくすると、利用者やスタッフの業務に影響します。止める操作、閲覧や確認ができる範囲、再開の見込みを前もって案内します。
案内では「メンテナンス中です」だけで済ませず、利用できない操作と、通常どおり確認できる内容を分けて伝えます。急ぎの連絡が必要なときの窓口も決めておくと、問い合わせへの対応を一か所に集めやすくなります。
- 利用者向け: 停止する操作、継続して見られる情報、問い合わせ方法
- 運営者・スタッフ向け: 管理画面で変更しない範囲、緊急時の連絡先、再開の判断者
- 関係者向け: メールや外部連携に設定変更が必要になる可能性と、確認する時期
04
移行作業には、処理時間だけでなく待機時間があります
移行サービスや運用体制によっては、申請や依頼の直後にデータ移行が始まるとは限りません。開始待ち、データ移行、確認、切替、古い環境への到達が残る期間があります。
データ移行にかかる時間だけを見積もると、停止や告知の期間が足りなくなることがあります。開始を待つ間に通常運用を続けるか、いつから更新を止めるかは、移行の仕様とデータの性質に合わせて決めます。
05
再開する条件は、移行前に決めておきます
データ移行と切替が終わっただけでは、すぐに更新を再開できるとは限りません。旧環境へ届くアクセスが残る場合、そこで登録された情報は新環境へ自動で反映されないことがあります。
再開前に、移行前に記録した件数や最新情報を移行先と比べます。表示、ログイン、メール、主要な閲覧機能も確認します。必要なら、移行元と移行先の両方で更新を受け付けない期間を延ばします。
06
変更は一度に重ねず、戻れる単位で進めます
移行のタイミングで、PHP、WordPress、プラグインの更新や、テーマ改修、CMSの入れ替えまで同時に進めたくなるかもしれません。しかし問題が起きたとき、どの変更が原因か分からなくなり、切戻しも難しくなります。
まずは移行前に近い条件で新しい環境へ切り替え、安定を確認します。その後、PHPや依存ライブラリの更新、機能の改善、構成の見直しを段階的に進めると、影響の範囲を確かめやすくなります。
WordPressを使い続けるか、公開サイトと編集・業務機能を分けるかも、流行や技術名だけでは決まりません。更新する人、扱う情報、停止できる時間、復旧時に誰が判断するかを並べて考えることが出発点になります。
07
移行は、今の運用を見直す機会にもなります
移行の準備では、サーバー、ドメイン、DNS、SSL、メール、バックアップ、管理者権限、外部連携などを確認します。システム移行では、データ、権限、外部連携、バックアップや復元の手順も確認します。こうした情報を整理すると、障害時の連絡先や、担当が変わったときに引き継ぐべきことも見えます。
作り直すかどうかを急いで決める必要はありません。安定して運用できているなら保守を強化する、公開サイトだけを分ける、一部の業務機能だけを作り直すなど、状況に合わせた選択肢があります。
今のサイトや仕組みを残す・整える・移すのどれから考えるべきか迷うときは、既存サイトの診断・移行設計について相談することから始められます。