Drupal 7を本番環境で実行し続けている場合、ぶっちゃけ言うと、あなたは時間を稼いでいるに過ぎません。Drupal 7は2025年1月5日に公式のサポート終了を迎えました。これは、当初の2021年11月の期限からさかのぼって、複数の延長を経ての終了です。つまり、もはやセキュリティパッチはなく、コミュニティサポートもなく、マイグレーションを次の四半期まで先延ばしにできる言い訳もありません。ここ数年、複数のエンタープライズチームがこの状況をどう切り抜けるかをサポートしてきた私の経験から、最後の期限まで待つチームほど、費用、ストレス、技術的負債の面でより多くを支払うことになっています。このガイドは、Drupal 7を実行し続けているエンジニアリング副社長に手渡したいと思うすべての情報です。

目次

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

Drupal 7サポート終了が実際に意味するもの

実務的な観点から「サポート終了」が何を意味するのかを正確に理解しましょう。ここで多くの混乱を見てきました：

  • セキュリティアップデートがもうない。 DrupalセキュリティチームはDrupal 7コアまたはcontribモジュールに対してセキュリティ勧告やパッチを発行しません。重大なSQLインジェクション脆弱性が明日発見されても、あなた自身で対応しなければなりません。
  • バグ修正がもうない。 壊れているものはそのままです。
  • Contribモジュールメンテナーは移行しています。 ほとんどはすでに移行しています。多くの人気のあるDrupal 7モジュールは何年も更新されていません。
  • ホスティングプロバイダーはサポートを打ち切ります。 Pantheon、Acquia、Platform.shはすべてDrupal 7ホスティング環境の廃止予定を発表しています。Aquiaは既存顧客向けに2026年までDrupal 7サポートを拡張していますが、これは長期的なソリューションではなく、有料の追加機能です。
  • PHP互換性の問題は複合します。 Drupal 7はPHP 5.xのために構築されました。パッチでPHP 8.1で実行されていますが、PHP 8.1自体は2025年12月に終了に達します。サポートされていないソフトウェアの上にサポートされていないソフトウェアを積み重ねることになります。

セキュリティリスクだけで行動をトリガーするのに十分です。あなたの組織がPII、財務データ、または健康情報のいかなる形式を処理する場合、パッチが当たっていないDrupal 7を実行することはコンプライアンスの責任です。PCI DSS、HIPAA、SOC 2はすべて、パッチが当たっているサポートされているソフトウェアを維持することを要求しています。

エンタープライズチームが遅延し続けた理由

この会話は数十回ありました。理由は常に次のようなバリエーションです：

  1. 「私たちのDrupal 7サイトはうまく機能しています。」 そうです。壊れるまでは。1月6日のコードは動かなくなりませんが、リスクプロファイルは劇的に変わります。
  2. 「Drupal 8/9/10へのマイグレーションは単純なアップグレードではありません。」 これは実際に本当です。Drupal 6→7アップグレードパスとは異なり、Drupal 7から最新Drupalへの移行は本質的に再構築です。アーキテクチャは根本的に異なります。Symfonyベース、構成管理、Twigテンプレート。カスタムモジュールは移植されません。
  3. 「私たちは15年分のコンテンツとカスタム機能があります。」 エンタープライズDrupal 7サイトは高度にカスタマイズされています。カスタムモジュール、Views構成、複雑なタクソノミー構造、レガシーシステムとの統合。マイグレーション範囲は本当に大きいです。
  4. 「予算が承認されませんでした。」 最も正直な答えで、最も一般的な答えです。

これらの理由のいずれもなくなりませんでしたが、期限は到着しました。では、実際に何をするかについて話しましょう。

2025年のマイグレーションオプション

現実的に4つのパスがあります。それぞれにトレードオフがあります。正直に説明します。

オプション タイムライン コスト範囲 最適な対象 リスクレベル
Drupal 10/11 6～18ヶ月 $200K-$1M+ Drupalエコシステムに投資しているチーム 中程度
ヘッドレスフロントエンド + Drupalバックエンド 4～12ヶ月 $150K-$600K モダンUXと使い慣れたCMSが欲しいチーム 中程度
ヘッドレスCMSマイグレーション 3～9ヶ月 $100K-$500K Drupalから完全に離れる準備ができているチーム 中～高
拡張サポートベンダー 即時 $30K-$100K/年 6～18ヶ月の追加計画時間が必要なチーム 低（短期）

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

オプション1: Drupal 10/11へのマイグレーション

Drupal 10は2025年現在の安定したリリースで、Drupal 11は2024年中頃にリリースされ、採用が進んでいます。あなたのチームがDrupalを知っていて、コンテンツモデルが堅牢で、エコシステムに留まりたい場合、これが最も簡単なパスです。

