Drupal 12：變化內容與搬遷時機

Drupal 12 預定在 2026年12月7日那一週推出，而 Drupal 10 會在 2026年12月9日走到生命週期終點。這兩個日期就印在 Drupal 核心發布時程的同一頁上，中間只隔兩行，可是絕大多數正在經營 Drupal 10 網站的人，兩個都沒注意到。新大版本的第一個 alpha 已經在 2026年9月2日打上標籤，所以這次發布的樣貌現在是有案可稽的事實，而不是臆測。

這場對撞就是整篇文章的重點。一個大版本問世，對網站擁有者來說通常並不急迫，因為你大可在舊的大版本上待個一兩年，等生態系跟上。這一次不一樣，舊的大版本會在新版本推出的同一週停止收到安全公告，於是一個技術事件變成一個帶著法遵鋒刃的期限。

以下要談的是 drupal.org 公布的行事曆、程式碼裡真正改了什麼、新的平台門檻對主機提出什麼要求、三條務實的升級路線以及各自的費用區間，還有一份從12月倒推的計畫。讓人安心的部分先講：Drupal 大版本更新的絕大部分是刪除，而不是重新發明。

Drupal 12 什麼時候問世，我一定要搬嗎？ Drupal 12.0.0 預定在 2026年12月7日那一週推出，與 Drupal 11.5.0 一同發布。Drupal 10 在兩天後，也就是 2026年12月9日走到生命週期終點，此後不再為它發出任何安全公告。Drupal 11 網站面對的是一次小升級。Drupal 10 網站必須先經過 Drupal 11.4 或更新的版本，所以這件事是兩段跳，而不是一段。

決定你未來半年的兩個日期

發布經理會事先公布整個週期，這一輪安排得格外整齊。Drupal 11.4.0 在 2026年6月29日那一週落地，該版本同時終結了 Drupal 11.2.x 與 Drupal 10.5.x 的安全支援。12.0.0-alpha1 的標籤打在 2026年9月2日。測試版要件必須在 2026年9月11日前備妥，12.0.0-beta1 與 11.5.0-beta1 排在9月14日那一週，候選版本排在11月9日那一週。

接著12月7日那一週會同時發生三件事。Drupal 12.0.0 推出，Drupal 11.5.0 一同推出，Drupal 11.3.x 與 Drupal 10.6.x 的安全支援結束。兩天後，也就是 2026年12月9日，Drupal 10 整體走到生命週期終點，此後不會再有任何版本被製作出來。

為什麼 Drupal 10 與 Drupal 12 會落在同一週

這是政策，不是巧合。發布流程總覽寫明，大版本每兩年於偶數年推出，而每個大版本至少支援四年，直到後續又有兩個大版本問世為止。Drupal 10.0.0 於 2022年12月15日推出。Drupal 11 在 2024年8月到來，Drupal 12 在 2026年12月到來，後者正是那第二個後續大版本，而四年也確實過去了。這個時鐘剛好照表走完。

同一套政策也管著小版本。每個小版本支援一年，前六個月提供錯誤修正與安全修正，後六個月只提供安全修正。這就是為什麼今天只有 10.6.x 還收得到公告，也是為什麼 11.5.0 一推出，11.3.x 就失去保護。

Drupal 11 不會因為 Drupal 12 開始而停下。在同一週推出 11.5.0，代表政策所稱的長期支援階段開始：舊的大版本保留一個 API 對齊的小版本，轉到 Symfony 的 LTS 版本上，並且每六個月收到一次範圍逐漸收窄的維護版本。drupal.org 沒有公布 Drupal 11 確切的終止日期，不過它自己的已淘汰擴充功能文件寫著 Drupal 11 將支援到 2028年中期至後期。

還有多少網站留在 Drupal 10 上

數字是公開的，而且不好看。drupal.org 的核心使用統計顯示，在 2026年8月23日開始的那一週，共有 468,877 個網站回報了核心版本。其中 205,568 個位於 Drupal 10 的某個分支，168,857 個位於 Drupal 11。已回報安裝量中大約 44% 落在12月起收不到公告的那個版本上。

