長年使用的系統卡在舊版 PHP 無法更新？升級、搬家與重建怎麼選

文章導讀

「還能動，就先不要碰。」系統卡在舊版 PHP 的公司，常靠這句話撐過一次又一次的更新提醒，訂單、會員、報名系統就這樣用了好多年。PHP2Shell 公開之後，這句話很難再成立：漏洞影響幾乎所有仍在使用的 PHP 版本，停止支援的版本卻拿不到官方釋出的修補版本。這篇拆解系統真的無法更新時，升級、搬家與重建怎麼判斷，以及做決定之前，怎麼先把風險降下來。

先講結論：三條路各適合什麼情況

系統無法更新時，可以走的路有三條：原地升級、搬到新環境、分階段重建。選哪一條，要看卡住的地方在程式、在主機環境，還是在整套系統的設計。

路線	適合的情況	不適合的情況
原地升級	程式結構清楚，相依元件仍有人維護，版本落差不大	大量用到新版已移除的寫法，或核心模組加密、無法修改
搬家（換到新環境）	卡在主機作業系統或控制台太舊，程式本身能在新版 PHP 上執行	卡住的是程式本身：換了主機，舊程式在新版 PHP 上一樣跑不起來
分階段重建	核心元件停止維護、改一處壞多處，或流程已經和現在的營運對不上	只落後一兩個版本，流程穩定，程式也健康

三條路可以接著走。常見的組合是先搬到能更新的環境，再分段重建最舊的模組。

為什麼會「無法更新」：常卡在三個地方

PHP 本身一直往前走，已上線的網站卻常常停在原地。PHP 套件生態系的統計裡，2026 年 7 月還在用 8.1 以下版本的只剩約一成（Packagist 統計）；同一時期的網站，卻有三到五成停在 8.1 以下（WordPress.org 回報資料約 36%，依 W3Techs 版本分布推算約 48.5%）。網站上線之後就很少再動，這段落差就是這樣累積出來的。

多數「無法更新」的系統，問題集中在三個地方，而且常常不只一個。

• 相依元件停止維護

  系統用的框架、外掛或商業模組多年沒有新版，新版 PHP 一上去就出錯，原作者也不再更新。

• 程式寫法被新版移除

  PHP 每個大版本都會拿掉一些舊寫法。7.0 移除了舊的 mysql 資料庫函式，8.0 又移除了一批早已不建議使用的函式，舊程式會直接無法執行。

• 主機環境太舊

  作業系統或主機控制台停在很多年前的版本，裝不了新版 PHP。CentOS 7 在 2024 年 6 月停止維護，就是常見的例子。

這是我們檢查舊系統時很常看到的狀況：程式本身只用到少數幾個被移除的寫法，真正卡住的是一個多年沒更新的付款或報表模組。所以判斷能不能升級之前，要先把卡住的元件一個一個找出來，整套系統不一定要一起處理。

比較棘手的是加密過的模組。這類模組要靠特定版本的載入元件才能執行，內容無法修改，只能等原廠推出支援新版 PHP 的版本，或改用其他方式承接它的功能。

做決定之前，先把風險降下來

評估和排預算都需要時間，系統卻每天對外開著。過渡期間的目標，是讓舊系統暴露在外的部分愈少愈好，同時確保出事時有退路。這些措施由維護團隊依系統的狀況安排：

過渡做法	作用	限制
縮小對外入口	只開放必要的頁面，管理後台與內部功能限定公司網路或 VPN 連線	對外服務本身仍然暴露
網站防火牆的虛擬修補	在請求抵達系統之前，擋下已知的攻擊手法	只擋得住已知模式，官方的說法仍是更新才是安全的選擇
延長支援的修補版本	部分作業系統發行版或第三方，會替停止支援的 PHP 提供修補	要評估來源是否可信，成本落在持續追蹤與相容測試
監看與備份	監看檔案異動、異常登入與對外連線，並確認有乾淨、可還原的備份	能及早發現與復原，無法阻止入侵

這些做法是為了爭取做決定的時間，不能取代升級、搬家或重建。

同一段期間，你們公司內部可以先確認幾件事：這套系統有哪些人每天在用、停一天會影響什麼、近期有沒有活動或結帳高峰要避開。這些答案決定隔離能做到多嚴，也是後面選擇路線的依據。

