更新網站後出現資料庫錯誤？搞懂 migration，上線才不會動到正式資料
週五下午的一個欄位，讓會員頁整片報錯
行銷主管希望會員資料多一個「生日」欄位，好在生日月寄優惠券。工程師（或 AI 工具）改完程式，傍晚更新網站。幾分鐘後客人來訊：會員頁一片白，只剩一行英文，寫著找不到某個 column，或是某張 table 不存在。
這種情況在中小企業很常見，原因通常不複雜：程式碼更新了，資料庫的結構卻沒有跟著更新。您能注意到錯誤訊息並想追查原因，已經比多數人踏出了更重要的一步。
Migration 是什麼：資料庫的施工紀錄
網頁程式可以整包換新，但資料庫裡有真實的訂單與會員，不能整個丟掉重來。要加欄位、改欄位型別、新增資料表，只能在原地施工。
Migration（遷移）就是一份有編號的施工單，例如：
- 001：建立會員表
- 002：新增訂單表
- 003：會員表加上生日欄位
系統會在資料庫裡留一張紀錄表，記下「已經做到第幾號」。每次上線，只補做還沒做的編號。這是 Laravel、Django、Rails、Prisma 等主流框架的共通做法，AI 工具產出的專案也多半有這一套。
出事通常是三種情況：
- 沒跑：新程式要讀生日欄位，資料庫裡卻還沒有，畫面就報錯。這正是開頭那個情境。
- 跑兩次：多半會看到「already exists」這類錯誤。更麻煩的是，如果那份 migration 帶有搬資料的動作，重複執行可能讓資料變成兩倍，或被覆蓋。
- 跑一半：施工到一半中斷，結構一半新、一半舊。有些資料庫（例如 MySQL）改結構的指令無法整批復原，要特別留意。
上線流程裡，migration 該放在哪一步
實務上建議用固定順序，每次都照著做：
- 先備份，並確認能還原。 備份檔存在，不代表還原得起來。至少要知道還原的步驟寫在哪裡。
- 先在測試環境演練。 用正式資料的副本（個資記得遮蔽）把 migration 跑一遍，確認不報錯、資料筆數正確。
- 只由一個地方負責執行。 不要讓每台伺服器、每次重啟都各自跑一次，這是「跑兩次」的主因。建議在部署流程中設一個獨立步驟，跑完才往下走。
- migration 完成後，再切換新版程式。 如果 migration 失敗，舊版程式仍在線上，客人不受影響。
- 上線後驗證。 檢查紀錄表是否已到最新編號，並實際打開會員頁、下單頁各操作一次。
另一個降低風險的習慣是「分兩次改」：這次只新增欄位，下次才改程式去用它，確定沒問題後，再用另一次更新刪除舊欄位。新增是安全的，刪除與改型別則難以反悔。
失敗了，怎麼不讓正式資料受損
看到錯誤時，最容易讓事情變糟的反應是「再按一次更新試試看」。建議改用這個順序：
- 先停手，不要重跑。 先查看 migration 紀錄表，確認停在第幾號。
- 先備份目前狀態。 即使狀態不完整，也要留一份，之後才有得比對。
- 能退回舊版程式，就先退程式。 資料庫則不要急著動，除非確認那一號 migration 可以安全退回，也就是沒有刪過資料。
- 必要時，把備份還原到另一個環境。 在那裡修好、驗證完，再決定怎麼處理正式環境。
如果您請 AI 工具幫忙產生 migration，可以加一句要求：「請逐項說明每一步能不能退回、會不會刪除或覆蓋現有資料。」這樣得到的說明，比單純一段程式碼有用得多。AI 產出的整體上線前檢查，可以對照這份 AI 寫的程式碼上線檢查清單。如果當初寫系統的人已經聯絡不上，連 migration 紀錄放在哪裡都不知道，可以先看 外包工程師失聯的 5 個步驟，把帳號與備份先掌握在自己手上。
另外補充一點：我們的 免費預覽 只放靜態網站，需要資料庫與後端的專案不會在那裡執行。這類專案的 migration 與備份流程，得在真正的主機上規劃。
下一步可以怎麼做
今天不必處理所有細節，先做兩件事：向負責的人確認「更新前有沒有備份、能不能還原」，並問清楚「migration 是在哪一步、由誰執行」。這兩個問題的答案，就能看出您的上線流程有沒有缺口。
如果答案模糊，或您想請人把流程補齊、寫成每次更新都能照做的文件，可以看看 我們的服務範圍與收費方式。範圍與價格都會先以書面談定，再開始動工。
關於 AI 上線專家
AI 上線專家讓您的 AI 幫您把網站部署上線：把一句話貼給 Claude Code、Cursor 或 Codex，幾分鐘後就有一個 您的名稱.aionline.tw 公開網址，可以直接傳給客戶或同事看。
- 免費預覽，不需信用卡，到期自動下線、不會扣款；滿意再升級為永久，最低 NT$99 / 月起
- 靜態網站、Node／Python 等有後端的網站都能部署，需要資料庫時自動配好 Postgres
- 付費方案可以綁自己的網域；部署不起來或需要客製開發，可以直接聯絡我們