Drupal から WordPress への移行：適切なタイミングと、その際に犠牲になるもの.

Drupal から WordPress へ移行できるものと、移行できないもの?

標準的なコンテンツタイプ、カテゴリ、タグ、メディアは、無料の「FG Drupal to WordPress」プラグインで移行できます。ただし、それだけでは足りない項目もあります。ユーザー、パスワードハッシュ、カスタム投稿タイプ、メニュー、コメント、自動の301リダイレクトまで移すには、プレミアム版が必要です。多くのサイトのようにユーザーデータを移行しないのであれば、Kinstaが指摘しているとおり、無料版でも十分に対応できます。

テーマは移行できません。Drupal 8以降はTwigで動き、WordPressはPHPテンプレートで動作するため、テーマは一から作り直すことになります。最も手間がかかるのはParagraphsの扱いです。各タイプをカスタムGutenbergブロックかACFフィールドに対応させ、置き換え用のブロックを組む必要があります。その後はクリーンアップです。一括エクスポートの実行後、カスタムフィールドのデータ、メタタグの値、壊れたメディアパス、エンティティ間の関連付けなどを手作業で直します。この工程には十分な時間を確保してください。こうした不備は、新しい構築環境と旧ページを突き合わせて監査して、初めて見つかります。

検索トラフィックを維持するために、URLマップやリダイレクトをどのように計画すればよいでしょうか?

パスの照合はスプレッドシートで行います。A列にはDrupalの全URL、B列には移行先WordPressのURL、C列にはステータス（完全一致、リダイレクトが必要、統合、削除）を整理します。エイリアスはpath_aliasテーブルから直接取得してください。Pathautoのレコードも含め、リダイレクトの連鎖を避けるために、Redirectモジュールの行もエクスポートします。PathautoのURLに対するリダイレクトの対応を削除してしまうと、ClonePartnerの報告では、サイトは通常、最初の90日間でオーガニックトラフィックの20～40％を失うとのことです。見落とされやすいパスもあります。「sites/default/files/」から「wp-content/uploads/」に移るアセット、末尾のスラッシュが付いた、または外れたタクソノミーアーカイブ、独自のページネーション方式を確認してください。タームページはロングテール検索のトラフィックを集めやすいため、タクソノミーテンプレートを作り直し、旧ルートからリダイレクトします。（トラフィックが落ちるまで、確認漏れに気づきにくい部分です。）

Google Search Centralのガイダンスに従い、連鎖のないサーバーサイドの301または308リダイレクトを設定してください。公開後も監視を怠ってはいけません。Search Consoleで新旧両方のプロパティの検索指標を追跡し、新しいサイトマップを送信し、これらのリダイレクトは少なくとも1年間有効にしておきます。公開日をゴールと考えないでください。

Drupal からコンテンツを移行する方法：エクスポート、API、またはクロール?

プラグインを使ってデータベースを移行しましょう。大量のレコードは一括で処理し、例外だけ手作業で修正します。ただ、公開ページのクロールは、元データを抜き出すためではなく、移行後の状態を確かめるために使ってください。Codeableでは、この段階的な進め方をこう説明しています。まずFGプラグインで投稿、メディア資産、用語を移し、そのあとで、マッピングできなかったカスタムフィールド、見つからないファイルパス、カスタムエンティティ同士の関係をスクリプトと手作業で整えます。

クロールで取れるのは、ブラウザに届くデータだけです。レンダリングされたHTML、HTTPレスポンスヘッダー、見出しタグ、スキーママークアップ、カノニカルタグなどがこれにあたります。ただ、裏側の情報は取れません。下書きノード、データベースフィールドのスキーマ、ロール権限などは見えないため、表側のスキャンだけでコンテンツアーキテクチャを組み直すことはできません。移行作業に入る前に、すべてのパスエイリアス、Redirectモジュールのテーブル、レンダリング後のメタタグ出力、代替のhreflangタグをデータベースから書き出してください。公開ページのクロールでは、非公開のAPIエンドポイントまで把握できません。パイプラインを設計する前に、エンジニアと一緒にバックエンドのアクセス権限を確認しましょう。

WordPressとDrupalを比較した場合、編集者はどのような機能を利用できますか?

編集チームには、最初から2つのタイプが揃った標準ダッシュボードが提供されます。公開日、カテゴリ、タグを備えた「投稿（Posts）」と、階層構造を持ち、分類を持たない「ページ（Pages）」です。基本の運用ならこれで十分でしょう。ただ、もっと複雑な構造が必要なら、専用の投稿タイプとタクソノミーを登録してください。100万以上のサイトで使われている「Custom Post Type UI」プラグインを導入すれば、PHPコードを一切書かずに、管理画面からこれらの定義をすばやく追加できます。