更尖銳的數字藏在這個數字裡面。還有安全涵蓋的只剩 10.6.x，而 10.6.x 佔了其中 139,911 個網站。剩下的 65,657 個位於 10.0 到 10.5 之間，也就是說它們今天、在這個9月，就已經跑在一個不受支援的小版本上，根本不必等到12月。

這些計數來自透過 Update Status 模組自願回報的網站，所以真實母數更大，而傾斜方向一樣。務實地讀，就是會有非常多的組織想在同一季預約同一批升級工作，而10月與11月的瓶頸會是服務商的人力，而不是程式碼。

生命週期終點對一個 Drupal 網站究竟意味著什麼

生命週期終點不是一個把網站弄壞的開關。你的 Drupal 10 安裝在12月10日照樣會像12月8日那樣把頁面送出去。改變的是 Drupal 安全團隊不再為那份程式碼發布公告與修補，因此從那天起，Drupal 10 核心裡每一個新發現的漏洞都會永久敞開。

第二個效應更慢，破壞力更大。貢獻模組的安全涵蓋，取決於該模組在受支援的核心分支上有沒有穩定版本，所以當維護者陸續放掉 Drupal 10 相容性時，你網站上的模組也會悄悄退出公告流程。發生這件事時你不會收到通知。模組只是不再出現在安全發布裡，而你自己網站上的可用更新報告看起來依舊是綠的。

第三個效應是，拖得越久出口越貴。一個在11月升級的 Drupal 10 網站，面對的是仍在維護的核心分支與一條可用的更新路徑。同一個網站若拖到隔年6月才升級，那就是一個搶救專案，因為它依賴的貢獻模組又多走了六個月，卻沒帶上它。

Cyber Essentials、保險與合約條款

到這裡，一套不受支援的 CMS 就不再只是工程問題了。NCSC 的 IT 基礎架構 Cyber Essentials 要求 v3.3日期為 2026年4月，規定範圍內裝置上的所有軟體都必須具備授權且受支援，一旦失去支援就必須從裝置上移除，或者用一個阻擋所有對外網際網路流量的既定子集把它移出範圍。該控制項適用於伺服器、IaaS、PaaS 與 SaaS，所以裝在範圍內伺服器上的 Drupal 是正面命中的。

一個面向公眾的 Drupal 10 網站不可能被隔絕在網際網路之外，所以 2026年12月9日之後可用的答案只有兩個：升級它，或者接受它通不過那條控制項。如果你的組織持有 Cyber Essentials 或 Cyber Essentials Plus 並且每年續評，那就是下一次評估時會被書面問到的問題。

超出這一點的主張要謹慎。某一份資安保險保單或客戶合約會不會受影響，完全取決於它的措辭，而真正有效力的條款通常是要求使用受支援軟體或原廠支援版本的那一類，而不是點名 Drupal 的條款。請在12月之前而不是出事之後，讀一遍自家保單與主服務合約，那才是便宜的時候。

Drupal 12 究竟有什麼不同

幾乎沒有不同，這是誠實而且有用的答案。12.0.0-alpha1 發行說明講得很直白：12.0.x 將與 11.5.x 幾乎一模一樣，差別只在於移除了已淘汰的程式碼（包含整個已淘汰模組）、把相依套件更新到新的大版本，以及提高系統需求。至於其餘所有改動，說明要你去讀 11.5.x 分支。

確實有幾處值得知道的行為變更。預設的密碼雜湊演算法改為 argon2id，在 argon2 不可用的環境裡可以透過 kernel 參數改用 bcrypt。核心的 robots.txt 現在會擋掉帶查詢參數的搜尋結果頁，藉此阻止搜尋引擎爬取無窮無盡的分面組合，而自訂過 robots.txt 的網站需要自己補上那些 disallow 規則。核心本來就內建的 HTMX，在 beta1 由版本 2 升到版本 4。

還有一條容易漏掉。在正式環境中直接把 Drupal 架在 Windows 上，在 Drupal 12 中被標為淘汰，理由是沒有自動化的 Windows 測試環境，在上面做測試的開發者也很少。本機開發使用 Windows 仍然受支援。如果你的正式環境跑在 Windows 上，這是一個要在接下來幾個月內做的主機決策，而不是一次程式碼修改。

離開核心的擴充功能

