您的生產網站運行 Drupal 7，自 2025 年 1 月 5 日起，它停止接收安全修補程式。沒有緊急修復。沒有社群後盾。沒有更多擴充功能。過去十八個月，我帶領了六個企業團隊完成這項遷移，模式非常清楚：那些把它當作第四季核取清單的團隊比提前六個月規劃的團隊多付費 40-60%。延遲稅是真實的 — 不僅以美元計，還包括當工程師被迫在八週而非二十週內完成遷移時所繼承的技術債。這是我每當工程副總裁承認 Drupal 7 仍為其旗艦財產提供支援時，就交給他們的指南。您還不算晚，但窗口正在以比您的路線圖承認的更快速度關閉。

目錄

Drupal 7 終止支援 2025：企業團隊遷移指南

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. 「預算未獲批准。」 最誠實的答案，也是最常見的。

這些原因都沒有消失，但截止期限已到達。所以讓我們談談實際應該做什麼。

您在 2026 年的遷移選項

您有四條現實的前進路徑。每條都有權衡。讓我坦誠地分解它們。

| 選項 | 時間表 | 成本範圍 | 最適合 | 風險等級 | |--------|----------|-----------|----------|------------|| | 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 終止支援 2025：企業團隊遷移指南 - 架構

選項 1：遷移至 Drupal 10/11

截至 2026 年，Drupal 10 是目前的穩定版本，Drupal 11 於 2024 年中期發佈並獲得強勁採用。如果您的團隊懂 Drupal，您的內容模型是穩固的，並且您想留在生態系統中，這是最直接的路徑。

但「直接」不代表「簡單」。

遷移實際涉及的內容

Drupal 提供了一個遷移 API，可以將內容從 Drupal 7 資料庫提取到 Drupal 10/11 網站。根據我的經驗，它處理了典型遷移的大約 60-70%。其餘部分是以下自訂遷移外掛：

  • 自訂欄位類型
  • 複雜的實體參考
  • Paragraphs（如果您使用了 Paragraphs 模組）
  • 檔案和媒體資產
  • URL 別名和重定向
  • 使用者帳户和角色

您的自訂模組需要重寫。不是移植 — 重寫。Drupal 10/11 使用完全不同的架構。如果您有一個掛入 hook_node_view() 的自訂模組，您現在在編寫事件訂閱者和外掛。

// Drupal 7 - 基於 hook
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 - 物件導向、基於 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：使用現代前端的無頭部署

這是有趣的地方，坦誠地說，這是我對 2026 年企業團隊最常推薦的方法。保持 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 開發人員方面遇到困難（您是 — Drupal 人才庫自 2020 年以來已大幅萎縮），或者如果您的內容模型已超出 Drupal 擅長的範圍，無頭 CMS 可能是正確的選擇。

熱門遷移目標

| CMS | 定價（2026 年） | 最適合 | 內容 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 貢獻者 — 通過 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 爬行舊網站以構建完整的重定向映射。

內容遷移策略

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

主體欄位問題

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

我的建議：清理它。編寫轉換腳本，執行以下操作：

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

媒體遷移

Drupal 7 網站以千差萬別的方式處理媒體。有些使用 Media 模組（1.x 或 2.x），有些使用純檔案欄位，有些在主體欄位中使用嵌入的媒體令牌。在開始編寫遷移代碼之前，繪製每個媒體處理模式。

如果您遷移到無頭 CMS，您還需要決定媒體檔案的位置。大多數無頭 CMS 具有內置資產管理，或者您可以使用 Cloudinary 或 imgix 等 DAM。

多語言內容

如果您的 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 是您的團隊實際能夠維護的 CMS。如果您沒有 Drupal 專業知識，遷移至 Drupal 10/11 而不為此招聘是在五年後重複這種情況。

並行執行系統太長。 設置硬截止日期。並行執行舊系統和新系統很昂貴且令人困惑。

跳過內容凍結。 在最後遷移推送期間，您需要對舊網站的內容凍結。計劃好。溝通好。內容作者討厭它，但它對於確保沒有任何東西丟失是必要的。

常見問題

如果終止支援後我仍然執行 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 或 Storyblok 等無頭 CMS 與靜態前端傾向於是更簡單網站最具成本效益的路徑，從 $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 對於以市場營銷為重點的網站運行良好。