WordPress に移すと、リレーショナルな厳密さが失われる分、フィールド設計の粗がそのまま表面化します。Drupal のエンティティフィールド、ボキャブラリ、アクセス権限、翻訳グラフに対応するコア機能は、初期状態の WordPress には存在しません。だから、まずはモデルを組みましょう。生データを流し込む前に、カスタム投稿タイプとACFフィールドグループを使って、元のデータ構造を忠実に再現する必要があります。ここを怠ると、コンテンツがまったく意図しないテーブルへ書き込まれてしまいます。Gautam Khorana氏のケーススタディでは、800件の記事ノードが標準の「投稿」テーブルへ直接インポートされた失敗例が紹介されています。「Paragraphs」はGutenbergブロックやACFの「Flexible Content」レイアウトへ置き換える形になり、専用の編集画面を仕立てるにはReactの知識が欠かせません。（これは純粋なスキルの問題であり、管理画面の設定で解決する話ではありません。）

ただ、小規模な編集中心のサイトで、コンテンツの種類もほんの数パターンなら、このトレードオフを受け入れる余地はあります。

Drupal から WordPress への移行にはどのくらいの時間がかかり、その作業量に影響を与える要因は何でしょうか?

移行期間を左右する要素は5つあります。URLの総数、コンテンツタイプの種類、メディアライブラリのサイズ、サードパーティ製サービスとの連携、有効なロケールです。だから、外部の平均値だけを眺めていても、正確な納期は見えてきません。残すコンテンツタイプが増えるほど、開発工数は跳ね上がります。残すタイプごとに、カスタム投稿タイプの登録、ACFフィールドスキーマ、専用のテンプレート開発をこなさなければならないからです。フロントエンドの制作も、既存のスタイルシートをコピーするだけでは終わらず、ゼロから書き直す必要があります。

ページ数が増加すれば、URLリストは膨らみ、リダイレクトの照合作業も重くなります。複数言語を扱っている場合は、hreflang のデータを別途エクスポートしたうえで、ステージングドメイン全体を目視で入念に突き合わせなければなりません。そして、Paragraphs の有無も費用に直結します。もしページ内で Paragraphs を多用しているなら、ブロック設計のために開発スプリントを何枠か確保しておいてください。Pagepro の SEO チェックリストには、初期ベンチマークからリリース後の監視まで8つの工程が定められており、その一つひとつにまとまった工数を割り当てておく必要があります。

無料診断を使えば、客観的な数値をもとに見積もりを練り直せます。トップページと最大8つのサンプルページを巡回し、8つの評価項目を100点満点の単一スコアに要約する仕組みです。ただし、測れるのは外側の状態にすぎません。スプリントの計画を確定する前に、このスキャンでスクリプトの容量、レスポンスヘッダー、スキーママークアップの抜け漏れを洗い出せます。管理画面内のデータや非公開のアクセスログは取得できません。だから、サイト内のコンテンツ構造はご自身の手で把握し続けるしかありません。

Drupal から WordPress への移行を控えるべき場合?

Drupal サイトがコンテンツ量が多い場合は、移行すべきではありません。通常、フィールド、タクソノミー、権限、多言語構造において、得られるメリットよりも失うものの方が多くなるからです。また、サイトが安定しており、編集者がそのサイトを気に入っており、評価の結果も良好である場合は、現状を維持すべきです。

使っているDrupalのバージョンを確認してください。Drupal 7は2025年1月5日にサポート終了を迎え、Drupal 10は2026年12月9日に公式サポート終了となります。だから、判断の先延ばしは禁物です。同じプラットフォーム内で上位版へアップグレードするにせよ、WordPressなど別環境へ乗り換えるにせよ、明確なロードマップを今すぐ敷く必要があります。

静的なメディアサイトやコーポレートサイトなら、Astroの採用を検討してみてください。パーソナライズされた動的機能や、大規模な編集チームを抱えるWebアプリケーションなら、SanityやContentfulをバックエンドに据えたNext.jsが有力な候補になります。ただし、それぞれ代償があります。Astroを選ぶと、執筆者が慣れ親しんだビジュアルエディタや豊富なプラグインエコシステムを諦めなければなりません。そしてヘッドレス構成を採る場合は、独立したAPIサーバーを別途構築し、その運用保守費用も払い続ける必要があります。私はアーキテクチャの評価、移行計画の策定、古いシステムやWordPressからこれらのモダンな実行基盤への移行支援を本業としていますが、一般的なWordPress構築案件そのものは提携先の制作会社へ委託しています。

よくある質問.

次に読む.

1. 01Drupalの代替ツールページの状況に応じて、アップグレード、分離、または移行をご検討ください。
2. 02Drupal から Next.js へコンテンツモデルをそのまま維持した状態で、分離または置換を行ってください。