Drupal 多年來持續把用途狹窄的模組從核心搬到貢獻專案，Drupal 12 延續了這件事。alpha1 說明列出 Ban、Contact、Field Layout、History、Settings Tray、Shortcut 與 Telephone 被移除，一併移除的還有 Stable 9 佈景主題。Text with Summary 欄位外掛也搬到自己的貢獻模組去了。Ban 早在 11.3 就被淘汰，Contact、Field Layout、History 與 Telephone 在 11.4，Settings Tray、Shortcut 與 Text with Summary 在 11.5。

其中兩個會讓人意外。Shortcut 與 Settings Tray 是非常多編輯團隊每天在用、卻從沒把它們當成選配的管理功能，尤其 Settings Tray 撐起了內容編輯者仰賴的區塊就地設定。

比這份清單更重要的是處理它的手法。正確的做法是在升級之前把貢獻版本加進 Composer 相依，而不是把模組解除安裝。解除安裝會毀掉該擴充功能的設定，而 Drupal 的模組探索最後才看核心，所以只要貢獻專案在，Drupal 自然就會用它。另外要注意，Drush 可以繞過 update.php 上關於擴充功能缺漏的警告，於是故障會在事後以狀態報告裡的錯誤形式浮現。

咬得最深的改動是失去 Migrate Drupal

Migrate Drupal 與 Migrate Drupal UI 兩個模組在 Drupal 12 中被移除，而且和其他模組不同，它們不會被搬到貢獻專案裡。Drupal 12 保留了 Migrate API 與面向現代 Drupal 的目的地外掛，但沒有保留 Drupal 6 與 Drupal 7 的來源外掛。

如果你手上有一個 Drupal 7 網站，請把這句再讀一次。那套讀取舊版 Drupal 資料庫並寫入現代 Drupal 的工具，在 Drupal 11 裡存在，在 Drupal 12 裡不存在。drupal.org 的指引很明確：打算使用遷移 API 的 Drupal 6 或 Drupal 7 網站，應當繼續遷移到 Drupal 11，然後用一般的更新流程從 Drupal 11 走到 Drupal 12。

這就把一個模糊的打算，變成一條硬性的順序限制。一個落在 Drupal 11 退出支援之後的 Drupal 7 重建案，只能自己寫來源外掛，或者在拋棄式環境裡還原一份舊核心來跑遷移，或者用別的方式把內容匯出再匯入。這三條都比在 Drupal 11 還是當前受維護目標時就把遷移做完更貴。這類工作的樣貌，我們在Drupal 遷移的費用、選項與期限一文裡談得更細。

新的相依門檻

大版本正是 Drupal 獲准調高平台需求的地方，而 Drupal 12 把這份許可全面用上了。這些門檻是你無從商量的部分，因為它們在安裝時就會被強制執行。

PHP 8.5，再舊的都不行

Drupal 12 需要 PHP 8.5。PHP 需求對照表顯示 Drupal 12.0 支援 PHP 8.5 並拒絕一切更低版本，而 Drupal 11.3 與 11.4 接受 8.3、8.4 與 8.5。那段重疊就是你的搬遷通道：先在 Drupal 11.4 上把網站挪到 PHP 8.5，確認行為正常，然後再動 Drupal。

這個門檻與其說嚴苛，不如說寬裕。PHP 8.5 於 2025年11月20日推出，php.net 的受支援版本頁面把它的主動支援列到 2027年12月31日，安全支援列到 2029年12月31日。落在這上面，可以買到三年才需要再談這件事。

資料庫與 Symfony

Drupal 12 的資料庫伺服器需求是 MySQL 8.0 以上、MariaDB 10.11 以上、PostgreSQL 18 以上，以及帶 json1 擴充的 SQLite 3.45。使用 PostgreSQL 的網站應該把這條門檻當成最需要仔細查核的一條，因為 alpha1 發行說明寫的是 PostgreSQL 19，而需求頁面與安裝程式的程式碼寫的都是 18。在預約資料庫工作之前，請在 beta1 時再核對一次。

在底層，Symfony 從 7.4 升到 8.1，Guzzle 從 7 升到 8。若干舊的函式庫大版本被放掉支援，包括 doctrine/lexer 2、egulias/email-validator 3 與 guzzlehttp/psr7 2。直接對 Symfony 類別做型別提示的自訂程式碼，就是這件事現形的地方。