ただし「簡単」とは「簡単」という意味ではありません。

マイグレーションが実際に何を含むのか

Drupalはマイグレーションを提供します。APIは、Drupal 7データベースから内容をDrupal 10/11サイトにプルできます。私の経験では、典型的なマイグレーションの60～70％を処理します。残りはカスタムマイグレーションプラグインです：

  • カスタムフィールドタイプ
  • 複雑なエンティティ参照
  • Paragraphs（Paragraphsモジュールを使用した場合）
  • ファイルとメディアアセット
  • URLエイリアスとリダイレクト
  • ユーザーアカウントとロール

カスタムモジュールは書き直す必要があります。移植ではなく。書き直します。Drupal 10/11は完全に異なるアーキテクチャを使用しています。hook_node_view()にフックされたカスタムモジュールがあった場合、イベントサブスクライバーとプラグインを書いています。

// Drupal 7 - フックベース
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP、Symfonyベース
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // あなたのロジックはここへ
    }
  }
}

TwigテンプレートレイヤーもPHPTemplateから完全に異なっています。すべてのカスタムテーマは再構築が必要です。

現実的なタイムライン

中規模のエンタープライズサイト（500～5,000ページ、10～20コンテンツタイプ、5～10カスタムモジュール）の場合、9～15ヶ月を予想してください。これには発見、コンテンツモデリング、開発、コンテンツマイグレーション、QA、およびローンチが含まれます。

オプション2: モダンフロントエンドでのヘッドレス化

ここで物事は興味深くなります。正直なところ、2025年のエンタープライズチームに最も推奨するアプローチです。Drupalをコンテンツバックエンド（Drupal 10/11にアップグレード）として保つが、モダンJavaScriptフレームワークでフロントエンドを構築します。

Drupal 10/11は、コアに組み込まれた優れたJSON:APIサポートがあります。構造化データとしてコンテンツを公開し、Next.jsやAstro、またはその他のフロントエンドフレームワークで使用できます。

このアプローチがうまく機能する理由

  • 編集チームはDrupalの管理インターフェースを保つ。 彼らはそれを知っています。彼らはそれで生産的です。それを取り除くことは組織的な苦しみを引き起こします。
  • フロントエンドは劇的に高速になります。 静的生成、エッジキャッシング、モダンな画像最適化。Drupalのレンダリングレイヤーに装着するのは困難なことです。
  • 段階的にマイグレーションできます。 古いサイトの横に新しいフロントエンドを設定し、セクションを1つずつマイグレーションします。

我々はNext.jsとAstroを使用していくつかのヘッドレスDrupalフロントエンドを構築しており、パフォーマンスの向上は実質的です。1つのクライアントは、Next.jsフロントエンドとISR（増分静的再生成）に移行した後、最大のコンテンツフルペイント（LCP）を4.2秒から0.8秒に削減しました。

// DrupalのJSON:APIからフェッチするNext.jsページ
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR: 60秒ごとに再生成
  };
}

next-drupalパッケージ（Chapter Threeによって維持）は、プレビューモード、認証、およびコンテンツタイプマッピングの組み込みサポートでこれをさらに簡単にします。

注意点

バックエンドでDrupal 7をDrupal 10/11にマイグレーションする必要があります。その作業を回避していません。ただし、フロントエンド再構築から分離しているため、シーケンスでより多くの柔軟性があります。

オプション3: 完全にヘッドレスCMSに移行

時々、正しい動きはDrupalから完全に離れることです。チームがDrupal専門知識を持たない場合、Drupal開発者を雇うのに苦労している場合（2020年以来、Drupalの才能プールが大幅に縮小しているため、そうしています）、またはコンテンツモデルがDrupalが得意な領域を超えている場合、ヘッドレスCMSが正しい呼び出しであるかもしれません。

人気のあるマイグレーションターゲット

CMS 価格（2025年） 最適な対象 コンテンツAPI 学習曲線
Contentful $300-$2,500+/月 大規模な編集チーム GraphQL + REST 中程度
Sanity $99-$949+/月（カスタムエンタープライズ） 開発者主導のチーム GROQ + GraphQL 低～中
Storyblok $109-$449+/月 ビジュアル編集が必要 REST + GraphQL 低
Strapi（自己ホスト） 無料（自己ホスト）/ $29+/月（クラウド） コントロールが欲しいチーム REST + GraphQL 中程度
Payload CMS 無料（自己ホスト）/ $35+/月（クラウド） TypeScript最初のチーム REST + GraphQL 中程度

