Drupal 7 终止支持 2025：企业团队迁移指南

如果你仍在生产环境中运行 Drupal 7，我不会粉饰事实：你已经在透支时间。Drupal 7 在 2025 年 1 月 5 日正式终止支持，之前已经多次延期，最初截止日期是 2021 年 11 月。这意味着不再有安全补丁，不再有社区支持，不能再假装迁移可以推到下一季度。过去几年，我帮助多个企业团队度过了这种困境，那些等到最后一刻的团队总是付出了更高的代价——金钱、压力和技术债务。这份指南是我希望能交给每个仍在运行 Drupal 7 的工程副总裁的一切内容。

目录

• Drupal 7 终止支持的实际含义
• 为什么企业团队一直在延迟
• 2025 年的迁移选项
• 选项 1：迁移到 Drupal 10/11
• 选项 2：采用现代前端的无头架构
• 选项 3：完全迁移到无头 CMS
• 选项 4：扩展支持供应商（购买时间）
• 迁移规划：分步框架
• 内容迁移策略
• 成本和时间评估
• 我见过的常见错误
• 常见问题

Drupal 7 终止支持的实际含义

让我们精确地了解"生命周期结束"在实践中意味着什么，因为我在这里看到了很多困惑：

• 不再有安全更新。 Drupal 安全团队不会为 Drupal 7 核心或贡献模块发布安全公告或补丁。如果明天发现严重的 SQL 注入漏洞，你就自己处理。
• 不再有错误修复。 任何损坏的东西都会保持损坏状态。
• 贡献模块维护者正在离开。 大多数已经离开了。许多流行的 Drupal 7 模块多年未见更新。
• 托管提供商将停止支持。 Pantheon、Acquia 和 Platform.sh 都已宣布弃用 Drupal 7 托管环境的时间表。Acquia 通过 2026 年为现有客户延长了 Drupal 7 支持，但这是付费附加功能，不是长期解决方案。
• PHP 兼容性问题将复合。 Drupal 7 是为 PHP 5.x 构建的。它通过补丁在 PHP 8.1 上运行，但 PHP 8.1 本身在 2025 年 12 月到期。你将在不受支持的软件上堆叠不受支持的软件。

仅安全风险就应该足以触发行动。如果你的组织处理任何形式的个人身份信息、财务数据或健康信息，运行未修补的 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 年的迁移选项

你有四条现实的前进道路。每条都有权衡。让我诚实地分解它们。

选项	时间表	成本范围	最适合	风险等级
Drupal 10/11	6-18 个月	20 万-100 万美元+	投资于 Drupal 生态系统的团队	中等
无头前端 + Drupal 后端	4-12 个月	15 万-60 万美元	希望在熟悉的 CMS 中实现现代 UX 的团队	中等
无头 CMS 迁移	3-9 个月	10 万-50 万美元	准备完全离开 Drupal 的团队	中等-高
扩展支持供应商	立即	3-10 万美元/年	需要 6-18 个月额外规划时间的团队	低（短期）

选项 1：迁移到 Drupal 10/11

截至 2025 年，Drupal 10 是当前稳定版本，Drupal 11 在 2024 年年中发布，正在增加采用。如果你的团队了解 Drupal，你的内容模型很扎实，并且你想继续留在生态系统中，这是最直接的路径。

但"直接"并不意味着"容易"。

迁移实际涉及的内容

Drupal 提供了一个 Migrate API，可以将内容从 Drupal 7 数据库拉入 Drupal 10/11 网站。根据我的经验，它处理大约 60-70% 的典型迁移。其余的是自定义迁移插件，用于：

• 自定义字段类型
• 复杂的实体引用
• 段落（如果你使用了 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 呈现层绑定的痛点。
• 你可以增量迁移。 将新前端与旧网站并排运行，并一次迁移一个部分。

我们已经用 Next.js 和 Astro 构建了几个无头 Drupal 前端，性能改进很大。一个客户在迁移到带有 ISR（增量静态重新生成）的 Next.js 前端后，看到他们的最大内容绘制从 4.2 秒下降到 0.8 秒。

