Drupal 移行は、期限が迫るまで来期の計画に居座り続けるたぐいのプロジェクトです。いま、その役割を果たしている日付が二つあり、まだ先にあるのは片方だけです。

Drupal 7 は 2025年1月5日に公式サポートを終了しました。いまだにそれで動いているサイトは、一年以上にわたってセキュリティの手当てがない状態で運用されていることになります。Drupal 10 は 2026年12月9日に提供終了を迎えます。Drupal 12 がリリースされるのと同じ週であり、それ以降はいかなる種類のリリースも届きません。どちらのバージョンを使っているとしても、問いはもはや移るかどうかではなく、どの経路を選び、いくらかかるのかです。

いまの立ち位置: Drupal 10 から Drupal 11 へは本物のアップグレードです。同じサイトをその場で更新するもので、通常は二週間から六週間で終わります。Drupal 7 から Drupal 11 へは、そもそもアップグレードではありません。コンテンツ移行を伴う作り直しであり、通常は三か月から六か月かかります。この二つを混同することが、この領域でもっとも高くつく誤りです。Drupal 7 のサイトがアップグレードとして見積もられ、そのあと四倍に膨らむからです。

まったく異なる二つの移行

移行という言葉は、名前以外にほとんど共通点のない二つの仕事を覆っています。

Drupal 10 から 11 はアップグレードです。 アーキテクチャは同じままです。エンティティ、フィールド、ビュー、設定はそのまま引き継がれます。作業の大半は依存関係の管理です。つまり、利用しているコントリビュートモジュールのすべてに Drupal 11 対応のリリースがあることを確かめ、カスタムコードから非推奨 API の呼び出しを取り除き、サポート対象の PHP バージョンへ移ることです。難しいというより手続き的な作業であり、よく手入れされたサイトなら二週間ほどで片づきます。

Drupal 7 から Drupal 11 は作り直しです。 Drupal 8 はプラットフォームを Symfony のコンポーネント上に書き直し、モジュール API、テーマ層、設定システムを置き換えました。コンテンツ以外は何も自動的には引き継がれず、そのコンテンツでさえアップグレードスクリプトではなく専用の移行処理を通ってやってきます。かつてのモジュールはもう存在せず、テーマは Twig で書き直す必要があり、カスタムコードは異なるアーキテクチャの上で実装し直すことになります。

この二つ目のケースこそ、Drupal 7 のサイトがこれほど長く残ってきた理由です。正直に言い直すなら、サイトをアップグレードしているのではありません。新しいサイトを作り、そこへコンテンツを連れていくのです。

Drupal 移行の各経路にかかる費用

以下の数字は、英国の制作会社の料金水準と、複雑さが中程度のサイトを前提としています。ここでいう複雑さとは、ページ数ではなく、コンテンツタイプ、コントリビュートモジュール、カスタムモジュールの数を指します。

Drupal 10 から 11、よく手入れされたサイト。 二週間から四週間、おおよそ 6,000 から 15,000 ポンド。これは幸運なケースです。モジュールは最新で、カスタムコードは少なく、作業の中心はテストになります。

Drupal 10 から 11、放置されたサイト。 四週間から八週間、おおよそ 15,000 から 35,000 ポンド。ここで足を引っ張るのは、Drupal 11 向けリリースのないコントリビュートモジュール、すでに削除された API に対して書かれたカスタムコード、そして同時に上げなければならない PHP のバージョンです。放棄されたモジュールはひとつひとつが判断を迫ります。代替を探すか、自分たちで保守を引き受けるか、その振る舞いを作り直すかです。

Drupal 7 から Drupal 11。 三か月から六か月、一般に 40,000 から 120,000 ポンド、規模の大きいサイトや作り込みの多いサイトではそれ以上になります。幅が広いのは、これが実際には作り直しの予算だからです。コンテンツ移行そのものはむしろ小さい方の半分で、テーマ、独自機能、外部連携が大きい方の半分を占めます。

Drupal 7 から別のプラットフォームへ。 これが正解のこともあります。Drupal を選んだ当初の理由がもう当てはまらないなら、たとえばサイトが実質的にブログ付きの会社案内になっているなら、より単純な仕組みへ移る方が Drupal の中で移行するより安くつき、その後の運用費も下げられます。WordPress とフルスクラッチ開発の比較 ではその境目がどこにあるかを扱っていますし、Drupal ウェブ開発ガイド は Drupal が答えにならない場面についても率直に書いています。

