先看真實狀態
先看程式與文件的真實狀態
評估路徑 · 從程式反推
沒有文件，就從程式與資料庫找答案
我們會看程式語言版本、相依套件、資料庫結構與操作手冊。很多舊系統沒有完整文件，只能從程式與資料庫反推。這個階段不談願景，只確認三件事：程式能不能建置、資料表之間怎麼連、操作手冊與現場做法差多少。
評估產出是一份切段清單：哪些模組能讀懂、哪些表格是真相來源、哪些報表只是暫時湊出來的。長期維護企業應用的經驗顯示，缺文件的現實要在第一週就面對，越晚面對，後面重工越多。
評估先看能不能建置、能不能還原資料關係，再談要不要重寫。
語言與套件
確認版本是否還能取得安全性更新，相依套件是否鎖死在舊版。升一版編譯器會壞多少支程式，先在測試機跑一次就知道。
資料結構
主鍵、外部鍵、預存程序與排程工作全部列出來。同一客戶在三個表有三種編號，這種問題在這裡第一次被看見。
操作現場
跟著操作員看一次月底結帳與出貨尖峰。手冊沒寫的暫存檔、共用資料夾與手動補單，才是真正的系統邊界。
選擇題 · 重構或整合
能讀懂就重構，不敢動就先包
2 週
現場盤點起跳
3 段
切段驗收單位
1 次
只換一段上線
老系統現代化應該先做重構還是先做整合，取決於停機容忍度。
能讀懂、能測試的模組，適合重構：把程式整理乾淨、補上測試、把相依套件升到可維護的版本。看不懂、不敢動的核心，適合先用 API 包起來：不動裡面，先把輸入輸出固定下來，外面系統都走同一道門。
產線系統多半先包，後台報表可以先重構。產線停一小時就是損失，包起來風險最小；報表錯了可以重跑，重構練手最合適。切段的原則是每一段都能獨立驗收、獨立上線，不賭一次全換。
- 適合重構邏輯清楚、有測試或補得起測試、可安排短暫停機的後台與報表模組。
- 適合先包沒人敢動的核心計費、庫存與產線連動，先定義 API 與錯誤碼，外面包一層再慢慢換裡面。
- 驗收方式每段附測試案例，客戶自己能重跑。跑得過才上線，跑不過就留在舊路上。
API 整合 · 具體作法
介面列清楚，錯誤碼寫死，重試有紀錄。
列出介面、定義錯誤碼、加上重試與紀錄。跨系統整合常卡在字集與時區，繁中介面還要注意編碼。我們會給測試案例，讓客戶自己能重跑，介面一致了，後面換什麼都比較不痛。
整理與串接 · 一次看完
報表、名單、上雲，照順序收斂
資料庫與報表
同一指標只留一種算法
舊報表邏輯散在 Excel 與程式裡，要先收斂指標定義。我們會做來源對照表：這個數字從哪張表來、經過什麼轉換、誰說了算。報表背後是流程，流程沒對齊，報表永遠對不起來。
整理完才談遷庫。先凍結定義，再搬資料，搬完用同一批測試案例比對新舊結果。
客戶資料與行銷串接
識別與同意先清乾淨
若舊系統要接會員與行銷工具，識別與同意紀錄要先清。同一客人在三套系統有三個編號，先合併識別，再談自動化。我們不把未經同意的名單寫入新庫，權限配合沒到位，串接就先停在讀取。
上線後每一筆寫入都要能追溯來源與同意時間，這是稽核要看的第一行。
雲端與通訊配合
先確認上雲順序
改造後若要上雲或整合通訊，保存與稽核要預留。跨點服務的需求存在，重構前先確認哪一段先上雲、資料留哪裡、日誌存多久，避免做好又重工。
順序通常是：介面固定、資料收斂，再談搬遷與通訊整合。
人力不足與小團隊提醒
大型改造缺人時，用短期工程人力補施工是可行的，但順序不能反：先定切段與介面，再補人。架構未定之前先補人，容易越補越亂，每個人各自接一條臨時線，最後沒有一條能留。
反過來，老系統裡的單一效能瓶頸，例如查詢逾時，可以先獨立處理。窄問題可以處理得直接，不用每次都談成全案。先止血，再談體質。
什麼情況不適合一次談全案？
停機時間談不下來、文件缺太多、權責還沒分清楚的時候。全案合約寫下去只是把未知數包起來，分段走反而比較快。
現場視角
拆到見骨不是口號，是把每一條線的去向都寫下來，再一條一條接回去。
下一步
帶著程式結構，來談一次
不用準備簡報，帶程式結構、資料庫關聯與最近一次出問題的紀錄來就好。我們先判斷先包還是先重構，再給切段與驗收方式。聯絡方式：新北市板橋區縣民大道二段7號12樓，+886-2-2960-3456，[email protected]。