// Next.js 从 Drupal 的 JSON:API 获取页面
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. 使用脚本将数据转换为目标 CMS 的内容模型（Python 和 Node.js 都可以）
3. 通过 CMS 的管理 API 导入
4. 验证和修复引用、媒体和关系

# 通过数据库进行简单的 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"导出了 {len(articles)} 篇文章")

难的部分不是导出。而是将 Drupal 7 的内容模型（带有其字段系统、实体引用、分类法术语和段落）映射到新 CMS 的数据结构。为此计划花费大量的分析时间。

选项 4：扩展支持供应商（购买时间）

如果你真的需要更多时间——有时你确实需要，特别是考虑到预算周期和组织优先事项——扩展支持供应商可以在你规划的同时保持你的 Drupal 7 网站受补丁保护。

提供 Drupal 7 扩展支持的主要供应商

• Tag1 Consulting —— 最成熟的之一。他们反向移植安全补丁并提供持续维护。定价因网站复杂性而异，但预期 3 万-8 万美元/年。
• Acquia —— 为他们的平台提供扩展 Drupal 7 支持，目前通过 2026 年为企业客户提供。
• mySociety / D7 LTS 贡献者 —— 社区驱动的扩展支持，通过 Drupal 7 扩展支持计划提供。

这是一个合法的桥接策略，不是长期解决方案。我会将其上限设定为 12-18 个月。你在 Drupal 7 上停留的每一个月都会增加你的迁移复杂性，因为 D7 和现代平台之间的差距在扩大。

迁移规划：分步框架

这是我用于每次企业迁移的框架。它不是光彩夺目的，但它有效。

第 1 阶段：审计（2-4 周）

• 内容审计： 有多少个内容类型？每个类型有多少个节点？内容模型复杂性如何？你使用段落、字段集合、实体引用吗？
• 模块审计： 列出每个贡献和自定义模块。分类为：有 D10 等效项、需要自定义替换、可以消除。我使用 drush pm:list --status=enabled 并与 drupal.org 交叉引用。
• 集成审计： Drupal 与哪些外部系统交互？支付网关、CRM、营销自动化、SSO 提供商？
• 流量和性能基线： 记录当前性能指标。你需要这些进行比较。
• 用户角色审计： 存在多少编辑工作流？哪些权限很重要？

第 2 阶段：架构决策（2-3 周）

基于你的审计，决定四个选项中的哪一个是正确的。这是一个真正的架构决策，应该涉及工程领导、内容利益相关者和控制预算的人。

第 3 阶段：概念证明（3-6 周）

在承诺完全迁移之前，构建一个概念证明，涵盖：

• 2-3 个内容类型迁移到新平台
• 最复杂的编辑工作流被重现
• 一个关键集成已连接
• 新堆栈的性能基准

这是你会发现没有人在审计中提到的东西的地方。总有什么东西。

第 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 都有内置的资产管理，或者你可以使用 DAM（如 Cloudinary 或 imgix）。

多语言内容

如果你的 Drupal 7 网站使用 i18n、entity_translation 或 content_translation，迁移复杂性大约会翻倍。Drupal 7 的多语言系统是……让我们说它"有创意"。数据结构不一致，需要仔细映射。

成本和时间评估

我将根据我参与过或直接了解的项目提供真实数据。

网站复杂性	Drupal 10/11 迁移	无头 CMS 迁移	无头前端 + Drupal 后端
小（5-10 个内容类型、<1K 页面、2-3 个自定义模块）	8 万-15 万美元，3-6 个月	6 万-12 万美元，2-4 个月	10 万-18 万美元，3-6 个月
中等（10-20 个内容类型、1K-10K 页面、5-10 个自定义模块）	20 万-50 万美元，6-12 个月	15 万-35 万美元，4-8 个月	20 万-45 万美元，5-10 个月
大（20+ 个内容类型、10K+ 页面、10+ 个自定义模块、多语言）	50 万-150 万美元+，12-24 个月	30 万-80 万美元，6-14 个月	40 万-100 万美元+，8-18 个月