コントリビュートモジュールが日程を決める理由

Drupal のアップグレード見積もりは、ほぼ例外なくコントリビュートモジュールの棚卸しで生き死にが決まります。そして、それは最初に手をつける価値のある作業です。

サイトが使っているコントリビュートモジュールをすべて書き出し、それぞれについて移行先バージョンに対応した安定版があるかを確認してください。出てくるものは四つのグループに分かれます。対応リリースがあり、何もしなくてよいもの。リリース候補版や課題キューのパッチがあり、Composer 経由で適用できるもの。放棄されており、代替を探すか、自分たちでモジュールを引き取るか、その機能をカスタムコードで置き換えるしかないもの。そして Drupal のコアに取り込まれたもので、これがこの作業における嬉しい驚きです。

この棚卸しは、漠然としたプロジェクトを数えられるプロジェクトへ変えます。これが済むまで、どんな見積もりも推測にすぎません。棚卸しを経ずに固定価格を出してくる業者は、大きく上乗せしているか、あとから変更依頼を連発するかのどちらかです。

同じ理屈がカスタムモジュールにも当てはまりますが、使う道具は変わります。Drupal の非推奨検出ツールはカスタムコードを走査し、削除済みまたは削除予定の API 呼び出しを報告してくれます。これが「うちには多少カスタムコードがある」という話を、ファイル名と行番号の具体的な一覧に変えてくれます。

実際に何がうまくいかないのか

ほとんどすべての Drupal 移行で、決まった失敗の型が繰り返し現れます。

環境間の設定のずれ。 変更が設定ファイルへ書き出されず、本番の管理画面で直接行われてきたのなら、ステージング環境は忠実な複製ではなく、テストの価値は思っているより低くなります。これを移行の途中で発見するのはよくあることで、必ず時間を食います。

誰もが思っていたほど構造化されていなかったコンテンツ。 Drupal 7 のサイトは、誰も文書化しなかったやり方でコンテンツを積み上げてきたことがよくあります。本来と違う用途に流用されたフィールド、ワークフローの状態管理の代わりを務めているタクソノミー、インラインスタイルごと本文フィールドに貼り込まれた HTML といった具合です。移行はそれらを一度に表へ出し、ひとつひとつについて、そのコンテンツが何のためにあるのかを知っている人の判断を求めます。

メディアとファイルの扱い。 Drupal のメディア管理は Drupal 7 以降で大きく変わりました。ファイル、画像スタイル、埋め込みメディアが一対一で対応することはまれで、大きなメディアライブラリを抱えるサイトは、この部分をコンテンツ移行に含まれるものと決めつけず、独立した工数として見積もるべきです。

URL と検索順位の連続性。 ここは日程ではなく事業そのものを傷つける項目です。URL エイリアスがリダイレクトなしに変われば、旧サイトが積み上げた検索順位を失います。どの移行でも、URL の完全な棚卸し、リダイレクトの対応表、公開後の検証が必要になります。トラフィックを落とさずにサイトを移行する方法 についての当社のガイドがその手順を詳しく扱っており、ドメイン変更と同じくプラットフォーム変更にも当てはまります。

多言語コンテンツ。 サイトが複数の言語で動いているなら、移行にかかる時間はかなり延びると考えてください。言語の扱いは Drupal 7 以降で作り直されており、翻訳されたコンテンツ、翻訳された設定、言語ごとの URL 規則が、それぞれ個別の手当てを要求します。

作業をどう並べるか

順序は多くのチームが思っている以上に効いてきますし、間違えるとやり直しが発生します。

まずコントリビュートモジュールとカスタムコードの棚卸しから始めます。見積もりよりも前です。次にサイトをサポート対象の PHP バージョンと、いま使っているメジャーバージョンの最新リリースへ載せ替えます。これだけで、本番のアップグレード作業から雑音の一群が消えます。メジャーバージョンの引き上げに手をつけるのは、そのあとです。

その場で上書きするのではなく、新しい環境を旧環境の隣に構築してください。そうすればコンテンツ移行を何度も試せる場所ができます。そして、それは必ず必要になります。移行は、本番で一度実行される前に、何度も実行されるものだからです。

コンテンツ移行はコードとして扱ってください。Drupal の移行フレームワークは、移行の定義を設定として書き、繰り返し実行できるようにしてくれます。つまり、いったん白紙に戻し、対応付けを直し、もう一度走らせられるということです。移行定義を直す代わりに新サイト側でコンテンツを手作業で直したチームは、やがて再実行できなくなり、旧サイトのわずかなコンテンツ変更が手作業の突き合わせに変わってしまいます。

