如果您仍在生產環境中執行 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 核心或貢獻模組發佈建議或補丁。如果明天發現了關鍵的 SQL 注入漏洞，您將自行承擔風險。
  • 不再有錯誤修復。 任何破損的功能將保持破損狀態。
  • 貢獻模組維護者正在轉向其他項目。 大多數已經轉向了。許多流行的 Drupal 7 模組已經多年沒有更新。
  • 主機服務提供商將停止支援。 Pantheon、Acquia 和 Platform.sh 都已宣佈了停用 Drupal 7 託管環境的時間表。Acquia 為現有客戶延長了 Drupal 7 支援至 2026 年，但這是一項付費附加服務，不是長期解決方案。
  • 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 個月 $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

截至 2025 年，Drupal 10 是目前的穩定版本，Drupal 11 於 2024 年中期發佈，並正在獲得廣泛採用。如果您的團隊對 Drupal 有所了解、您的內容模型是穩健的，並且您想留在生態系統中，這是最直接的前進路徑。

但"直接"並不意味著"簡單"。

遷移實際涉及的內容

Drupal 提供了 Migrate 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 的渲染層中的功能。
  • 您可以逐步遷移。 在舊網站旁邊建立新前端，並逐段遷移內容。

我們使用 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 的內容模型（其欄位系統、實體引用、分類術語和 Paragraphs）對應至新 CMS 的數據結構。規劃此項以花費大量分析時間。

選項 4：延長支援供應商（購買時間）

如果您真的需要更多時間——有時候您確實需要，尤其是在預算周期和組織優先事項方面——延長支援供應商可以在您規劃時保持您的 Drupal 7 網站修補狀態。

提供 Drupal 7 延長支援的主要供應商

  • Tag1 Consulting ——最成立的供應商之一。他們反向移植安全補丁並提供持續維護。定價因網站複雜性而異，但預計每年 $30K-$80K。
  • Acquia ——通過其平台提供延長的 Drupal 7 支援，目前為企業客戶提供至 2026 年。
  • mySociety / D7 LTS Contributors ——通過 Drupal 7 延長支援計畫的社群驅動延長支援。

這是一項合法的橋接策略，不是長期解決方案。我會將其限制在最多 12-18 個月。您在 Drupal 7 上停留的每一個月都會增加遷移複雜性，因為 D7 和現代平台之間的差距擴大。

遷移規劃：逐步框架

這是我用於每次企業遷移的框架。它並不華麗，但它有效。

階段 1：審計（2-4 週）

  • 內容審計： 有多少個內容類型？每個類型有多少個節點？內容模型複雜性如何？您是否使用了 Paragraphs、Field Collections、Entity Reference？
  • 模組審計： 列出所有貢獻和自訂模組。分類為：有 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 爬取舊網站以構建完整的重新導向對應。

內容遷移策略

內容遷移應該有自己的部分，因為這是大多數遷移出問題的地方。

body 欄位問題

Drupal 7 body 欄位通常是 HTML 的混亂。您會找到內聯樣式、硬編碼的圖像路徑、嵌入式 iframe，有時甚至是原始 PHP（如果有人啟用了 PHP 過濾器模組——一個真正的安全恐怖）。遷移之前，您需要決定：清理它，還是移植這個混亂？

我的建議：清理它。編寫轉換腳本，它們：

  • 去除內聯樣式
  • 將 <img> 標籤轉換為適當的媒體引用
  • 修復內部連結以使用新的 URL 結構
  • 將任何 WYSIWYG 嵌入令牌轉換為新格式

媒體遷移

Drupal 7 網站以廣泛不同的方式處理媒體。有些使用 Media 模組（1.x 或 2.x），有些使用平紋件欄位，有些在 body 欄位中使用嵌入式媒體令牌。在開始編寫遷移代碼之前對應每個媒體處理模式。

如果您轉移至無頭 CMS，您還需要決定媒體檔案在哪裡存放。大多數無頭 CMS 都有內置的資源管理，或者您可以使用 DAM，如 Cloudinary 或 imgix。

多語言內容

如果您的 Drupal 7 網站使用 i18n、entity_translation 或 content_translation，遷移複雜性大約翻倍。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 要對應。不要成為那個團隊。

沒有足夠早地涉及編輯利益相關者。 每天使用 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 等供應商的延長支援（$30K-$80K/年）是最便宜的短期選項，但它不能解決根本問題。對於實際遷移，轉移至無頭 CMS（如 Sanity 或 Storyblok）並使用靜態前端往往是較簡單網站最具成本效益的路徑，起價為 $60K-$120K。查看我們的 定價頁面，了解更多有關我們如何構建遷移項目的詳細資訊。

遷移會影響我的 SEO 排名嗎？ 它可以，但適當的規劃會最小化影響。關鍵因素是：維護 URL 結構（或為具有搜尋權益的每個索引 URL 實施適當的 301 重新導向）、保留元數據和結構化數據標記、確保新網站加載速度至少與舊網站一樣快（理想情況下更快），以及向 Google Search Console 提交更新的站點地圖。我見過執行良好的遷移導致 SEO 改進，因為更好的頁面速度和行動體驗。我也見過拙劣的遷移通過失去 50% 的流量使流量陷入困境，因為有人忘記了重新導向。

我可以逐步遷移內容或必須一次性完成？ 逐步遷移是可能的，對於大型網站通常更可取。使用無頭架構，您可以建立新前端，並逐段遷移網站的各個部分，使用反向代理規則將流量路由至適當的後端。這降低了風險，讓您在繼續之前驗證每個部分。權衡是遷移期間增加的操作複雜性。

我應該考慮 WordPress 作為遷移目標嗎？ WordPress 對於較簡單的網站是可行的選擇，但我對企業用途會謹慎。如果您的 Drupal 7 網站有複雜的內容類型、細粒度權限或複雜的編輯工作流程，WordPress 將感覺像是降級。WordPress 的內容模型（文章、頁面和自訂文章類型）比 Drupal 的實體系統更簡單。對於企業團隊，我會更認真地查看 Drupal 10/11 或適當的無頭 CMS。也就是說，具有 ACF Pro 和無頭前端的 WordPress 對於以行銷為重點的網站運行良好。