这些都是完整成本，包括发现、开发、迁移、QA 和项目管理。你的实际情况将因团队组成（内部与代理）、地理位置以及你如何清理与移植现状而异。

想为你的情况获得更具体的估计？我们提供 迁移评估，为你提供清晰的范围和成本图景。

我见过的常见错误

尝试进行 1:1 重创。 你的 Drupal 7 网站已经积累了 10 多年的杂乱。不要迁移所有这些。使用迁移作为一个简化的机会。

低估重定向工作。 我参与了一次迁移，其中团队直到启动前两周才想到重定向。他们有 45,000 个 URL 要映射。不要成为那个团队。

没有及早涉及编辑利益相关者。 每天使用 CMS 的人对新系统会有强烈的看法。在第 1 阶段参与他们，而不是第 4 阶段。

根据功能而不是团队能力选择平台。 最好的 CMS 是你的团队能够实际维护的那个。如果你没有 Drupal 专业知识，迁移到 Drupal 10/11 而不为其招聘是在为这种情况的重复设置 5 年的场景。

运行并行系统太长时间。 设定一个硬停止日期。运行旧的和新的并行是昂贵和困惑的。

跳过内容冻结。 在最后迁移推动期间，你需要对旧网站进行内容冻结。为此计划。沟通它。内容作者讨厌它，但这是必要的，以确保没有任何东西丢失。

常见问题

如果我在生命周期结束后继续运行 Drupal 7 会发生什么？ 你的网站不会突然停止运行。但你将不会收到安全补丁，这意味着任何新发现的漏洞都将无限期地保持未修补状态。这是一个真正的风险——Drupal 网站是自动化攻击的频繁目标。你还会面临越来越多的兼容性问题，因为 PHP 版本的进步和托管提供商放弃对旧 PHP 版本的支持。对于任何有合规要求的组织（PCI、HIPAA、SOC 2、GDPR），运行不受支持的软件是直接违反。

我能直接从 Drupal 7 升级到 Drupal 11 吗？ 是的，Migrate 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 等供应商的扩展支持（3 万-8 万美元/年）是最便宜的短期选项，但它不能解决根本问题。对于实际迁移，迁移到像 Sanity 或 Storyblok 这样的无头 CMS，带有静态前端，往往对更简单的网站来说是最具成本效益的路径，起价约 6 万-12 万美元。查看我们的 定价页面 了解我们如何组织迁移项目。

迁移会影响我的 SEO 排名吗？ 可以，但适当的规划可以将影响最小化。关键因素是：维护 URL 结构（或为每个索引 URL 实现适当的 301 重定向）、保留元数据和结构化数据标记、确保新网站加载速度至少与旧网站一样快（理想情况下更快），以及向 Google Search Console 提交更新的站点地图。我见过执行良好的迁移因更好的页面速度和移动体验而导致 SEO 改进。我也见过拙劣的迁移由于某人忘记了重定向而导致流量下跌 50%。

我能逐步迁移内容还是必须全部一次性进行？ 增量迁移是可能的，通常对大型网站更优选。使用无头架构，你可以站起新的前端并一次迁移网站的一部分，使用反向代理规则将流量路由到相应的后端。这降低了风险，并让你在继续之前验证每个部分。权衡是在迁移期间增加运营复杂性。

我应该考虑 WordPress 作为迁移目标吗？ WordPress 对于更简单的网站是一个可行的选择，但我对企业用例持谨慎态度。如果你的 Drupal 7 网站有复杂的内容类型、细粒度权限或复杂的编辑工作流，WordPress 会感觉像降级。WordPress 的内容模型（文章、页面和自定义文章类型）比 Drupal 的实体系统更简单。对于企业团队，我会更认真地看待 Drupal 10/11 或适当的无头 CMS。也就是说，带有 ACF Pro 的 WordPress 和无头前端对于以营销为重点的网站可以很好地工作。