はじめに
ウェブサーバー移行とは
ウェブサーバー移行は、サイトやアプリのデータや設定を別のサーバーに移す作業です。移行中は表示の途切れやメールの受信トラブルが起こる可能性があるため、計画的に進めることが大切です。
本章の目的
本章では、移行で押さえておくべき重要点をわかりやすく整理します。特に「現状の把握」「新サーバー準備」「データ移行とDNS切り替え」の3点を軸に、何を確認し、どの順で進めるかを示します。
重要な3点（概要）
- 現状の把握：現行サーバーのOS、ソフト、データ量、依存関係を確認します。たとえばPHPやデータベースのバージョンやメール設定などです。
- 新サーバー準備：必要なソフトやバージョンをそろえ、テスト環境で動作を確認します。性能（CPU・メモリ）やセキュリティ設定も確認します。
- データ移行とDNS切り替え：データを移し、動作確認後にDNSを切り替えます。DNSの伝搬時間を考慮して、ダウンタイムを最小限にします。
この先の章について
次章で具体的な手順を順を追って説明します。章ごとにチェックリストを用意し、実務で使える形にします。
基本的な移行ステップ
準備（現状把握）
まず現行サーバーの契約内容と仕様を確認します。ディスク容量、OS、ミドルウェア、言語のバージョン、SSLの有無、バックアップの頻度などを一覧にします。ログやアクセス数も把握すると必要なスペックが判断しやすくなります。
新サーバーの選定と契約
要件に合う新サーバーを選びます。例：ディスク容量が足りないなら大容量プラン、PHPやDBのバージョン差があるなら互換性のある環境を選びます。必要ならテスト用のサブアカウントを契約して試します。
環境構築（同等または互換性の確保）
OSやミドルウェアを現行と合わせます。パッケージの設定や権限、タイムゾーンなど細かい設定も揃えます。SSLやメール設定もこの段階で準備します。
バックアップと転送
ファイルは圧縮（例：tar）して安全に保存し、データベースはダンプ（例：mysqldump）で取得します。ファイル転送はrsyncやSCP、FTPを使い、転送後にチェックサムで整合性を確認します。
インポートと動作確認
新サーバーにファイルを配置し、DBをインポートします。設定ファイルのパスや接続情報を更新して、ログインや主要ページを実際に操作して確認します。画像や外部連携も忘れずに検証します。
切り替えとロールバック計画
DNS切替前に最終の差分バックアップを取得します。切替時のリスクに備え、問題発生時は旧サーバーに戻せる手順（ロールバック）を用意します。切替後は監視を強化し、エラーや負荷を早期に検知します。
DNS切り替えとダウンタイム対策
事前準備：TTLを短くする
DNSのTTLを短く設定します。具体的には300秒（5分）程度にすると切り替え時の反映を早められます。切り替え前に十分な時間（少なくともTTLの数倍、例：1〜2時間）を見て変更してください。
切り替え手順（Aレコード変更）
- 新サーバーを準備し、動作確認を済ませます。表示やフォーム送信などをローカルのhostsで確認すると安全です。
- TTL短縮後、Aレコードを新しいIPに変更します。
- DNS反映中は旧サーバーと新サーバーを並行稼働させます。ユーザーに見えるページは新サーバーへ、データ同期は両方で行える状態にしてください。
データ同期と最終バックアップ
データベースやアップロードファイルはリアルタイム同期が理想です。難しい場合は切り替え直前に最終バックアップ（ダンプやrsync）を取り、新サーバーに再インポートして不整合を防ぎます。例えば：
– DB：mysqldump → 新サーバでインポート
– ファイル：rsync –archive –delete
検証項目（切り替え後）
- 表示確認：ページ崩れや画像欠損がないか
- フォーム送信：送信が成功し、管理画面でデータが見えるか
- ログイン：会員ページや管理者ログインが正常か
- メール送受信：MX設定が変わる場合は特に注意
切り替え後の旧サーバー処理
問題がなければ旧サーバーはTTL期間が過ぎたことを確認してから解約します。念のため数時間〜数日程度は並行稼働を続けると安全です。
トラブル時の対処
- 反映遅延：DNSキャッシュを疑い、ブラウザやローカルのDNSキャッシュをクリアして再確認
- メール不達：MXやSPF、SMTP設定を見直す
チェックリスト：TTL変更、最終バックアップ、Aレコード更新、表示/送信/ログイン/メール確認、旧サーバ停止の順で進めてください。
よくある注意点
はじめに
移行作業でよく見落とす点を項目ごとにまとめます。事前にチェックリストを作り、ステージング環境で検証してください。
PHP・DBのバージョン互換性
- CMS（例：WordPress）はPHPやMySQL/MariaDBのバージョンに依存します。事前に要件を確認し、ステージングで動作確認を行います。
- プラグインやテーマが新しいPHPで動作しないことがあるため、主要機能を重点的に試します。
パーマリンク・URL設定
- サイトURL（siteurl/home）や.htaccessの設定が変わるとリンク切れが起きます。内部リンクや画像の絶対パスを置換するツールを使ってください。
- シリアライズされたデータは単純な文字列置換で壊れることがあります。WP-CLIや専用プラグインを使うと安全です。
プラグイン・外部連携
- キャッシュやセキュリティ系は移行前に無効化し、移行後に再設定します。
- 外部APIや有料サービスは接続先のドメイン変更やコールバックURLの更新を事前に確認してください。
ファイルアップロードと権限
- アップロードパスやメディアの相対/絶対パスを確認します。ファイル所有者と権限（一般的にディレクトリ755、ファイル644）を適切に設定してください。
SSLとメール関連
- SSL証明書は再発行や再インストールが必要になる場合があります。混在コンテンツ（HTTP資源）もチェックしてください。
- メールは送信元サーバーが変わるとSPF/DKIM/DMARCの調整が必要です。MX変更の伝播時間を見込んでテストします。
社内対応が難しい場合
- 技術的に不安があるときは移行代行サービスや制作会社に依頼する選択肢を検討してください。費用対効果とリスクを比べて判断します。
自前移行と外部委託の違い
概要
自前で移行する場合は直接費用を抑えられますが、担当者の工数と技術知識が必要になります。外部に委託すると代行費用が発生しますが、担当者の負担を減らせてトラブルを抑えやすくなります。
自前移行のメリット
- コストを直接抑えやすい（業者費用が不要）。
- 社内にノウハウが蓄積する。具体例：担当者がDNSやサーバ設定を学ぶことで次回以降は速くできる。
- スケジュールを柔軟に調整できる。
自前移行のデメリット
- 手順漏れや設定ミスのリスクが高い。例：DNSのTTLを見落として想定外の切替遅延が起きる。
- 担当者の工数増加で本業に支障が出る。
- テスト不足で本番トラブルに繋がりやすい。
外部委託のメリット
- 専門家が作業するためトラブルを避けやすい。
- 担当者の工数を大幅に削減できる。例：事前リハーサルを業者が実施してくれる。
- 障害対応や保証が付く場合がある。
外部委託のデメリット
- 代行費用が発生する。規模によっては高額になる可能性がある。
- ベンダー選定や要件調整に時間がかかる。
- 外注先に依存すると内製能力が育ちにくい。
判断のポイント
- 規模：小規模なら自前でも対応可能。大規模や影響範囲が広ければ外注を検討。
- 期限：短期間で確実に完了させたい場合は外注が有利。
- スキルと工数：社内に十分な技術と余力があれば自前でコスト効率が良い。
ハイブリッド案として、設計とリハーサルを外注に依頼し、本番実行を自前で行う方法も有効です。
もし追加で教えてほしい内容
以下の情報を教えていただければ、より具体的で安全な移行手順書を作成します。
前提に教えていただきたい項目
- 移行元と移行先の環境（例：レンタルサーバーA→VPS、オンプレ→AWSなど）
- 利用中のCMSやアプリ（例：WordPress、Movable Type、自作PHPなど）
- OSとソフトのバージョン（例：Ubuntu 20.04、MySQL 5.7）
- ドメイン管理・DNSの管理者（どこでDNS設定しているか）
- SSLの種類（Let’s Encrypt・商用証明書など）
- メールの扱い（サーバーで管理しているか外部サービスか）
- データ量と想定アクセス数（GBや月間PV）
- バックアップ方法と現在の頻度
- 移行の希望時期と許容ダウンタイム
ご提供いただくと作るもの（例）
- ステップごとの実行手順（コマンドや設定例を含む）
- DNS切替の最適なタイミングとTTL調整案
- データベース移行手順と検証チェックリスト
- ロールバック手順とリスク低減策
- 想定ダウンタイムとテスト方法
補足とお願い
- 設定ファイルや画面キャプチャがあると正確に作れます。
- 特別な制約（稼働時間帯、予算、社内規程）があれば最初に教えてください。
これらの情報をいただければ、実行可能な手順書を作成してお渡しします。まずは移行元と移行先、CMSの有無を教えてください。
