年初接到一個保養廠客戶的需求，他打開電腦給我看：

「我們公司現在用『維修高手』這套系統 — 跑在 Windows XP 的電腦上、共 17 個模組、每天結束要找老闆桌上那台電腦做月結。我兒子說該升級了，但我們不知道怎麼升、找誰升、升完是不是反而更難用。」

這個故事我相信很多台灣中小企業老闆有共鳴。今天這篇要聊的是「舊系統升級」這件事 — 不是技術選型 cheatsheet、也不是 SaaS vs 自架的爭論，而是一個實際從 Windows 桌面舊系統升級到雲原生 ERP 的完整故事，包含我們踩過的坑、做出的取捨、和最後客戶怎麼說。

起點：「維修高手」這套系統

先講背景：客戶是高雄的一家連鎖汽車保養廠，有 3 個門市、員工 25 人。他們從 2008 年就在用一套叫「維修高手 (Geniusoft)」的桌面軟體。這套系統當年是業界主流，功能涵蓋：

車主 / 車輛資料管理
維修工單建立 / 派工 / 進度
零件進貨 / 庫存 / 出貨
服務項目價格 / 工時表
客戶分級 / 行銷標籤
報表（日 / 月 / 季 / 年）
薪資計算 / 出勤打卡
公文簽核 / 內部通知

17 個模組總共加起來，其實業務邏輯設計得意外完整。但問題不在功能 — 問題在「載體」。

舊系統的 5 個致命傷

綁定單機：整套軟體裝在某一台 Windows XP 電腦上，老闆桌上那台。其他 5 台分機只能透過共享資料夾連回去，連線速度慢、不穩。
沒有遠端能力：出差、居家辦公、開分店都看不到資料。要看報表必須回辦公室開那台電腦。
資料容易壞：用的是 Access mdb 檔，月結時電腦如果當機，整檔資料就要重建 — 客戶經歷過兩次。
沒有手機版：技師在保養廠地下室修車，要回辦公室才能更新工單進度、查零件庫存。
廠商已停止維護：維修高手公司倒了，連 Windows 10 的相容性問題都沒人修。每年 Windows 更新都要拜託。

客戶最怕的事：「升級會不會反而更難用？」

這個問題我聽過 N 次，它本身就是這類客戶最大的心理障礙。舊系統雖然爛，但已經用了 15 年，每個員工都會用、業務流程都圍繞著它跑。

升級失敗的恐懼很真實：

員工要重新訓練，學習曲線太陡 → 反而更慢
新系統 bug 沒舊系統的 bug 熟悉 → 客訴變多
資料搬不過去或搬錯 → 客戶歷史紀錄消失
上線初期跟舊系統並行 → 兩邊資料對不上

所以接這種案子，第一個要解決的不是技術，是降低客戶的風險感。我們的做法：

階段性交付：不一次換 17 個模組，按使用頻率排序，先換最常用的 3 個，跑穩了再換下 3 個。
並行期：3 個月 — 新舊系統同時運作，每天結束自動對帳，差異 ≥ 1 筆就警報。
UI 致敬：新系統的工單建立流程、欄位順序、快捷鍵儘量跟舊系統一致，員工幾乎無痛切換。
逐步淘汰計畫：白紙黑字寫好「Q1 切第 1 批、Q2 第 2 批、Q3 全部完成」，老闆有掌控感。

技術選型：為什麼是「雲原生 ERP」

我們最後給客戶的方案是一套多租戶 SaaS 架構的 ERP — 表面看起來是「給他的客製化系統」，骨子裡是個能服務更多保養廠的平台。架構大致是這樣：

┌────────────────────────────────────────────────┐
│  Cloudflare  (TLS / CDN / DDoS / DNS)          │
└──────────────────┬─────────────────────────────┘
                   ▼
┌────────────────────────────────────────────────┐
│  K8s — tenant-central namespace (中央服務)     │
│    ┌─────────────┐  ┌──────────────────────┐   │
│    │ nextjs UI   │  │  routing gateway     │   │
│    └─────────────┘  └──────────────────────┘   │
└──────────────────┬─────────────────────────────┘
                   ▼ 依 X-Agent-Code 分流
       ┌───────────┴──────────────┐
       ▼                          ▼
