独自CMSからWordPressへ移行できる？データ・URL・機能の確認手順

独自CMSからWordPressへの移行は、多くの場合、何らかの方法で進められます。ただし、サイト全体をボタン一つでそのまま移せるとは限りません。記事と画像はまとめて移せても、フォームは作り直す、検索機能は仕様を見直す、URLは別に引き継ぐ、といった組み合わせになることがあります。

そのため、最初に決めるべきなのは「移行できるか、できないか」の二択ではありません。記事、固定ページ、画像、PDF、カテゴリ、ユーザー、URL、フォーム、検索、外部連携、デザインを対象ごとに分け、自動移行・変換・手作業・再構築のどれで扱うかを決めます。この分け方ができると、残せるものと作り直すものが見え、見積もりの前提や公開時の確認範囲もそろえやすくなります。

独自CMSからWordPressへ移せるかは、対象ごとに決まる

「独自CMS」という呼び方だけでは、移行難易度を判断できません。同じ独自CMSでも、CSVやXMLで記事を出力できるもの、データベースへアクセスできるもの、公開画面からしか内容を確認できないものでは、選べる方法が変わります。また、一つのサイトの中でも、ニュースは自動移行、会社案内は手作業、問い合わせフォームは再構築というように、対象によって方法が分かれます。

四つの方法は、次のように考えると整理しやすくなります。

方法	向いている状態	主な作業
自動移行	出力形式とWordPress側の受け皿が対応し、項目の規則がそろっている	インポーターや移行スクリプトでまとめて登録する
変換	データは取得できるが、項目名、HTML、日付、カテゴリなどの形式が違う	WordPress用の形式へ加工してから取り込む
手作業	件数が少ない、例外が多い、公開画面でしか確認できない	内容を確認しながら個別に登録し直す
再構築	フォーム、検索、会員機能、外部連携、テンプレートなど	現在の目的と必要条件を確認し、WordPress側で作り直す

重要なのは、自動移行を増やすこと自体を目的にしないことです。数十件の例外を無理にスクリプトへ含めるより、規則的なデータだけ自動で移し、少数の例外を手で直した方が、確認しやすい場合があります。反対に、記事が数百件あるのに全件をコピー＆ペーストすると、公開日、カテゴリ、画像、内部リンクの抜けを見つけにくくなります。方法は件数だけでなく、データの規則性と検査方法まで含めて選びます。

最初に確認するのはCMS名より、契約・権限・データ出力

移行調査は、管理画面を見て終わりではありません。まず、現在のサイトを誰がどこまで管理できるのかを確認します。少なくとも、ドメイン、DNS、サーバー、CMS管理画面、ファイル、データベース、ソースコード、問い合わせ先メール、利用中の外部サービスについて、契約者とアクセスできる人を整理します。

ここで確認したいのは、パスワードそのものではなく、「何の管理画面があるか」「誰が権限を持つか」「移管や出力に制限があるか」です。共有資料へパスワードや認証コードを書き込まず、実際に権限を渡す段階で安全な共有方法を決めます。制作会社が独自CMSを提供している場合は、契約書や利用規約を確認し、データ、プログラム、デザイン、画像の権利と、契約終了後に受け取れるものを分けます。

次に、CMSから何を取り出せるかを調べます。候補になるのは、CSV、XML、JSON、API、データベースのダンプ、サーバー上の画像・PDF、HTMLです。出力ボタンがあっても、公開済み記事だけなのか、下書き、カテゴリ、カスタム項目、ユーザー、添付ファイルまで含むのかは別問題です。サンプルを少量出力し、文字コード、改行、HTML、画像URL、日付、公開状態、親子関係を実際に確認します。

WordPressの公式ドキュメントでも、他の公開システムからコンテンツを取り込める一方、システムごとに手順が異なると案内されています。つまり、「WordPressにインポート機能がある」ことと、「独自CMSの全データをそのまま受け取れる」ことは同じではありません。取得できる形式と、WordPress側で必要な項目の対応を調べて初めて、移行方法が決まります。

現行サイトの契約は、新サイトが公開された時点ですぐ解約しない方が安全です。移行後に不足データが見つかったり、旧URLやフォームの動きを確認したりすることがあるため、保存期間と解約条件を先に決めます。いつまで旧環境を残すかは、契約費用だけでなく、復旧と照合に必要な期間を踏まえて判断します。

移行対象を一覧化し、ページ数より中身を数える

「サイトは50ページです」という情報だけでは、移行量を正確に見積もれません。1ページの中に、本文、複数画像、PDF、表、関連記事、フォーム、構造化された製品情報が含まれている場合があるからです。反対に、同じテンプレートで作られた短いお知らせが多数ある場合は、規則を見つければまとめて処理しやすくなります。