我々はこれらのいくつかをヘッドレスCMS開発プラクティスを通じて使用しています。正しい選択はチームの技術スキル、コンテンツの複雑さ、および予算によって異なります。

Drupal 7からヘッドレスCMSへのコンテンツマイグレーション

これは実際にはいくつかの方法でDrupal 10/11へのマイグレーションより簡単です。Drupalのマイグレーションフレームワークに制限されていません。典型的なアプローチ：

  1. Drushまたは直接データベースクエリを使用してDrupal 7コンテンツをエクスポート
  2. スクリプト（PythonとNode.jsの両方が機能）を使用してターゲットCMSのコンテンツモデルにデータを変換
  3. CMSの管理APIを使用してインポート
  4. 参照、メディア、および関係を確認して修正
# Drashを使用したシンプルなDrupal 7コンテンツエクスポート
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exported {len(articles)} articles")

難しい部分はエクスポートではありません。Drupal 7のコンテンツモデル（そのフィールドシステム、エンティティ参照、分類法用語、およびParagraphs）を新しいCMSのデータ構造にマッピングすることです。これが重要な分析時間を要することを計画してください。

オプション4: 拡張サポートベンダー（時間を買う）

本当により多くの時間が必要な場合（そしてそれはあります、特に予算サイクルと組織的優先順位がある場合）、拡張サポートベンダーは計画中にあなたのDrupal 7サイトをパッチを当てた状態に保つことができます。

Drupal 7拡張サポートを提供する主要ベンダー

  • Tag1 Consulting — 最も確立された1つ。彼らはセキュリティパッチをバックポートし、継続的なメンテナンスを提供します。価格はサイトの複雑さによって異なりますが、年間$30K-$80K予想してください。
  • Acquia — 彼らのプラットフォーム、現在エンタープライズ顧客向けに2026年までを通じてDrupal 7拡張サポートを提供。
  • mySociety / D7 LTS Contributors — Drupal 7拡張サポートプログラムを通じたコミュニティ主導の拡張サポート。

これは正当なブリッジ戦略です。長期的なソリューションではありません。最大12～18ヶ月でキャップしてください。Drupal 7に滞在する月ごとに、D7と最新プラットフォーム間のギャップが広がるにつれて、マイグレーション複雑さが増加します。

マイグレーション計画：段階的フレームワーク

これはすべてのエンタープライズマイグレーションで使用するフレームワークです。それは派手ではありませんが、それは機能します。

フェーズ1：監査（2～4週間）

  • コンテンツ監査： コンテンツタイプはいくつありますか？タイプごとのノードはいくつですか？コンテンツモデルの複雑さは何ですか？Paragraphsを使用していますか、フィールドコレクション、エンティティリファレンス？
  • モジュール監査： すべてのcontribおよびカスタムモジュールをリストアップ。次のように分類：D10相当物がある、カスタム置換が必要、削除できる。I use drush pm:list --status=enabled と drupal.org相互参照。
  • 統合監査： Drupalはどのような外部システムと通信していますか？支払いゲートウェイ、CRM、マーケティングオートメーション、SSOプロバイダー？
  • トラフィックとパフォーマンスのベースライン： 現在のパフォーマンスメトリクスを文書化。比較のために必要です。
  • ユーザーロール監査： 編集ワークフローはいくつ存在しますか？どのアクセス許可が重要ですか？

フェーズ2：アーキテクチャ決定（2～3週間）

監査に基づいて、4つのオプションのうちどれが正しいかを決定します。これは、エンジニアリングリーダーシップ、コンテンツステークホルダー、および予算を管理するすべての人を含むべき本当のアーキテクチャ決定です。

フェーズ3：概念実証（3～6週間）

完全なマイグレーションにコミットする前に、次のカバーする概念実証を構築してください：

  • 新しいプラットフォームに2～3コンテンツタイプをマイグレーション
  • 最も複雑な編集ワークフローを再現
  • 1つの重要な統合を接続
  • 新しいスタックのパフォーマンスベンチマーク

ここで、誰も監査中に言及しなかった物事を発見するでしょう。常に何かあります。

フェーズ4：完全マイグレーション（3～12ヶ月）

これが実際の作業です。徹底的に優先順位をつけます。Drupal 7からのすべてのコンテンツと機能が一緒に来る必要はありません。私の経験では、典型的なエンタープライズDrupal 7サイト上のコンテンツと機能の20～30％はマイグレーション中に排除できます。

フェーズ5：QAとローンチ（2～4週間）