┌─────────────────┐      ┌─────────────────┐
│ tenant-baoyang  │      │ tenant-{others} │
│  laravel + DB   │      │  laravel + DB   │
│  100% 隔離      │      │  100% 隔離      │
└─────────────────┘      └─────────────────┘

這個架構有幾個重點：

每個保養廠一個獨立資料庫 + namespace — 資料完全隔離，誰也看不到誰的客戶。
但程式碼是同一份 — 修一次 bug 全租戶都受益，不需要為每個客戶單獨維護分支。
K8s 自動擴展 — 一家保養廠流量大的時候自動加 pod，其他客戶不受影響。
可動態切品牌 — 主題色、logo、字體全部資料庫驅動，不用 rebuild。下個客戶想要紫色背景？改一個欄位就好。

Stack 選擇的取捨

這次案子我們選的 stack：

後端：Laravel 10 + Octane (Swoole) — PHP 生態成熟、找人接手容易，Octane 解決了 PHP-FPM 慢啟動的痛點
前端:Next.js 16 + MUI v7 — App Router + Turbopack 快、SSR 對 SEO 友善
資料庫:MySQL + MongoDB — 主資料 MySQL，操作 log 進 MongoDB（90 天 TTL，自動清）
通訊:Laravel Echo + Socket.io — 工單狀態變化即時推播給技師手機
部署:K8s + Helm Chart + AWS EKS — 模板化部署，新租戶開通從手動 1 小時降到 10 分鐘
認證:JWT (php-open-source-saver/jwt-auth) — 雙 Auth Guard 設計，後台 ERP 員工跟 LINE LIFF 廠商完全分離

為什麼不用 SaaS（如 SAP Business One、Salesforce）？因為客戶業務太特殊：保養廠跟一般零售業的「商品」概念完全不一樣 — 商品是工時 + 零件 + 服務的組合，標準 ERP 處理不了「同一台車不同次來店要追蹤同一個技師」這種需求。客製化的價值就在這裡。

最有趣的設計:保留 17 個模組的 5 個改造

1. 車主 LINE 綁定

舊系統的客戶資料只有「姓名 + 電話」，現在加上LINE User ID。車主用 LINE 加保養廠官方帳號就能：

在 LIFF 內查維修進度（不用打電話問）
車子保養 / 驗車 / 保險到期前 7 天自動推播提醒
上次消費紀錄一鍵調出

2. 維修工單變成「進度看板」

把舊系統靜態的「工單狀態欄位」改造成 5 階段的看板，技師在手機上拖拉就能更新：

接車 ──► 檢查 ──► 維修中 ──► 待領車 ──► 已交車

車主端的 LIFF 也即時同步看到。

3. 零件庫存 + 自動採購

舊系統的庫存是「員工手動扣減」 — 容易漏。新系統把工單完成 → 零件自動扣庫存 → 低於安全庫存自動發採購建議綁在一起。

4. 行銷自動化

3 萬個車主資料閒置太可惜。新系統內建：

保養到期前 14 天自動發 LINE 提醒（含預約連結）
驗車到期前 30 天提醒
保險到期前 60 天提醒 + 推薦合作保險公司
VIP 等級自動計算（依累積消費），到一定門檻自動升級 + 推播優惠

光是「保養到期提醒」一個功能，客戶第一個月回流率就從 30% 提升到 62%。

5. MCP / AI 對接

這個是新東西 — 我們把 ERP 開了一個 MCP（Model Context Protocol）介面，老闆用 Claude 直接問：

「上個月哪個技師工時最高？三輪保養 + 1 次驗車的客戶有幾位？最近 30 天哪個零件成本最高？」

AI agent 直接呼叫 MCP 工具撈資料、跑分析。老闆不用學 SQL、不用學報表系統，用自然語言就能管公司。

資料遷移:最頭痛的步驟

整個專案最容易被低估的就是這一步。客戶以為「資料就匯出來再匯進去」很簡單，實際上要處理 9 種狀況：

