これは何の問題だったか
WordPressの引っ越しではなく、
見えない依存関係を解く仕事でした
サーバーが古い
OS、PHP、DBがサポート終了。脆弱性が見つかっても修正が提供されない状態でした。
正しい現行環境が分からない
似た構成が複数サーバーにあり、版も異なっていました。まず、どちらが実際に使われているかを確かめる必要がありました。
Webサイトだけではない
WordPressの外に、メール、チャット、ファイル共有、社内ポータルなどの業務サービスが動いていました。
止めて試せない
問い合わせや社内業務が続いているため、旧環境を残し、検証環境で確かめてから段階的に切り替える必要がありました。
着手時の状態
「動いているから触れない」が、先送りの理由になっていました
OS
CentOS 7・RHEL 7系
すでにサポート終了
PHP
7.3・7.4系
8.4へ上げると互換問題
Web
複数WordPress
マルチサイトと古いテーマを含む
業務
複数の社内サービス
DB・Docker・Java・メールも依存
顧客はセキュリティ上の危険を認識していましたが、WordPressだけを扱う会社には業務サービスまで任せられず、 インフラ会社には古いテーマやプラグインの改修まで頼みにくい状態でした。 作業の境界を引けないこと自体が、相談先が見つからない原因でした。
実際に行ったこと
調査、移植、検証、切替を一つの工程として進めました
現行環境を棚卸し
サーバー、ドメイン、WordPress、DB、テーマ、プラグイン、フォーム、メール、cron、社内サービスを一覧化。版と稼働状態を実機で確認しました。
移行リスクを先に判定
PHP 8.4互換、MySQLとMariaDBの差、廃止プラグイン、マルチサイト、外部サービス、DNS管理者を調べ、切替前に問題になりそうな箇所を洗い出しました。
本番・検証・業務系を分離してAWSを構築
VPC、EC2、ALB、WAF、ACM、バックアップ、監視を用意。旧サーバーの役割をそのまま一台へ押し込まず、用途ごとに環境を分けました。
約9.8GBと複数DBを移植
WordPress本体、テーマ、プラグイン、uploads、DB、業務サービスのデータを取得。旧環境を動かしたまま、まず検証環境へ復元しました。
PHP 8.4で動くように修正
古いテーマ、プラグイン、文字コード、DB collation、ファイル権限を調整。単に最新版へ更新せず、実際の画面と管理操作を確認しながら直しました。
顧客検証を一件ずつ解決
表示、投稿、画像アップロード、プレビュー、管理画面を顧客にも確認してもらい、指摘を原因別に切り分けました。旧環境を見ていたケースとAWS側の不具合も区別しました。
約20フォームを送信テスト
送信先、確認画面、自動返信、添付、迷惑メール対策まで確認。サーバーが表示できるだけでなく、問い合わせを失わないところまで検証しました。
DNSを段階的に切替
旧環境を残したまま、ドメインごとに切替。SSL、メール、フォーム、社内サービスを切替直後に再確認し、戻せる状態を維持しました。
移行中に見つかった問題
予定どおりコピーできないことを、予定に入れておく
移行では10件以上の技術的問題が発生しました。重要なのは、問題をゼロと約束することではなく、 旧環境を残し、ログと実機で原因を切り分け、業務を止めずに直せる手順を持つことでした。
WAFが正規操作を遮断
管理画面の投稿や画像アップロードが403に。WAFログから該当ルールを特定し、管理操作だけを安全に通しました。
PHP更新で表示が変わる
WordPressとテーマの仕様差により余白やウィジェットが変化。旧・新環境を比較し、必要なCSSと設定を補いました。
画像をアップロードできない
権限、Webサーバーの上限、WAFを順に確認。原因を一つに決めつけず、経路全体を直しました。
検証先ではなく旧サーバーが見える
社内プロキシではPCのhosts設定が効かないことを特定。画面に表示されたPHP版を証拠に、接続先の違いを説明しました。
マルチサイト特有のURL
サブサイトのアップロードURLやプレビューURLが通常のWordPressと異なり、WAFやブロック検証で不一致が起きる箇所を修正しました。
メール・DNSを別会社が管理
顧客、既存ベンダー、DNS管理会社と役割を分け、誰がいつ何を変更するかを切替計画へ落としました。
移行結果
旧環境を残したまま検証し、段階的に本番を切り替えました
複数
WordPressサイト
表示と管理操作を確認
約20
問い合わせフォーム
送信と自動返信を検証
10件以上
移行中の問題
原因を記録して解決
3環境
AWS上に分離
本番・検証・業務系
この事例で証明できること
BBJが証明できるのは「WordPressをコピーできる」ことではありません。 作った会社、運用会社、DNS管理会社が異なる環境でも、動いているものから事実を拾い、 顧客が確認できる資料にし、問題が起きても原因を説明しながら本番切替まで進められることです。
記録から確認できる事実
2026年2月の調査から、3月の本番切替まで
このページは後から作った一般論ではありません。2026年2月14日の現状調査、3月1日からのAWS構築、 3月6日からのデータ転送、3月11日からの顧客検証、3月19日からのフォーム送信試験、 3月下旬のDNS切替と完了報告まで、日付入りの作業記録を基にしています。
2月14日
旧サーバー、OS、PHP、DB、WordPress、業務サービスの現状調査
3月1日〜5日
AWSネットワーク、ALB、WAF、証明書、バックアップ環境を構築
3月6日〜8日
データ転送、WordPress復元、PHP互換修正、業務サービス起動
3月11日〜24日
顧客検証、WAF・画像・テーマ・マルチサイト問題への対応
3月19日〜20日
約20フォームの送信・自動返信を実地確認
3月下旬
複数のDNS管理者と連携し、ドメインごとに本番切替
同じ状態かもしれない会社へ
移行の見積より先に、何が動いているかを出します
最初から移行を発注する必要はありません。サーバー情報、ドメイン一覧、管理画面、分かる範囲の運用資料から、 「何があるか」「何が危ないか」「誰に確認が必要か」「先に試すもの」を整理します。 移行するか、延命するか、止めるかは、その地図を見てから決められます。
本ページは実際の移行記録を基にしています。顧客を特定できる名称、ドメイン、IP、認証情報は掲載していません。
よくあるご相談
古いWordPress・CentOS 7の移行について
古いWordPressのサーバー移行を断られるのはなぜですか？
WordPress本体だけでなく、古いPHP、独自テーマ、廃止プラグイン、フォーム、メール、DNS、社内サービスが相互に依存し、作業範囲と責任を先に確定できないためです。BBJは移行見積の前に、現行環境と依存関係を調査します。
CentOS 7とPHP 7.4で動くWordPressをAWSへ移行できますか？
可能性はありますが、そのままコピーして終わりにはできません。本事例ではAmazon Linux 2023とPHP 8.4の検証環境を先に作り、テーマ、プラグイン、DB、フォームを動かして修正してから切り替えました。
WordPress以外の社内システムが同居していても相談できますか？
相談できます。本事例でもDB、Docker、Java、チャット、ファイル共有などがありました。最初にサービス、データ、通信先、定期処理を棚卸しし、移行単位を分けました。
稼働中のサイトと問い合わせフォームを止めずに移せますか？
完全な無停止を調査前に保証はしません。旧環境を残して検証環境へ複製し、約20フォームを送信テストした後、DNSを段階的に切り替えることで停止と問い合わせ喪失のリスクを下げました。
移行を決める前で構いません
古い環境の全体像から整理します
分かる範囲を箇条書きでお送りください。代表の水野が直接確認します。