這些門檻對主機提出了什麼

真正卡住共享主機與代管主機的是 MariaDB 的調高。Drupal 11 接受 MariaDB 10.6，而依照 MariaDB 維護政策，它的社群維護已在 2026年7月6日結束，所以一個 Drupal 11 網站眼下完全可以名正言順地跑在一個不受支援的資料庫引擎上。Drupal 12 把門檻拉到 10.11，而這一版維護到 2028年2月16日。如果你的主機今天拿不出 PHP 8.5 與 MariaDB 10.11，那麼換主機必須排在換 Drupal 之前，而正是這種順序對調，把一件兩週的工作變成兩個月。平台這一側，我們在什麼才真的跑得動 Drupal裡整理過。

淘汰模型為什麼讓 Drupal 12 變得可控

這裡有一個幾乎從沒被解釋給網站擁有者聽的機制，而它正是 Drupal 大版本不再嚇人的原因。跨大版本連續升級政策讓核心許下一個簡單承諾：下一個大版本擁有與上一個大版本最後一個小版本相同的公開 API。新 API 在小版本裡加入，舊 API 在小版本裡被標為淘汰，而刪除只發生在大版本的交界上。

它務實的後果值得用白話說清楚。如果你的自訂程式碼與貢獻模組能在 Drupal 11.5 上運作而且沒有淘汰警告，那它們就能在 Drupal 12 上運作。升級不再是重寫，而變成一次相依套件調升加一次資料庫更新，因為所有會壞掉的東西，幾個月前就已經以警告的形式報給你，而你本來可以從容修掉。

這也是發行說明要你先升到 11.4 以上、並強烈建議 11.5 的原因。來自 11.4.0 之前版本的資料庫更新路徑，已經被從 Drupal 12 裡整個移除，所以 11.3 或更早的網站在沿著 11 分支往上走之前，根本沒有通往 12 的路。這不是建議，這是一條不存在的程式碼路徑。

會回報淘汰情況的工具

做這件事的專案有兩個，而且都還在維護。Upgrade Status 是全站掃描器。你要把它裝在準備升級的那個網站上，而不是升級之後的網站上，因為被淘汰的 API 必須還在，它才找得到對這些 API 的呼叫。它會檢查你的環境是否符合下一個大版本的系統需求，把你的貢獻專案與可用更新交叉比對，針對淘汰的 PHP API 用法執行 PHPStan，並讀取 Twig 樣板、info.yml 檔、composer.json 與已淘汰的設定鍵。2026年7月2日推出的 5.0.0-alpha3 宣告相容 Drupal 10.4、11 與 12。

它還會把找到的問題分類，而這一點最省錢。問題被分成機器能修的與必須由人來修的，於是你可以在承諾日期之前，先把人工那一半算出價格。它在 Drush 下以 upgrade_status:analyze 執行，其 Code Climate 格式的 JSON 輸出可以接進 GitLab CI。

另一半是 Drupal Rector。它會改寫你的自訂模組與佈景主題中可以機械修復的淘汰呼叫，還有一個 --dry-run 參數可以先看差異。版本 1.1.2 於 2026年8月7日推出。兩者搭配，一位稱職的開發者可以在兩到三天內，為一個中型網站提出一份站得住腳的就緒報告。

路線一：從 Drupal 11 到 Drupal 12

如果你在 Drupal 11.4 或 11.5 上，而且貢獻模組都是新的，這就是一件小工程。官方升級指南基本上就是一串 Composer 指令：用 --no-update 宣告版本 12 的中繼套件，拿掉任何明寫的 drupal/core 相依，跑 composer update --dry-run，接著真的跑一次，再用 drush updatedb 套用資料庫更新。

真正的工作在這前後兩端。之前要跑 Upgrade Status，為你確實在用、卻已被移除的核心擴充功能加上貢獻替代品，並確認主機提供 PHP 8.5。之後要預期每一個核心 scaffold 檔案都變了，包含 .htaccess，所以你對它們做過的自訂必須有意識地重新套用，而不是盲目合併。

當相依關係拒絕解出時，composer why-not drupal/core ^12 會點名擋路的那一個。在 composer.json 裡同時允許一個模組的兩個大版本，例如 "^6.1 || ^7.0"，是替過渡期專案搭橋的標準做法。如果你需要的模組有可用修補但還沒有打標籤的版本，Drupal Lenient Composer 端點正是為此而存在，而且仍在維護。