リダイレクトが重要です。あなたのDrupal 7サイト上の検索エクイティを持つすべてのURLは301リダイレクトが新しいサイトに必要です。path_redirectとglobalredirectモジュールのエクスポートを開始点として使用し、Screaming Frogで古いサイトをクロールして完全なリダイレクトマップを構築します。

コンテンツマイグレーション戦略

コンテンツマイグレーションは、それ自体のセクションに値します。これはほとんどのマイグレーションが横道にそれるところです。

ボディフィールドの問題

Drupal 7のボディフィールドは、一般的にHTMLの混乱です。インラインスタイル、ハードコードされた画像パス、埋め込みiframe、そして場合によっては生のPHP（誰かがPHPフィルターモジュールを有効にした場合、本当のセキュリティ恐怖）が見つかります。マイグレーション前に、決定する必要があります：クリーンアップするか、混乱を移植するか？

私の推奨：クリーンアップする。変換スクリプトを書く：

  • インラインスタイルを削除
  • <img>タグを適切なメディア参照に変換
  • 内部リンクを新しいURL構造を使用するように修正
  • 任意のWYSIWYG埋め込みトークンを新しい形式に変換

メディアマイグレーション

Drupal 7サイトは非常に異なる方法でメディアを処理します。某些使用メディアモジュール（1.xまたは2.x）、ある純粋なファイルフィールド、あるメディアモジュール本文フィールド内の埋め込みトークンを使用します。マイグレーションコードを書き始める前に、すべてのメディア処理パターンをマップしてください。

ヘッドレスCMSに移行する場合、メディアファイルがどこに住むかを決定する必要があります。ほとんどのヘッドレスCMSには組み込みのアセット管理があるか、CloudinaryやImgixのようなDAMを使用できます。

多言語コンテンツ

あなたのDrupal 7サイトがi18n、entity_translation、またはcontent_translationを使用する場合、マイグレーション複雑さはおおよそ2倍になります。Drupal 7の多言語システムは...創造的と言いましょう。データ構造は一貫性がなく、慎重なマッピングが必要です。

コストとタイムライン推定

私が関与したか直接知識のあるプロジェクトに基づいて実数を提供します。

サイト複雑性 Drupal 10/11マイグレーション ヘッドレスCMSマイグレーション ヘッドレスフロントエンド + Drupalバックエンド
小（5～10コンテンツタイプ、<1Kページ、2～3カスタムモジュール） $80K-$150K、3～6ヶ月 $60K-$120K、2～4ヶ月 $100K-$180K、3～6ヶ月
中（10～20コンテンツタイプ、1K-10Kページ、5～10カスタムモジュール） $200K-$500K、6～12ヶ月 $150K-$350K、4～8ヶ月 $200K-$450K、5～10ヶ月
大（20+コンテンツタイプ、10K+ページ、10+カスタムモジュール、多言語） $500K-$1.5M+、12～24ヶ月 $300K-$800K、6～14ヶ月 $400K-$1M+、8～18ヶ月

これらは発見、開発、マイグレーション、QA、およびプロジェクト管理を含む完全にロードされたコストです。あなたの走行距離はチーム構成（社内対機関）、地理的位置、および移植済みでクリーンアップをいくらするかに基づいて異なります。

あなたの状況に対してより具体的な見積もりが欲しいですか？マイグレーション評価を実施し、範囲とコストの明確な画像を提供します。

チームが犯してきた一般的な誤り

1対1の再作成を試みる。 あなたのDrupal 7サイトは10年以上の劣化を蓄積しています。すべてを移行しないでください。マイグレーションを単純化する機会として使用してください。

リダイレクト努力を過小評価する。 45,000のURLをマップしなければならなかったマイグレーションで作業しました。2週間前までリダイレクトについて忘れていました。そのチームのようにしないでください。

編集ステークホルダーを早期に十分に関与させていない。 CMSを毎日使用する人々は新しいシステムについて強い意見を持つでしょう。フェーズ4ではなくフェーズ1で関与させてください。

プラットフォームをチーム機能ではなく機能に基づいて選択する。 最高のCMSはあなたのチームが実際に維持できるものです。Drupal専門知識がない場合、Drupal 10/11への採用はそれなしで雇用は5年で同じ状況の繰り返しをセットアップしています。

並行システムを長すぎる実行。 ハードカットオーバー日付を設定します。古いものと新しいものを並行して実行するのは費用がかかり、混乱しています。

コンテンツフリーズをスキップ。 最終的なマイグレーション プッシュ中、古いサイト上でコンテンツフリーズが必要です。計画してください。伝えてください。コンテンツ作成者はそれを嫌いますが、何も失われないことを確保するために必要です。

FAQ