まず、サイトマップ、CMSの記事一覧、公開サイトの巡回結果、アクセス解析、サーバー上のファイル一覧を照らし合わせ、移行台帳を作ります。台帳には、少なくとも次の項目を持たせます。

• 現在のURLとページ名
• コンテンツ種別、公開状態、公開日、更新日、投稿者
• 本文、要約、カスタム項目、カテゴリ、タグ、親子関係
• 画像、PDF、動画、ダウンロード資料の所在
• 内部リンク、外部サービスへのリンク、埋め込み
• WordPress側の格納先と移行方法
• 移行後の確認担当と確認状態

公開画面に見える内容だけでなく、管理画面で使っている情報も分けて数えます。たとえば、一覧表示の並び順、注目記事のフラグ、フォームの送信先、製品の絞り込み項目、会員区分は、公開画面からは全体を把握できないことがあります。これらを本文と同じ「ページ」として扱うと、移行後に機能だけ不足する原因になります。

画像とPDFは、ファイル数だけでなく、どこから参照されているかを確認します。本文中の絶対URLが旧サーバーを向いたままだと、新サイトが表示できても、旧サーバー停止後に画像や資料だけ消えることがあります。ファイル名が重複している、同じ画像が複数サイズで保存されている、日本語ファイル名や特殊文字を含む、といった例外も台帳へ残します。

すべてのページを同じ深さで調べる必要はありません。まず主要なページと、件数が多いコンテンツ種別を選び、規則と例外を見つけます。規則が確定した後に全件へ広げると、調査の途中で項目を追加し直す手戻りを減らせます。

URLはデザインより先に、旧URLと新URLの対応表を作る

CMSを変えても、既存URLを維持できるなら、変更しない方が分かりやすい場合があります。ただし、独自CMSのURLがパラメータ形式で、WordPressの構造と合わない場合や、ページ統合・削除を行う場合は、新しいURLを設計し、旧URLごとの行き先を決めます。

URL対応表には、旧URL、新URL、扱い、確認結果を記録します。扱いは「同じ内容へ移行」「複数ページを統合」「代替ページなしで終了」「画像・PDFを移動」などに分けます。ページがなくなるからといって、すべてをトップページへ送るのではなく、利用者にとって対応する内容があるかを一件ずつ判断します。

Google Search Centralのサイト移転ガイドは、旧URLと新URLの対応表を用意し、可能ならサーバー側の恒久的なリダイレクトを使うこと、リダイレクトの連鎖を避けること、関係のない多数のURLをトップページなど一つのURLへまとめて送らないことを案内しています。恒久的なURL変更では301または308が候補になります。設定方法はサーバー環境によって異なるため、実装後に全件または優先URLを機械的に検査します。

URL変更時は、リダイレクトだけでは終わりません。新サイトの内部リンク、canonical、サイトマップ、画像・PDFのURL、広告やプロフィールからのリンクも確認します。公開時に開発環境用のnoindexが残っていないか、404が急増していないか、Search Consoleやアクセス解析で旧URLと新URLの動きを確認できるかも、公開手順へ含めます。

Googleのガイドでは、リダイレクトを可能な限り長く、一般に少なくとも1年間維持することも案内されています。実際の保持期間はサイトの事情で判断しますが、「公開確認が終わったから数日で削除する」という扱いにはしません。旧URLへ来る利用者や外部リンクが残る可能性まで考えます。

フォーム・検索・外部連携は、データではなく機能として再設計する

記事本文を移せても、独自CMS上の機能がWordPressへ自動的に移るわけではありません。フォームや検索は、画面の見た目だけでなく、入力、処理、保存、通知、外部サービスへの送信まで含む仕組みです。現在と同じ見た目を再現できても、裏側の動作が違えば、業務上は同じ機能とはいえません。

問い合わせフォームは、送信後の業務まで確認する

フォームでは、入力項目、必須条件、確認画面、自動返信、社内通知先、添付ファイル、迷惑送信対策、個人情報への同意、完了ページを整理します。さらに、送信をアクセス解析で計測しているか、顧客管理やメール配信へ連携しているか、エラー時に誰が気づくかも確認します。

移行後のテストは、画面が表示されるだけでは不十分です。テスト用の宛先と入力内容を決め、利用者側と担当者側の両方で受信し、文字化け、迷惑メール判定、添付、返信先、計測まで確認します。公開中の実フォームへ顧客情報を入れて試すのではなく、テスト方法とデータ削除の扱いを先に決めます。

検索・会員・予約・外部サービスは、必要条件を言葉にする

サイト内検索は「検索窓がある」だけでは仕様になりません。検索対象、部分一致、カテゴリ絞り込み、並び順、0件時の表示、非公開情報の除外を確認します。独自CMSで製品や事例を複数条件で絞り込んでいる場合、WordPressの標準検索だけでは同じ結果にならないことがあります。

