WordPressから独自CMSへの移行
記事や画像、URL、更新業務を確認し、必要な範囲から移行を検討します。
まず、移行が必要かを確認
WordPressの継続利用、改修、独自CMSへの移行を比較します。PHP更新やプラグイン管理が負担でも、直ちに全面移行が必要とは限りません。現在の管理状況と、実現したい業務を整理して方針を決めます。
コンテンツと機能を棚卸し
固定ページ・記事・画像・カテゴリ・フォームを一覧化します。プラグイン独自のデータ、会員情報や外部連携は、出力方法と移行可否を個別に確認。必要な機能を、新しい管理画面やAPI連携でどう実現するか検討します。
移行前にプラグインを整理するなら：停止・削除とデータの確認 →
記事を書き出すだけで、移行は終わる？
「管理画面から記事を保存できたので、もう元のサーバーは解約してよい？」。移行先で記事が読めること、画像が表示されること、問い合わせが届くことを確かめるまでは、解約を急がずに確認を進めます。
XMLは、記事の情報を渡すための形式です
WordPressの「ツール → エクスポート」では、投稿・固定ページ・カスタム投稿・分類・カスタムフィールドなどをXML（WXR）形式で書き出せます。WordPressへの取り込みに使う形式なので、React・Pythonによる独自CMSでは、移行先の項目への対応付けと取り込み処理を設計します。
書き出したファイルがあるだけで、画像ファイルやデザイン、プラグイン固有の機能まで再現できるとは限りません。旧サイトへの画像参照が残っていないか、本文に埋め込んだ独自の表示が崩れないかも確認します。
移行前に、担当者と確認すること
- 記事：下書き・公開日・分類・独自項目のうち、何を引き継ぐか。
- 画像・資料：ファイルを取得できるか。元のサーバーを止めても表示・ダウンロードできるか。
- フォーム：入力項目・通知先・受信メール・保存履歴・迷惑送信対策をどう引き継ぐか。
- 独自機能：予約・会員・決済などは、何の仕組みで動いているか。必要な情報の出力方法を個別に確認する。
- 更新中の情報：最終取り込みの時刻を決め、その後の記事や問い合わせをどう反映するか。
元のサイトへ戻す準備も、別に残します
WordPress公式のバックアップ資料では、通常のサイトを復旧するにはデータベースとファイルの両方が必要とされています。移行用の記事書き出しと、問題が起きたときに元へ戻す準備は分けて考えます。取得日時・保存先・復旧担当を記録し、個人情報を含むデータはアクセスできる人と保管期間を決めます。
切り替え前には検証環境で代表的な記事・画像・独自項目を確認し、フォームの送信と受信も試します。テスト内容が実際のお客様に送られないようにし、公開後の確認が終わってから旧環境の契約や保存データを整理します。
参考にした公式情報
URLと公開切り替えを設計
既存URLの維持を優先し、変更するURLは対応表とリダイレクトを用意します。タイトル・説明文・内部リンク・画像・検索設定を確認し、公開後もエラーや検索状況を確認します。検索順位の維持を保証するものではありません。
新しい構成でも保守を続ける
PHPを使用しない構成では、そのサイトのPHP更新は不要になります。一方で、JavaScript・Pythonの依存ソフトウェアやクラウド設定の管理は必要です。監視・バックアップ・復旧手順・費用を含めて運用を設計します。
データ移行のよくある質問
WordPressのXMLを書き出せば、独自CMSへそのまま移行できますか？
そのまま取り込めるとは限りません。WordPress標準のXML（WXR）は投稿や固定ページなどの情報を含みますが、独自CMSの入力項目やデータ形式に合わせた変換・取り込みが必要です。画像ファイル、表示、独自機能も別に確認します。
エクスポートとサイト全体のバックアップは同じですか？
異なります。記事の書き出しだけでは、テーマ・プラグイン・画像ファイルを含む元サイト全体を戻せるとは限りません。元のWordPressを復旧するためのバックアップは、データベースとファイルの両方を対象に準備します。
移行中に入った問い合わせや更新記事はどうなりますか？
最終取り込み後の追加データが漏れないよう、更新を止める時間や差分の反映方法を決めます。問い合わせは受信メールと保存データの扱い、送信先、切り替え前後の確認担当を整理します。自動で同期される前提にはしません。