路線二：從 Drupal 10 到 Drupal 12 是兩段跳

沒有從 Drupal 10 直接升到 Drupal 12 的路。Upgrade Status 的文件講得很明白，而 11.4 之前資料庫更新路徑的移除，讓這條規則被強制執行。你要先從 Drupal 10.6 走到 Drupal 11.4 或 11.5，驗證網站，然後再從那裡走到 Drupal 12。

只要規劃得當，這並不是雙倍工作量。從 Drupal 10 到 Drupal 11 那一段承擔了幾乎全部風險，因為貢獻模組的相容問題住在那裡，自訂程式碼撞上被移除 API 的地方也在那裡。第二段就是上面說的那件小工程。想把兩段壓進同一個變更時窗的團隊，通常最後分不清是哪一段弄壞了什麼。

行得通的順序是：現在就做 Drupal 11 那一段，讓網站在 11.4 或 11.5 上跑幾週，好讓真實的編輯行為與流量把異常翻出來，然後等貢獻模組針對 Drupal 12 打出穩定版本後，在新的一年再取 Drupal 12。關鍵是要在12月之前完成第一段，因為正是這一段把你從不受支援的程式碼裡帶出來。

路線三：Drupal 7 或 8 是重建，不是升級

任何比 Drupal 9 更舊的東西都是另一回事。Drupal 7 在 2025年1月5日走到終點，Drupal 6 在 2016年2月。兩者都完全無法原地升級，因為它們早於現代架構本身。它們是被遷移的，也就是在當前 Drupal 上蓋一個新網站，再用 Migrate API 把內容搬進去。Drupal 8 網站技術上確實有一條原地路線，但那條路要連續穿過四個大版本，而每一個貢獻模組都得在每一步活下來，所以通常把它當成重建反而更省錢。

費用是由內容以外的一切主導的。佈景主題要重做，自訂模組要針對一套完全不同的 API 重寫，各種整合要重新接上。依我們的經驗，內容遷移本身通常是預算裡較小的那一半，這跟大多數擁有者來問報價時的預期恰好相反，也正是我們把這類案子當成網站開發專案而不是升級來定範圍的原因。

對這些網站來說，12月的期限以另一種方式起作用，但因為 Migrate Drupal 被移除，它照樣會咬人。你的目標必須是 Drupal 11 而不是 Drupal 12，而依 drupal.org 自己的文件，Drupal 11 支援到 2028年中期至後期。這給了 Drupal 7 的擁有者一個真實的時窗，但那是一個有硬邊界的時窗，而為了趕上一個 2028年的目標，在 2028年才動手一個六個月的重建，稱不上是計畫。

每條路線在英國要花多少錢

這些是我們自己交付經驗得出的內部估算，不是公開牌價，而每個區間內部的落差，幾乎完全由貢獻模組的健康狀況決定，而不是網站規模。英國服務商做這類工作的日費大約是 600 到 900 英鎊。維護良好的網站從 Drupal 11 升到 12，含測試是三到八天，落在大約 2,000 至 6,000 英鎊。同一個網站若貢獻模組已經陳舊，就要預留兩到四週與 6,000 至 12,000 英鎊。

Drupal 10 網站要付兩段的錢。維護良好的話，Drupal 10 到 11 那一段是 6,000 至 15,000 英鎊，Drupal 12 那一段再加 2,000 至 6,000 英鎊，於是四到八週內合計 8,000 至 21,000 英鎊。若長期失修，光第一段就要 15,000 至 35,000 英鎊，總額落在 17,000 至 41,000 英鎊之間。Drupal 7 重建是三到六個月，常見 40,000 至 120,000 英鎊，規模大或改造多的網站還會更高。

決定你日期的是貢獻模組盤點

升級專案很少死在核心上。它們死在名單裡第十四個模組上，那個誰都想不起來何時裝的模組，它沒有相容下一個大版本的版本，而維護者上一次留言是在2023年。在你承諾日期之前先做這次盤點，因為產出那個日期的正是這次盤點。