会員、予約、決済、在庫、基幹システム、地図、求人、SNS、MA・CRMなどの外部連携は、現在の接続先、契約者、APIや認証方式、送受信する項目、障害時の対応を整理します。旧システムの認証情報を資料へ貼り付けず、必要な権限だけを安全に渡します。会員パスワードのように、保存方式や認証方式が違うためそのまま移せない情報は、再設定手順や案内方法まで含めて設計します。

各機能は、「WordPress標準で再現」「既存プラグインを利用」「個別開発」「代替手順へ変更」「廃止」のいずれかへ仮置きします。現在あるから残すのではなく、今も必要か、更新担当が扱えるか、保守できるかを確認して選びます。

デザインは「移せるか」より、どこまで再利用するかを決める

CMSのデータ移行と、見た目の移行は別工程です。記事の本文や画像をWordPressへ登録できても、独自CMSのテンプレートがそのままWordPressのテーマになるわけではありません。WordPress側では、ヘッダー、フッター、一覧、詳細、固定ページ、フォームなどの表示を、テーマやブロックテンプレートとして組み直します。

現行サイトのHTMLやCSSを一部再利用できる場合もありますが、更新画面との接続、レスポンシブ表示、プラグインとの干渉、アクセシビリティ、将来の保守を確認する必要があります。「見た目を完全に同じにする」ことを優先すると、独自CMSで更新しづらかった構造まで再現してしまうことがあります。

先に決めたいのは、公開後に誰が何を変えたいかです。お知らせだけ更新するのか、サービスページの順番や画像も変えたいのか、定型ページを追加したいのかで、編集可能にする範囲が変わります。自由に編集できる場所を増やすほど便利に見えますが、レイアウト崩れを防ぐルールや確認作業も増えます。反対に固定しすぎると、移行後も小さな修正を制作会社へ依頼し続けることになります。

デザイン方針は、「現行の印象を保って構造だけWordPress化」「文章や写真を残し、導線と見た目を部分的に見直す」「情報設計から全面的に作り直す」などに分けられます。データ移行の可否とデザイン方針を一つの判断にまとめず、再利用できる資産と、更新しやすさのために変える部分を分けて考えます。

本番前に代表データでテスト移行し、件数と内容を照合する

全件移行の前に、代表的なデータを選んでテストします。短い記事だけでなく、長文、画像が多い記事、表や埋め込みを含む記事、階層の深いカテゴリ、下書き、予約公開、特殊なHTML、古い形式のデータなどを含めます。例外が見つかりやすい組み合わせを先に試すことが大切です。

テストでは、見た目の確認とデータの照合を分けます。データは、移行前後の件数、公開状態、日付、投稿者、カテゴリ、親子関係、画像・PDF、内部リンクを比較します。見た目は、PCとスマートフォンで、見出し、表、リスト、画像、余白、リンク、埋め込みを確認します。ファイルが表示されても、旧サーバーのURLを参照していないかまで見ます。

WordPress公式のインポート案内では、処理が途中で失敗しても一部のコンテンツが作成され、再実行すると重複する可能性があると注意されています。エラー時に「最初からやり直せばよい」と決めず、どこまで登録されたかを確認し、再実行前に削除・上書き・スキップの方針を決めます。移行スクリプト側に、元データのIDを記録して重複を判定できる仕組みを持たせる方法もあります。

旧サイトで更新が続く場合は、テスト移行後に増えた記事や修正内容をどう反映するかを決めます。一定期間だけ更新を止める「更新停止期間」を設ける方法と、差分だけ再移行する方法があります。更新停止を設けるなら、社内担当者と公開予定を共有し、緊急更新の扱いも決めます。

テストの完了条件は、「担当者が見た」ではなく、確認項目と結果が残っていることです。件数が一致したか、例外はどの方法で直したか、未解決事項は誰がいつ判断するかを記録します。その記録が、本番移行と公開後の調査に使える手順書になります。

公開当日は、切り替えることより戻せる状態を作る

公開作業では、旧サイトのファイル、データベース、設定、リダイレクト前の状態をバックアップします。新サイトも、公開直前の状態を戻せるようにします。バックアップがあるだけでなく、誰がどの手順で復元できるか、復元に必要な権限があるかを確認します。

公開手順には、DNSやサーバーの切り替え、SSL、キャッシュ、noindex解除、リダイレクト、サイトマップ、フォーム、アクセス解析、Search Console、主要ページの表示確認を含めます。実施順と担当を決め、各工程の完了を記録します。複数の設定を同時に変える場合は、不具合が出た時に原因を切り分けられる順序にします。