五個評估面向，決定走哪條路

走哪條路，看的是下面五個面向，其中幾項只有你們公司內部才答得出來。

程式與資料的健康度

這個面向看的是程式怎麼組成，資料結構還符不符合現在的流程。它決定升級的工程有沒有邊界：程式切分清楚，相容問題可以一處一處修；功能彼此糾纏，修一處就得測整套。你們內部可以觀察的是，最近幾年改功能時，是不是常常改了這裡、壞了那裡。常見的誤判是用程式量判斷難易度，模組之間怎麼綁在一起，影響其實更大。

對營運的關鍵程度

同樣是舊系統，對外展示的官網和每天在接單的系統，能承受的風險完全不同。停一天的影響，決定切換要不要新舊並行、要準備到什麼程度。損失怎麼估，可以參考網站停機一天的損失估算。哪些時段絕對不能停，你們內部最清楚。

跟外部系統的串接

金流、物流、電子發票和 ERP 的串接，是舊系統最難動的部分。對方的介面可能早就改版，舊系統靠相容模式撐著；換環境或重建時，每一條串接都要重新驗證。你們要提供的是串接了哪些服務、各由誰對口，技術上怎麼接由維護團隊處理。串接怎麼規劃，可以參考官網、CRM、ERP 的資料分工與串接。

這個技術是不是還有人在維護

系統用的框架、內容管理系統或商業模組，原作者還有沒有在出新版，直接決定升級的意義。還有人維護的技術，升級之後能跟著官方的修補走；已經沒人維護的，就算這次硬升上去，下一次 PHP 大改版又會卡住。現成模組和客製開發各自的長期影響，在現成模組還是客製開發那篇有完整說明。

網址與搜尋上的累積

系統如果對外，網址就連著搜尋排名、外部連結和客戶的書籤。搬家或重建時，重要的網址都要有明確的去向，累積的內容與資料也要接得上。哪些資產要延續、怎麼延續，可以參考舊官網該局部改版還是整站重做的拆解。

原地升級：版本落差決定工程範圍

原地升級是改動最小的路，前提是版本落差和程式狀況都在可控的範圍。從 8.0、8.1 升到仍有支援的版本，多半是修正一些新版變嚴格的地方；從 7.x 升上來，要處理的寫法明顯變多；從 5.x 直接升到 8.x，跨了好幾個大版本，工程常常接近重寫。

升級的工序大致如下，由維護團隊在不影響正式站的環境完成：

• 盤點相依元件與寫法

  列出框架、模組與擴充套件各自支援到哪個 PHP 版本，找出會在新版出錯的寫法。

• 在隔離環境切換新版

  複製一份系統，在新版 PHP 上執行，把錯誤與警告全部收集起來。

• 修正相容問題並測關鍵流程

  逐一修正之後，用你們實際的下單、會員與報表流程測試，頁面能打開只是其中一部分。

• 排定切換與退回點

  避開營運高峰安排切換，切換前留好能回到舊版的退回點。

• 上線後持續監看

  觀察錯誤紀錄、排程與串接是否正常，再接回日常的版本更新。

升級完成，只是回到官方支援的時間軸上。PHP 每個版本的支援期大約四年，8.2 的安全支援到 2026 年底結束，8.3 到 2027 年底。所以升級時通常直接選較新的版本，並把後續的版本更新排進年度維護。版本更新時網站要怎麼測，可以參考網站更新為什麼會壞。

搬家：換到能持續更新的環境

搬家適合卡在主機環境的系統：作業系統太舊、控制台裝不了新版 PHP，或公司機房的設備很多年沒換。換到能持續更新的環境之後，PHP 與系統元件才跟得上官方的修補。

搬家要搬的不只程式和資料庫，還有這些：

• 上傳的檔案與圖片
• 排程工作，例如每天的報表、對帳或通知信
• 寄信設定，以及網域的 DNS 與憑證
• 串接用的金鑰與白名單，對方可能綁定了舊主機的 IP

搬家時最容易漏掉的，是藏在主機上的排程和寄信設定。系統搬過去看起來一切正常，幾天後才發現每天早上的訂單報表沒寄出。所以動手之前，要先把主機上在背後跑的事情全部列出來。