跑一次 Upgrade Status 並匯出報告，然後把模組分成四個桶。第一個桶是有穩定版本支援目標大版本的專案，它們不花錢。第二個桶是議題佇列裡有修補或開發版本的專案，它們要花一點整合工作，並帶著那份修補最後沒被納入的風險。第三個桶是議題開著但沒有修補的專案，需要有人去寫。第四個桶是完全沒有任何動靜的專案。

定下時程的是第四個桶，而它的大小今天就能知道，不必等到11月。一個有三十個貢獻模組、第四個桶是空的網站，是一件順當的工作。同一個網站若第四個桶裡有四個模組，那就是預算完全不同的另一份委託，而這兩份報價之間的差別，只值一天的掃描。

遇到被棄養的模組該怎麼辦

誠實的選項有四個，選哪一個取決於這個模組在做什麼。如果它提供的功能已經沒人用了，就移除它，在多年編輯口味漂移之後，這比團隊預想的更常成立。或者換成一個做同樣事情、仍在維護的專案，並接受隨之而來的設定遷移。

接手維護，在 Drupal 裡這是一個真實的選項，也沒有聽起來那麼嚇人。drupal.org 有一套成為無人支援專案維護者的成文流程，而對一個你的業務確實依賴的小模組來說，把它認養下來可能比替換更便宜。這筆成本是持續的而不是一次性的，所以要老實把它算進去。

或者，把這個行為在一個只涵蓋你實際用到範圍的自訂模組裡重新實作一次。貢獻模組替所有人解決通案，而你通常只需要其中窄窄的一片。針對現行 API 把那一片重做，往往是兩天的工作對上兩週的移植，而且能永久拿掉這個相依。要怎麼辨識具備這種判斷力的人，我們在聘用 Drupal 開發者一文談過。

從 2026年12月9日倒推的時程表

從終點日期出發，計畫會自己寫出來。到9月下旬，在正式環境的一份副本上針對 Drupal 12 跑一次 Upgrade Status，把那四個桶落到紙上。這是兩到三天的工作，而它是唯一能讓你誠實地為其他一切定價的產出。

到10月中旬，確認你的主機拿得出 PHP 8.5 與那些資料庫門檻，如果拿不出就開始搬。同時把貢獻模組的那些問題定下來，因為它們每一個都帶著前置時間。到11月上旬，Drupal 10 網站應當已經完成升到 Drupal 11.4 或 11.5，而且網站已經在新分支上跑正式流量。

到12月初，你會是在旁觀 12.0.0 推出，而不是被它推著反應。如果那時你在 Drupal 11 上，就等貢獻專案針對它打出穩定版本後，在 2027年1月或2月再取 Drupal 12。在推出當週升級並沒有獎品，而 Drupal 11.5 那時仍在支援期內。獎品屬於在公告停止時不在 Drupal 10 上的人。

什麼都不做的代價

直接代價是，2026年12月9日之後揭露的每一個 Drupal 核心漏洞，都會在你的網站上永久敞開。Drupal 的公告史裡出現過嚴重到公布數小時內就被利用的遠端程式碼執行問題，而公開 IP 上一套沒有修補的 CMS，是被自動掃描找到的，不是被某個特別挑上你的攻擊者找到的。

間接代價來得更早，而且通常更大。在 Cyber Essentials 評估中通不過受支援軟體那條控制項，可能影響你參與要求該認證之合約的資格，而這在英國公部門採購裡很常見。貢獻模組會停止為你的分支發修正。而升級本身每個月都在變貴，因為就算沒有人動過任何東西，你的程式碼庫與受維護生態系之間的距離也在拉開。

還有一種更安靜的代價。一個誰都不被允許升級的網站，往往會變成一個誰都不被允許改動的網站，功能開發因此停擺，因為每一處改動都得建立在一套即將消失的 API 上。一個五年歷史的 Drupal 網站，就是這樣從升級變成重建的。如果你正在權衡這個決定，我們的 Drupal 開發指南會比一份報價更適合當起點。

兩個可以正當等待的理由

等待在兩種情況下站得住腳，而且必須是有意識地等。第一種是你已經在 Drupal 11.4 或 11.5 上。這些分支受支援，它們就是為 Drupal 12 指定的發射台，而在貢獻專案還在陸續打標籤的頭幾週去取一個全新的大版本，並沒有任何好處。等到 2027年第一季是專業的選擇，不是偷懶的選擇。