サポート終了後Drupal 7を実行し続けると何が起こりますか？ あなたのサイトは突然動くのをやめません。ただし、セキュリティパッチを受け取りません。つまり、新しく発見された脆弱性はすべて無期限にパッチが当たらないままになります。これは本当のリスクです。Drupalサイトは自動攻撃の頻繁なターゲットです。古いPHPバージョンとのホスティングプロバイダーのサポート低下が、PHPバージョンが進むにつれて互換性の問題が増加します。コンプライアンス要件（PCI、HIPAA、SOC 2、GDPR）を持つ組織では、サポートされていないソフトウェアを実行することは直接違反です。

Drupal 7からDrupal 11に直接アップグレードできますか？ はい、マイグレーションAPIはDrupal 7からDrupal 10または11への直接マイグレーションをサポートしています。Drupal 8と9をステップスルーする必要はありません。ただし、これは従来の意味での「アップグレード」ではありません。これは新しいプラットフォーム上のサイトの再構築で、コンテンツはマイグレーションされています。テーマ、カスタムモジュール、構成は直接移携されません。

典型的なDrupal 7マイグレーションにはどのくらい時間がかかりますか？ 中規模のエンタープライズサイトの場合、キックオフからローンチまで6～12ヶ月を計画してください。カスタム機能が限られている小さいサイトは3～4ヶ月で完了できます。大規模で複雑なサイトで多言語コンテンツ、広範な統合、重い自分用化がある場合、12～24ヶ月かかる場合があります。監査フェーズはあなたの特定の状況に対してはるかに正確な見積もりを提供します。

Drupal 10/11にマイグレーションする価値があるか、CMSプラットフォームを切り替えるべきか？ チームとニーズに依存します。社内でDrupal専門知識がある場合、コンテンツモデルがDrupalのエンティティシステムに適している場合、およびDrupalの強み（複雑なアクセス許可、多言語、マルチサイト）が必要な場合、エコシステムにとどまることが意味があります。Drupal開発者の雇用に苦労している場合、サイトが主に複雑な編集ワークフローのないマーケティングサイトの場合、またはヘッドレスアーキテクチャに移動したい場合、別のCMSが確認するより良い投資かもしれません。

Drupal 7から移行する最も安い選択肢は何ですか？ Tag1（$30K-$80K/年）のようなベンダーからの拡張サポートは、最も安い短期選択肢ですが、根本的な問題を解決しません。実際のマイグレーション、SanityやStoryblobのようなヘッドレスCMSへの移行は、一般的に、静的フロントエンドを備えた人気のあるサイト、$60K-$120Kで開始する最も費用対効果が高いパスです。価格ページで、マイグレーションプロジェクトをどのように構造化するかについて詳しく知ってください。

マイグレーション中にSEOランキングに影響があるか？ 彼らはできますが、適切な計画は影響を最小限にします。重要な要因は：URL構造を維持している（またはインデックスされたすべてのURLに対して適切な301リダイレクトを実装）、メタデータと構造化データマークアップを保持、新しいサイトが少なくとも古いサイトと同じくらい速いロード（理想的には速い）、および更新されたサイトマップをGoogle Search Consoleに提出。適切に実行されたマイグレーションは、より良いページ速度とモバイルエクスペリエンスのためのSEO改善で終わりました。また、リダイレクトについて誰かが忘れたため、トラフィックを50％下げた悪いマイグレーションも見てきました。

段階的にコンテンツをマイグレーションするか、それはすべて一度にする必要があるか？ 段階的マイグレーションは可能で、大規模サイトでは多くの場合望ましいです。ヘッドレスアーキテクチャを使用して、新しいフロントエンドを立ち上げたり、リバースプロキシルールを使用してトラフィックを適切なバックエンドに的確にルーティングしながら、サイトのセクションを1つずつマイグレーションできます。これはリスクを低減し、各セクションを前に進める前に検証できます。トレードオフはマイグレーション期間中の増加した運用複雑さです。

WordPressをマイグレーションターゲットとして検討すべきか？ WordPressはシンプルなサイトに対して実行可能なオプションですが、エンタープライズのユースケースには慎重です。あなたのDrupal 7サイトが複雑なコンテンツタイプ、細粒度アクセス許可、または洗練された編集ワークフローを持つ場合、WordPressはダウングレードのように感じます。WordPressのコンテンツモデル（投稿、ページ、およびカスタム投稿タイプ）はDrupalのエンティティシステムより単純です。エンタープライズチームについては、Drupal 10/11または適切なヘッドレスCMSをより深刻に見検討してください。とはいえ、WordPressとACF Proおよびヘッドレスフロントエンドはマーケティング中心のサイトに対してうまく機能できます。