「我們有一套用了 30 年的 ERP，有/沒原始碼，現在新 Windows 跑不動了，想升級。」
這是我們最近 5 年最常被問到的開頭。重點在那個「有/沒」 — 因為差這一個字，工法、時間、風險、報價，全部不一樣。
我們做過兩個剛好一邊一個的案子，這篇講清楚兩條路怎麼選、怎麼做。
兩個案子，一邊一個 #
| 案 | 客戶手上有什麼 | 工法 | 時間 |
|---|---|---|---|
| 衛浴大廠（鶯歌某衛浴廠） | Visual FoxPro 6 + .prg 原始碼 + DBC/DBF 資料 | 自動轉碼 + 視窗化 + 列印 middleware | 1-2 週 |
| SunERP（新北建材業） | 跑了 30 年的 .EXE + .DBF，沒源碼、原廠商失聯 | 逆向業務邏輯 + 整套用 VFP 重寫 | 好幾個月 |
下面拆開來講。
路徑 A：有原始碼（衛浴案） #
如果客戶手上有 .prg 程式碼檔，事情會出乎意料地快。我們的做法分 5 步：
步驟 1：AI 自動轉碼（TSSHCO） #
TSSHCO（Thinking Robot · Smart Programmer Converter Robot）是伊朗工程師 Jamal Anvaripour 開發的 AI 程式自動轉換器，得過瑞士發明大賽銀牌。專做 FoxPro 系列的版本升級：FP 2.5 / 2.6 / VFP 6 → VFP 9。
它做什麼：把所有 .prg 源碼批次讀進去，AI 識別 syntax + API 差異，自動產生 VFP9 可編譯的版本。不是手工搬一行一行 port，是真的「丟進去 → 拿出來」。
對 30 年的老系統來說，這一步省下的時間是「等比級數」級別 — 你不可能讓工程師逐行讀 30 年的 code 改 syntax。
步驟 2：VFP9 編譯 + 視窗化 #
VFP9 是 Windows 32-bit native，編出來的 EXE 在 Windows 10 / 11 都能直接跑。
重點：UI 排版、欄位順序、F-key shortcut、報表格式都跟 VFP6 完全一樣。 員工從舊版切到新版，唯一感覺是「視窗有 title bar 跟 minimize 按鈕了」。操作流程零改變。
這對工廠現場員工很重要 — 你跟一個用了 20 年同套系統的師傅說「我們要換新系統」，他會立刻反彈。但如果你說「同個系統，只是能在新電腦跑了」，他根本不會抗拒。
步驟 3：DBC / DBF 完全不動 #
VFP9 原生支援 VFP6 的資料庫格式 — .DBC (database container) / .DBF (table) / .IDX (index)，連資料遷移都不用做。
舊系統的資料留在原本的位置，VFP9 直接讀。零風險的搬移。沒有「半夜 dry-run」、沒有「上線前比對筆數比到天亮」。
步驟 4：大方廣漢書列印整合 #
這是台灣 VFP 升級最常踩的坑：VFP6 原本的 report 是直接送 DOS / 老式印表機（用 ESC/P 那類控制碼）。換到新 Windows 印表機（特別是雷射 / 噴墨 USB 那類）就完全印不出來。
解法：導入「大方廣漢書」中文列印系統。它是個 middleware，不改原程式碼，老 VFP report 直接從 VFP 出到任何 Windows 印表機，中文字型、版型、套表完整保留。
對中文 ERP 來說這個工具是 hidden gem，省掉重寫所有報表的工。
步驟 5：後續加值 #
系統有源碼了，未來客戶要加什麼都能做。
衛浴案後續加上的：
- 陶瓷產線（成型→施釉→燒成→倉儲→出貨）條碼掃描追蹤
- 人員缺點履歷管理
- 修補流程
這些用 VFP9 form 開發 + 行動條碼掃描器（由摩葳統籌採購整合）。這些是「客戶想做」而不是「不得不做」，因為原系統已經穩定在跑了。
結果 #
1-2 週搞定主體搬移。員工接受度 100%。系統壽命延長 10+ 年。後續加值是 nice-to-have，不是 must-have。
路徑 B：沒原始碼（SunERP 案） #
這條路就完全不同了。客戶手上只有：
- 一份跑了 30 年的
.EXE - 一堆
.DBF資料檔 - 沒有源碼
- 原廠商失聯
想升級沒辦法 — 沒源碼就改不了；想換廠商沒辦法 — 沒人敢「黑盒接手」一套 30 年的關鍵業務系統；繼續用又怕老 EXE 哪天在新 Windows 跑不動。
這是真實的死局。我們的做法分 4 階段：
第一階段：逆向業務邏輯 #
從 .DBF 結構、.EXE 行為、現場員工怎麼操作，一條一條把業務規則重新整理出來。這不是技術活，是商業邏輯重建。每個欄位代表什麼？每個動作觸發什麼？每張報表的數字怎麼算？
舉例：「採購單上的『扣抵碼』是什麼？什麼時候啟用？對應到應付帳款的什麼欄位？」 — 這不是讀文件能找到的，要去問會計、問採購、問實際在用系統的人，然後對照 .DBF 裡的資料反推。
這階段花的時間最多，比寫 code 久得多。但跳過去的後果就是寫到一半才發現邏輯漏洞，整套打掉重來。
第二階段：用 VFP9 重寫 #
很多人會問：「為什麼還用 VFP？不是要搬 Web 嗎？」
務實理由：
| 為什麼還用 VFP | |
|---|---|
| 資料無痛遷移 | 客戶現有資料是 .DBF，VFP9 原生支援 |
| 介面熟悉 | 員工已經習慣 VFP / Win32 風格，不會抗拒 |
| 部署簡單 | Windows native EXE，不用搞 server / proxy / SSL |
| 速度快 | local DBF + native code，比 Web 還快 |
這是務實選擇，不是技術潔癖。先把客戶從「沒源碼黑盒」救出來，搬到「有源碼可控系統」。
第三階段：資料遷移 + 上線 #
舊 .DBF 全部清理（trim 空白、修補編碼、去重）後 import 進新系統，dry-run 比對筆數確認零遺失。上線後員工繼續用，但這次系統有源碼了 — 想加什麼、改什麼，都做得到。
這個 milestone 對客戶是分水嶺。從「我每天都怕系統突然壞掉」變成「我可以叫廠商加新功能」。
第四階段（現在進行中）：規劃 Web 版 #
客戶用穩 VFP 版幾個月之後，提出更現代的需求：行動端、跨地遠端、跟外部系統整合（電子發票、會計事務所對接、客戶下單系統）。
這時候才是搬 Web 的好時機。我們交付了規劃書，技術選 Next.js 15 + Prisma + Postgres + NextAuth.js v5。規劃啟動，實作待開工。
如果一開始就直接「VFP → Web」一步到位 — 客戶會卡在第一階段（逆向業務邏輯）就放棄。Web 重做的同時還要逆向 30 年的業務規則，工程量太大、風險太高、ROI 看不到。分兩階段做：先穩定，再現代化。
怎麼判斷該走哪條路 #
幫客戶評估時我們先問這幾個問題：
| 問題 | 答案影響 |
|---|---|
有 .prg / .fxp 原始碼嗎？ |
沒 = 路徑 B；有 = 看下一題 |
| 原廠商還聯絡得到嗎？ | 聯絡得到 = 可能用路徑 A；聯絡不到 = 看程式碼結構複雜度，可能還是路徑 B |
| 資料量級？ | < 50 萬筆 = 兩條路都行；> 100 萬筆 = 必須先 dry-run 評估遷移風險 |
| 員工對新介面接受度？ | 強烈反對 = 路徑 A 優先；願意學 = 兩條都可以 |
| 有沒有「現代化」剛性需求？（行動端、API 串接、跨地遠端等） | 沒 = 路徑 A 一階段就好；有 = 路徑 B 兩階段或路徑 A + Web 加值 |
| 預算 / 時間？ | 緊 = 路徑 A 優先（如果條件允許）；寬鬆 = 路徑 B 比較徹底 |
簡單說：路徑 A 是「翻新」，路徑 B 是「重蓋」。能翻新就翻新，沒得選才重蓋。
常見的迷思 #
迷思 1：「老系統都該直接搬 Web 才叫『現代化』。」
不對。如果有源碼能做路徑 A，搬上 Windows 視窗 + 持續維護 + 必要時加 Web 模組，比硬要 Web 重做有意義得多。客戶的痛是「新電腦跑不動」「員工年紀大要學新介面」，不是「沒有 Web」。
迷思 2：「沒源碼的系統用 SDK 工具就能反編譯出來。」
VFP 反編譯的工具有，但效果極差。你拿到的會是一堆無法讀的中間碼，比逆向業務邏輯還難。SunERP 案我們試過，最後還是回到「從 DBF + EXE 行為重建邏輯」。
迷思 3：「VFP9 已經被 Microsoft 停產了，不該用。」
VFP9 確實 EOL（2015 年）。但：
- Windows 11 還能跑（runtime 還在）
- 客戶舊資料在 DBF，新工具不會原生支援
- VFP 的開發效率對 ERP 類應用還是非常高
- 「不會死掉」跟「該重寫」是兩件事
實務上：先讓系統穩定能跑，再規劃搬 Web。直接跳「VFP → Next.js」常常會在 Web 重寫的中途就把客戶搞瘋。
客戶想評估 #
你手上有 30 年的老 ERP？先問自己這幾個問題：
- 有沒有原始碼？（在哪台電腦的哪個資料夾？）
- 資料庫格式是什麼？（DBF / MSSQL / Access / 其他）
- 原廠商還聯絡得到嗎？
- 員工對新介面的接受度？
- 預算有多大？
可以聊聊，諮詢免費，依工時報價。
0912852835 / henryccy@icloud.com / LINE @3q3tw / 線上表單
延伸閱讀：