最後に、終盤でコンテンツの凍結期間を設け、それを短く保ってください。凍結が長引くと編集担当者は回避策を取りはじめ、まさに避けたかったずれが生まれます。

そもそも Drupal をやめるべきか

もっともな問いですし、身構えた答えではなく正直な答えに値します。

Drupal を選んだ理由がいまも通用するなら、そのまま留まってください。複雑なコンテンツモデル、細かい権限制御、多言語の要件、重い編集ワークフロー、あるいはアクセシビリティや公共部門としての義務といったものです。Drupal はこれらすべてで本当に強く、ここから先のアップグレード経路は二年ごとのメジャーリリースという予測可能な形で安定しています。

サイトがそうした要件から離れてしまったのなら、移ることを検討してください。少なくない Drupal 7 のサイトは、いまや実態としてお知らせと問い合わせフォームのある会社案内です。それを Drupal の中で移行するのは、もう使っていない能力に対して作り直しの代金を払うことになります。

判断の軸はコンテンツモデルと編集作業の負荷であって、開発者の好みではありません。より単純なプラットフォームでは実現できないことを Drupal が何かしてくれている、と誰も言葉にできないのなら、それ自体がひとつの答えです。

見積もりの前に棚卸しを

Mecanik は Drupal のアップグレードと移行をウェブサイト開発サービス の一部として引き受けています。私たちはコントリビュートモジュールとカスタムコードの棚卸しから始めます。それが終わりの見えないプロジェクトを固定された範囲へ変えるものであり、そのあと作業を別のところへ任せるとしても、持っておく価値があるからです。

Drupal 10 のサイトなら、賢明なのは全員が動き出す 11 月ではなく、いま Drupal 11 への一歩を計画することです。Drupal 7 のサイトなら、セキュリティの状況そのものがすでに理由になっています。制約が技術力ではなく人手なのであれば、Drupal 開発者の採用 についての当社のガイドが、何を見るべきかを扱っています。

いまどのバージョンを使っていて、コントリビュートモジュールとカスタムモジュールがおおよそいくつあるかを教えてください。上に挙げた経路のうち、実際にどれに直面しているのかをお伝えします。

関連記事: レガシーPHPモダナイゼーション：2026年ガイド 、Symfony vs Laravel 2026: どちらのPHPフレームワーク 、APIセキュリティ：公開APIを守る2026年の実践 、英国における医療・ヘルスケアウェブサイト開発 2026 。

よくある質問

Drupal 10 のサポートはいつ終わりますか？ Drupal 10 は 2026年12月9日に提供終了を迎えます。Drupal 12 がリリースされるのと同じ週です。その日以降はセキュリティ修正を含めていかなるリリースも提供されません。そこに留まるサイトは、サポートのない状態で動き続けることになります。

Drupal の移行費用はいくらかかりますか？ よく手入れされたサイトでの Drupal 10 から 11 へのアップグレードは、通常 6,000 から 15,000 ポンドです。モジュールとカスタムコードが放置されている場合は 15,000 から 35,000 ポンドまで上がります。Drupal 7 から Drupal 11 はコンテンツ移行を伴う作り直しで、一般に 40,000 から 120,000 ポンド、あるいはそれ以上になります。

なぜ Drupal 7 から Drupal 11 はこれほど高いのですか？ それがアップグレードではないからです。Drupal 8 はプラットフォームを Symfony のコンポーネント上に作り直し、モジュール API、テーマ層、設定システムを置き換えました。モジュールは差し替え、テーマは Twig で書き直し、カスタムコードは実装し直す必要があります。コンテンツは専用の移行処理を通して運び込むことになります。

Drupal 10 から 11 へのアップグレードにはどれくらいかかりますか？ コントリビュートモジュールが最新でカスタムコードが少ないサイトなら、二週間から四週間です。放棄されたモジュールや削除済み API を回避する必要がある場合は、四週間から八週間になります。見積もりを信頼できるものにするのは、事前に行うコントリビュートモジュールの棚卸しです。

代わりに Drupal から WordPress へ移行できますか？ それが正しい判断のこともあります。とくに Drupal 7 のサイトが、複雑なコンテンツモデルも細かい権限も多言語要件もない単純な会社案内になっている場合です。判断はプラットフォームの好みではなく、自社のコンテンツモデルと編集作業の負荷に基づいて行ってください。