第二種是一個已經有預算、也已經排程的 Drupal 7 重建案。把 Drupal 7 遷到 Drupal 11 再立刻推進 Drupal 12 是多餘的動作。先落在 Drupal 11 上，跑起來，之後再把 Drupal 12 當成一般維護取走。

站不住腳的是，在沒有既定計畫的情況下繼續坐在 Drupal 10 上。如果說的是你，那麼到9月底最起碼該有的狀態是：一份掃描報告、一個點名的目標分支，以及行事曆上的一個日期。其餘一切都還可以調整。如果你希望由做過這件事的人來出這份評估，我們的軟體開發團隊把版本稽核當成一項範圍固定的工作來做。

從哪裡開始

先做掃描。世上幾乎每一份糟糕的 Drupal 升級報價，都是在沒有掃描的情況下做出來的，這也是為什麼其中那麼多在兩個方向上都是錯的。兩到三天的 Upgrade Status 與 Drupal Rector 輸出，會告訴你自己實際落在上面五個費用區間的哪一個，而這一個數字對你和董事會談話的改變，勝過任何關於大版本的泛論。

Mecanik 做這類稽核，也做後續的升級，既面向正在直面12月的 Drupal 10 網站，也面向計畫在 2027年從容搬遷的 Drupal 11 網站。自訂模組工作、整合與淘汰清理歸我們的軟體開發團隊，而重建或換主機則歸網站開發。如果這件事落到你桌上是因為資安態勢，先讀我們關於 Drupal 安全公告與真實風險的文章；如果版本搬遷期間的自然流量才是你的擔憂，那麼 Drupal SEO 設定那一篇談的正是要保護什麼。

常見問題

Drupal 12 什麼時候推出，Drupal 10 什麼時候走到生命週期終點？ Drupal 12.0.0 預定在 2026年12月7日那一週推出，與 Drupal 11.5.0 一同發布，而 Drupal 10 在 2026年12月9日走到生命週期終點。兩個日期都公布在 Drupal 核心發布時程上。同一週內，11.3.x 與 10.6.x 兩個小版本分支的安全支援也會結束。Drupal 12.0.0-alpha1 已在 2026年9月2日打上標籤。

我可以從 Drupal 10 直接升級到 Drupal 12 嗎？ 不可以。來自 Drupal 11.4.0 之前版本的資料庫更新路徑已經從 Drupal 12 中移除，所以 Drupal 10 網站必須先升到 Drupal 11.4 或更新版本，然後再升到 Drupal 12。drupal.org 建議在大版本搬遷之前先到 11.5.0 或更高。請按兩段跳來規劃，其中從 Drupal 10 到 11 那一段承擔了幾乎全部風險與成本。

Drupal 12 的系統需求是什麼？ Drupal 12 需要 PHP 8.5，並放掉對 PHP 8.4 及更早版本的支援。資料庫門檻是 MySQL 8.0、MariaDB 10.11、PostgreSQL 18，以及帶 json1 擴充的 SQLite 3.45。Symfony 升到 8.1，Guzzle 升到 8.0。在正式環境中直接把 Drupal 架在 Windows 上已被淘汰，不過本機開發使用 Windows 仍然受支援。

和 Drupal 11.5 相比，Drupal 12 究竟有什麼新東西？ 依設計幾乎沒有。alpha1 發行說明寫明，12.0.x 除了移除已淘汰程式碼、更新相依套件大版本與提高系統需求之外，與 11.5.x 幾乎一模一樣。值得留意的行為變更是預設密碼雜湊演算法改為 argon2id、HTMX 升到版本 4，以及核心 robots.txt 會擋掉帶查詢參數的搜尋結果頁。

在英國做一次 Drupal 12 升級要花多少錢？ 在維護良好的 Drupal 11 網站上，是三到八天的工作，按英國服務商每天 600 至 900 英鎊的常見費率，大約 2,000 至 6,000 英鎊。Drupal 10 網站要付兩段的錢，維護良好時落在 8,000 至 21,000 英鎊，長期失修時落在 17,000 至 41,000 英鎊。Drupal 7 重建是三到六個月，常見 40,000 至 120,000 英鎊。這些是內部估算，不是公開牌價。