戻す条件も先に決めます。たとえば、問い合わせが送れない、主要ページが表示できない、広範囲なリダイレクト誤りがある、管理画面へ入れないといった事象が出た場合に、修正を続けるのか、旧サイトへ戻すのかを判断できるようにします。公開直後に旧環境を消さないのは、このためでもあります。

公開後は、404、フォームエラー、旧URLへのアクセス、検索のクロール状況、表示速度、アクセス解析の計測を確認します。検索表示は即時に切り替わるものではないため、順位だけを見て成功・失敗を決めません。技術的なエラーと、検索エンジンが新URLを処理する時間を分けて見ます。

公開後の更新担当と保守範囲まで決める

WordPressへ移行すると、更新作業の担当が自動的に決まるわけではありません。記事を作る人、内容を承認する人、画像を用意する人、WordPress本体・テーマ・プラグインを更新する人、バックアップと障害対応を担う人を分けます。小規模な体制でも、少なくとも「日常の内容更新」と「技術的な保守」を同じ作業として曖昧にしないことが大切です。

管理者権限を全員へ配るのではなく、役割に必要な権限を設定します。退職や担当変更時の停止手順、二要素認証、共有アカウントを使わない運用も決めます。ドメイン、サーバー、外部サービスの契約更新日と登録メールを整理し、担当者個人のメールだけに依存しない形へ近づけます。

保守範囲では、WordPress本体、テーマ、プラグイン、PHPやサーバー環境の更新、バックアップ、セキュリティ監視、フォームの定期送信確認、障害時の連絡先を確認します。独自CMSから移る目的が「特定の会社にしか触れない状態を減らす」ことであっても、保守が不要になるわけではありません。更新しやすい仕組みと、安全に維持する体制をセットで考えます。

移行時に作った項目対応表、URL対応表、機能一覧、テスト結果、公開手順は、公開後も残します。どの項目がWordPressのどこへ入ったかが分かれば、将来の改修や再移行でも調査をやり直さずに済みます。旧CMSの停止は、必要データの保存と照合が終わり、契約上の手続きも確認した後に行います。

見積もりはページ数だけでなく、移行方法と検査範囲を比べる

移行の見積もりを見る時は、金額だけでなく、何をどの方法で移し、どこまで確認するかを比べます。同じ「50ページ移行」でも、公開画面を手作業で登録する見積もりと、データベースを解析して下書き・カテゴリ・画像まで移す見積もりでは、対象も成果物も違います。

見積もりに含まれるか確認したいのは、現行調査、移行台帳、項目対応、変換スクリプト、手作業の補正、画像・PDF、機能再構築、URL対応とリダイレクト、テスト移行、件数照合、公開作業、公開後の監視、操作説明です。含まれない作業も明記してもらうと、後から追加になりそうな範囲を把握できます。

特に、「データ移行一式」という表現だけでは、下書き、公開日、投稿者、カテゴリ、画像、内部リンク、フォーム、旧URLが含まれるか分かりません。対象データの一覧と完了条件を合わせて確認します。移行できない項目がある場合は、削除、手作業、代替機能、運用変更のどれで扱うかを決めます。

費用や期間は、データ量だけでなく、現行CMSへのアクセス、規則性、例外数、機能、デザイン変更、確認担当者の体制で変わります。調査前に一律の期間や金額を断定するより、代表データと機能を確認し、前提をそろえた見積もりの方が比較しやすくなります。

WordPressへ移さない判断もあり得る

確認の結果、独自CMSを改修して使い続ける方が合う場合もあります。現在の業務に深く組み込まれた機能が安定して動き、保守担当と更新手順が確立しているなら、CMSだけを変えることで負担が増える可能性があります。逆に、公開ページが少なく、必要な機能も限られているなら、データ移行へ大きな仕組みを作らず、必要な内容だけを整理して再制作する方が分かりやすいこともあります。

WordPressは有力な選択肢ですが、サイトの目的、更新体制、必要な機能、保守できる人に合うかを確認して選びます。CMSそのものを比較し直す場合は、「CMSの選び方｜中小企業が押さえるポイント」で、運用体制と機能要件から候補を整理できます。

まとめ｜「移せる・移せない」ではなく、対象と方法を分ける

独自CMSからWordPressへの移行は、サイト全体を一括で判定するのではなく、記事、固定ページ、画像、カテゴリ、ユーザー、URL、フォーム、検索、外部連携、デザインを分けて考えます。そのうえで、自動移行、変換、手作業、再構築のどれを使うかを決めます。

契約と権限、データ出力、移行台帳、URL対応、機能要件、代表データのテスト、件数照合、公開時の復旧手順、公開後の担当まで確認できれば、見積もりの前提と完了条件が明確になります。最初から技術的な結論を出す必要はありません。分かっていることと未確認のことを分け、調査する順序を決めることが、無理のない移行計画の出発点です。