要注意的是，搬家本身不會修好程式的相容問題。舊程式在新版 PHP 上跑不起來，就只能在新主機上繼續用舊版 PHP，等於把舊問題原封不動搬過去。這種情況下，搬家適合當作第一步：把系統放進比較好隔離、比較好監看的環境，接著再處理程式本身。

重建：把流程重新整理再上線

重建適合三種情況：核心元件已經沒人維護、資料結構對不上現在的流程，或每次修補的成本愈來愈高。這時候硬升級只是延後問題，重新建置反而能一次把規則定清楚。

重建也不必一次全部換掉。比較穩的方式是分階段：先處理對外、風險最高的部分，舊系統的內部功能暫時保留，再一段一段移過來。新舊並行期間，資料以哪一邊為準，要在動工前就定好。

以 WordPress 重建時，標準的內容、會員與購物流程交給核心與成熟模組；現成模組承接不了的價格、審核或資料回寫規則，再用客製外掛補上。這樣分工，之後的版本更新才有清楚的邊界。兩者怎麼搭配，可以參考模組化建置、客製設計與外掛開發的差別。

成本會花在哪裡

三條路的費用依專案範圍而定，差別在錢花在哪幾段。把這次的建置和往後每年的持有成本放在同一張表判斷，比只看報價總額更準。

成本段落	驅動因素	三條路的差別
現況盤點	程式量、模組數、串接數量	三條路都需要，是後面所有估算的基礎
相容修正或重新開發	版本落差、被移除寫法的數量、客製規則的複雜度	升級花在修正，重建花在開發，搬家在這段最少
資料移轉	資料量、欄位差異、歷史資料的清理程度	重建最重，搬家次之，原地升級幾乎沒有
測試與並行	關鍵流程數量、串接對象、並行期間長短	牽動的營運流程愈多，這段愈重
上線後的維運	版本更新、備份驗證、資安監看	不論哪條路都持續發生；留在舊版環境，監看的工作更多

成本怎麼從建置延伸到每年的維運，可以參考網站從建置到每年維運的成本地圖。

還有一筆常被忽略的成本：繼續不動。停在舊版的系統需要額外的隔離與監看，出事之後的復原與補救，也比事前規劃更費工。這筆成本不會出現在報價單上，卻每個月都在發生。

三種常見情況的建議路線

同樣卡在舊版 PHP，公司的條件不同，合適的路線也不同。下面三種是常見的情況，最後的選擇仍要依評估結果與預算階段決定。

• 內部沒有 IT 人力，系統以對外為主

  形象官網或會員網站卡在舊版，傾向搬到有人持續維護的環境，或直接以 WordPress 重建，由維護團隊長期承接版本更新。

• 串接了 ERP、金流等既有系統

  先守住串接的邊界：搬到能更新的環境，串接維持不動，再分段重建最舊的模組。

• 流程還在變，功能常常要調整

  與其硬升級舊程式，不如重建時就採用模組化加客製外掛的架構，讓之後的調整有清楚的邊界。

如果程式健康、只落後一兩個版本，原地升級就是合理的選擇，沒有必要為了這次事件重建。要不要重建，應該由營運需要決定，恐慌不是好的理由。

我們怎麼評估一套無法更新的舊系統

評估一套舊系統，參考的做法是先看三件事。第一，它現在跑在哪個 PHP 版本與主機環境；第二，每天真正在用的是哪些流程與資料；第三，它和外部服務串接的邊界在哪裡。三件事看清楚，升級、搬家或重建的取捨就有了依據，過渡期間要做哪些隔離也能一起排定。

評估不需要你們先準備技術文件。你們說明系統的用途、誰在用、遇過什麼狀況；程式與環境的判讀，由維護團隊在確認範圍後進行。路線決定之後，升級或搬家的施工、重建的規劃與開發，到上線後的版本更新與資安處置，都可以由我們一路負責。

系統的改版與功能調整，由你們依營運檔期提出；PHP 與主機的版本更新、備份驗證與資安監看是另一條線，不論這個月有沒有改功能都持續在跑。舊系統會走到無法更新，常常就是這條線停了好幾年。

常見問題