舊系統的 mdb 檔每年一個 → 跨年資料要合併
客戶聯絡方式有些有手機、有些只有市話 → 標準化
車牌格式不一（有些有空白、有些大小寫不一致）→ 正規化
歷史維修紀錄的「零件名稱」是員工自由打字 → 對應到新系統的零件主檔
技師代號重複（前員工和現任員工同代號）→ 重新編碼
金額欄位有些是含稅、有些不含稅 → 全部統一
30 萬筆操作 log 全部要保留（稽核需求）→ 進 MongoDB
舊系統的 PDF 報表（合約、保固卡）要從檔案系統撈出來重新關聯
客戶照片（車輛特徵、保險卡）→ 重新上傳到 S3，更新連結

我們的做法是寫了一套遷移工具腳本（Laravel artisan command + Python），跑了 4 個 dry run、3 個白天 + 2 個假日的實際資料對檢，才正式上線。光是這部份就花了整個專案 30% 的時間。如果你聽到「3 個月可以做完整套 ERP」的報價，要不就是不換資料庫，要不就是低估了。

上線後 3 個月:客戶說了什麼

「沒想到員工沒人抱怨。」

這是客戶上線 1 個月後跟我們說的話，也是最讓我意外的反饋。我們以為會有 5-10% 員工適應不良，但因為 UI 致敬舊系統 + 並行期有舊系統可退路，實際上完全沒人抱怨。員工的反應分三類：

原本最反對升級的老員工：「跟舊版差不多嘛，新功能不用就好」（用了 2 週後開始主動用 LINE 提醒功能）
中生代員工：「終於能在家也看工單了」
技師：「手機就能改狀態這個超方便」

數字

3 個月後客戶端的可量化改善：

客戶回流率：30% → 62%（保養到期 LINE 提醒）
人均月維修工單數：48 → 67（手機更新狀態節省 4 趟回辦公室時間）
月結時間：從 2 天降到 30 分鐘（自動計算 + 報表）
零件斷貨次數：月平均 8 次 → 1 次（自動採購建議）
VIP 客戶月消費：平均 +35%（自動分級 + 推播優惠）

我們學到的 3 件事

「升級恐懼」比「技術困難」更難解。老闆嘴上問規格，心裡擔心的是員工反彈、業務中斷、上線失敗。技術方案要先 wrap 在「降低風險」的論述裡。
UI 致敬是必修課。不是創新就一定好，員工已經養成的肌肉記憶值得保留。新功能放在新地方，舊操作流程儘量原地不動。
把單客戶做成平台的思維。這套保養廠 ERP 寫的時候就考慮「多租戶」架構。下個客戶不會是保養廠，可能是工程顧問、連鎖門市、教育中心 — 80% 程式碼可重用，只要客製 20% 業務邏輯模組。客戶覺得我們是「為他客製」，我們其實是「在他身上磨平台」。

如果你也在用 Windows 桌面舊系統

這個故事可能跟你的場景有幾分相似：

用了 10 年以上的桌面軟體（Geniusoft、聖典、神乎其技、自家工程師做的⋯⋯）
綁定特定電腦 / 機房 / Windows 版本
已經沒有原廠維護或維護費用很高
公司業務變大或開新分店，舊系統跟不上
員工抱怨「為什麼還要用 Excel 跟舊系統雙頭工作」

這時候換系統是時候，但選錯方法會雪上加霜。先別急著比較 SaaS 報價，先做一份「舊系統流程盤點」— 把 17 個（或 27 個）模組畫成流程圖，標出哪些是「真的用」、哪些是「以前用過早就棄了」、哪些是「想要但沒人做」。這份盤點做完，你才知道要找什麼樣的廠商、需要什麼樣的功能。

這個盤點工作我們也接 — 第一次免費評估 1-2 小時，幫你判斷「該不該換、該怎麼換、預算大概多少」。聊完不合作不收費，至少你帶走一份清楚的決策框架。

延伸閱讀

如果你的客戶資料還在 Excel：先看「中小企業 ERP 該怎麼起手？」
在乎成本：看「自架 ERP vs SaaS：中小企業怎麼算才划算」（下一篇）
對 K8s 多租戶感興趣：看「多租戶 SaaS 平台架構決策筆記」（規劃中）