クライアントのためにWordPressサイトを管理するには、日常的に手をかけなくても安定して運用できるサーバー環境が欠かせません。しかしサイトのダウンやDNSレコードの不具合、データ消失といったリスクを懸念して、本来必要なインフラの切り替えになかなか踏み切れないという場合もあります。
Kinstaのサイト移行部門は、トラフィックの多い単一サイトから、制作会社が管理するクライアントサイト全体まで、日々さまざまなサイトを移行しています。今回は、サーバー切り替えに関する誤解を取り上げつつ、Kinstaのサイト移行サービスについてもご紹介します。
懸念1. サーバーを移行するとサイトが数時間〜数日オフラインになる
まず、「別のサーバーに移行すると、ファイルの転送とDNSの伝播の間は、サイトをオフラインにしなければならない。結果として、数時間〜数日間サイトが停止し、顧客や収益に影響を及ぼす」という誤解があります。
このような長時間のサイト停止は、制作会社のサーバー移行にとって大きな障壁になります。実際、一般的なサーバー移行では、移行中にサイトをオフラインにする必要があることがよくあります。例えば、共用サーバーには通常、本番サイトに影響を与えることなくサイトを複製するために必要なインフラがありません。
真実：移行時にもサイトのダウンなし
Kinstaのサイト移行サービスでは、移行中にもサイトがダウンすることはありません。専任のエンジニアがお客様のサイトをKinstaサーバーに複製し、その間、元のサイトは通常通り機能し続けます。
DNSレコードを変更する際だけは、切り替えの過程で一時的に挙動が不安定になる可能性があります。DNSが伝播している間は、古いサーバーに到達する訪問者もいれば、Kinstaのサーバーにアクセスする訪問者もいます。伝播にかかる時間はDNSプロバイダやTTL設定によって異なりますが、通常は数分〜数時間で完了します。つまり、トラフィックの少ない時間帯にDNS更新を予定したり、ビジネス要件に合わせて切り替えのタイミングを調整したりできます。
懸念2. DNSを変更するとサイトやメールサービスが壊れる
「DNSを変更すると、メール配信が中断され、一時的にサイトにアクセスできなくなったり、サーバー環境間で競合が発生する」というイメージも一般的です。
DNSの変更は、トラブルが起きやすい重要なポイントでもあるため、不安を感じやすい操作です。実際、DNS移行が適切に行われなければ、混乱が生じたり、サイトが一時的にダウンしたり、環境間で競合が発生したりする可能性があります。
真実：DNSを変更しても破損なし
KinstaのDNS管理は、慎重な検証プロセスと明確なガイダンスによって、こうした問題を未然に防ぎます。DNSレコードを「いつ」「どのように」更新するかはお客様側で完全にコントロールでき、チームやクライアントと相談しながら、自分のペースで変更内容を調整できます。
特に、DNSを変更する前にサイトを複製するため、両方のロケーションが同じサイトバージョンを提供している場合、DNS伝播による実質的な影響は最小限に抑えることができます。
メールサーバーについては、MXレコードがメール配送先を指定し、ドメインをウェブサーバーに紐づけるAレコードとは別に管理されます。さらに、メールサーバーがウェブサーバーと別の場合、通常レコードを変更する必要はありません。
Kinstaが推奨する検証プロセスでは、更新前にサイトプレビューツールを使用します。これにより、訪問者に影響が出るDNS変更を行う前に、機能テスト、コンテンツの確認、各種連携（統合）のチェックを行うことができます。
移行後の案内メッセージ内に掲載されている、DNSの紐付け先（切り替え）に関する記事を確認し、追加の質問があればサポートスタッフに問い合わせることができます。
懸念3. カスタム設定が複雑すぎて移行が大変
「WordPressのカスタムアーキテクチャ、標準でない構成、特殊な設定は、マネージドサーバーがサポートするには複雑すぎる、あるいは移行中に壊れてしまう可能性がある」という声もあります。
制作会社は、セキュリティを強化したり、パフォーマンスを向上させたり、開発ワークフローを効率化したりするために独自のアーキテクチャを使ってWordPressサイトを構築するのが一般的です。独自のカスタム設定は、マネージドサーバーではサポートしてくれないと思われがちです。
真実：専任エンジニアに任せて楽々移行
Kinstaの移行チームは日々さまざまな技術設定に対応しているため、制作会社独自の構成も見た目ほど特殊ではないケースが多いです。
例えば、BedrockとRootsスタックの実装は、頻繁に扱っています。マルチサイト（サブドメイン、サブディレクトリ、ドメインマッピングの有無にかかわらず）は、移行中にネットワーク検証、ドメインマッピングのチェック、サイト間の機能テストを行います。
サイトがApache専用のディレクティブに依存している場合、KinstaではそれらをNginx互換のルールに変換します。具体的には、リライトの挙動、リダイレクト、アクセス制御などを確認し、本番と同じように動作することを検証します。移行チームは、Bedrock/Roots、マルチサイト、リバースプロキシなど多様な構成にも対応してきました。これまでにも、リダイレクトルールやIP制限ルール、承認済みのNginxルールの移行を成功させています。
また、特殊なケースに対応するため、必要に応じてチームがカスタムツールを作成することもあります。ある制作会社の例では、エクスポート機能のないレガシーシステムに800件以上のリダイレクトルールが保存されていたことがありました。Kinstaのエンジニアは、それらのルールを抽出し、正規化して再フォーマットしたうえで、Kinstaのリダイレクトマネージャーへ問題なくインポートできるようにするスクリプトを作成することができています。
懸念4. 移行後にデータが失われたりリンクが壊れたりする
「WordPressの移行では、データベースの破損や内部リンク切れ、メディア参照の不整合が発生し、結果としてデータ損失や大量の手作業による修正が必要になることがある」という懸念もよくあります。
WordPressは複雑な関連情報をデータベースに保存しているため、データの整合性が保たれるかどうかは当然の懸念点です。たとえば、シリアライズされたデータ（PHPのオブジェクトを文字列として保存したもの）は、適切な処理をせずにURLだけを変更すると壊れてしまう可能性があります。内部リンクやメディア参照、プラグイン設定なども、正確なパスやドメイン情報に依存しています。
真実：専任エンジニアの手で慎重に品質保証チェック
Kinstaの移行ワークフローは、こういった問題を回避するように特別に設計されており、DNSの変更が訪問者に影響を与える前にすべてのリスクをキャッチします。
最初に、移行先環境に適したバックアップデータを準備します。利用中のサーバーに応じて、コマンドラインツール、phpMyAdmin、または管理パネルのエクスポート機能を使い、データの完全なスナップショットを作成します。
インポート後は、データベース容量の確認、必要に応じて、古い形式（MyISAM）のテーブルをInnoDBへ移行、wp-config.phpに基づくマルチサイト／サブディレクトリ構成の自動検出など、一連の整合性チェックを実施します。
URL変更やデータ更新は、SQLを手作業で編集するのではなく、WP-CLIの検索・置換を用いて安全に行います。これにより、シリアライズされた配列も壊れずに保たれます。さらにメディアライブラリのパスを手動で確認し、フロントエンドと管理画面の両方でテストを行って、画像や添付ファイルが正しく読み込まれることを確かめます。
リンクの挙動やハードコードされたURLについても慎重に扱い、品質保証の段階で、絶対パスを参照しているテーマやプラグインのファイルを特定し、必要に応じて該当箇所を指摘したうえで、WordPressに適した開発プラクティスで修正する方法を案内しています。
最後に、移行後のサイトが元のサイトを正確に反映しているかを確認する品質保証チェックを実施します。これには、ドメインやパス参照の更新も含まれ、さらに古いテーマやプラグインに起因する問題の解決方法についても提案します。
懸念5. 大規模サイトや複数サイトの移行に数週間かかる
「大規模なデータベースや膨大なファイルライブラリを持つサイト、または数十のサイトを社内で抱えている場合は、移行に数週間、あるいは数ヶ月かかる」というのもよくある誤解です。
大量のサイトを管理する制作会社のサーバー移行は、時間がかかり、リスクも大きいと考えられがちです。これは通常、移行能力が限られていたり、複雑なワークロードを処理する専任のチームがいなかったりするサーバーを利用した過去の経験から来るものです。
真実：2段階アプローチで移行時間を大幅短縮
Kinstaの移行ワークフローは、不必要な遅延を生むことなく、大規模なマルチサイトのポートフォリオにも対応できます。
事前にしっかり計画しておけば、非常に大規模なサイトでもスケジュールを予測しやすくなります。
適切な事前計画を行うことで、希望するスケジュールに沿って進めやすくなります。大規模なサイトでは、先にファイルを移行し、後日「追加分のファイル」とデータベースを移行する2段階の方法を取ることで、切り替え時の作業時間を短くできる場合があります。
具体例として、300GBのサイト移行時に、送信元ホストとKinsta間の接続速度が遅く、ファイル移行に24時間以上かかることがありました。そこでKinstaの移行部門は、完了予定日の2日前に先にファイルを移行し、最終日には新規（更新）ファイルだけを移行すると同時にデータベースをエクスポートしました。
一括移行でも同様に、構造化されたアプローチを取っています。
-
一括移行用のスプレッドシートを受け取り、ポートフォリオ内の各サイトの詳細情報を共有してもらう
-
お客様の優先順位に合わせてスケジュールを調整しつつ、制作会社あたり1営業日で最低8サイトの移行を目標に進める
-
お客様がすぐにテストを開始できるよう、各バッチの完了後に通知を送信
頻繁に変更されるECサイトやメディアサイトでは、2段階方式で最初にファイル一式を移行し、DNS切り替え直前に最新コンテンツの最終同期とデータベースのエクスポートを行います。これにより、本番サイトと移行後サイトの差分を最小限に抑えられます。
サーバー切り替え時の準備
サーバー移行にあたって、適切な準備を行うことで、プロセスを高速化し、予期せぬ問題が発生する可能性を低減することができます。
Kinstaでは、長年のサイト移行経験と完了した何千もの移行に基づく内部移行前チェックリストを使用しています。以下の構造を取り入れることで、移行プロセスをよりスムーズに進めることができます。
- チームとコミュニケーションチャネルを調整する：移行プロジェクトに参加するメンバーをチーム内で確認し、関係者のメールアドレスを共有します。Kinsta側で全員を同じ移行のやり取りに含められるようにしておくと、進捗の共有が一本化され、作業中の連絡が分散するのを防げます。
- 移行申請前にすべての認証情報を確認する：移行に影響する以下すべてのログインをテストします。
- サーバーのコントロールパネル
- SSHまたはSFTP認証情報
- WordPress管理者アカウント
これらの認証情報を事前に確認しておくことで、移行開始後の遅れをなくすことができます。
- カスタム設定や通常とは異なるものはすべて文書化する：移行部門が以下のような情報をより把握すればするほど、より効率的に設定を正確に再現することができます。
- 保存が必要なカスタムリダイレクトルール
- 実行し続ける必要のあるスケジュールタスクやcronジョブ
- ECサイトにメンテナンスモードが必要かどうか
- 標準以外のサーバー設定やオーバーライド
- 現在設定されているIP制限やアクセス制御ルール
これらの情報は、想定外のケースを事前に洗い出すのに役立ちます。
- DNSおよびメール関連情報を提供する：最終的な切り替え時にDNSへのアクセスが必要になるため、DNSをどこで管理しているかをメモし、ログイン情報をあらかじめ準備しておきましょう。また、Google WorkspaceやMicrosoft 365、その他のメールプロバイダなど、メールサーバーの利用先も共有することで、MXレコード周りの調整がスムーズになり、メールのトラブルを防ぎやすくなります。
- 関係者と期待値を設定する：関係者全員が移行のワークフロー、スケジュール、サイトの停止時間やメンテナンスの有無について理解していることを確認しましょう。Kinstaまたは社内チームを通じて、明確なコミュニケーションを取ることで、プロセスを円滑に進め、土壇場での不測の事態を防ぐことができます。
まとめ
WordPressサイトの移行は、本来、リスクや混乱を伴うものではありませんが、一般的なサーバーでの移行経験から、多くの制作会社が「サーバー移行は面倒」と感じています。
Kinstaではサイト移行部門を設け、移行プロセスを予測しやすく、スピーディーに進めることを目的に、制作会社が日々直面する複雑な課題にも対応できる体制を整えています。
サーバー移行を検討している場合、サーバーまわりの悩みを解決したい場合は、KinstaのWordPress専用マネージドクラウドサーバー、制作会社の成長を支援するエージェンシーパートナープログラムをぜひご利用ください。ご不明点があれば、いつでもお気軽にお問い合わせください。
