網站搬站流程：更換寄存前後如何測試資料、域名與回復方案

網站搬站流程：先寫甚麼情況要回復舊環境

網站搬站流程若只寫「複製檔案、改 DNS、完成」，最重要的失敗處理便留了空白。搬站前先定義回復條件：新環境何時算可用、哪些訂單和資料不能漏、發現錯誤後誰決定暫停切換。假設一間香港小型網店在搬站當晚仍有客人落單，若舊站和新站同時接受交易，兩邊的資料很快會分岔。先處理寫入與切換，才適合安排搬站時間。

這裏討論的是保留原有網址及主要網站內容，只更換寄存環境的工作。若連網址、分類與頁面都改，須另按網站改版處理對照與轉址；若連公司郵箱都搬，郵箱歷史資料和收件路徑另有規劃。不要把「網站搬了」誤當所有依賴同一域名的服務已一起完成。

作業準備：列出現有網站的完整依賴

程式、資料庫、檔案與定時任務分開清點

盤點 PHP 版本、資料庫版本、必要擴充、網站檔案、使用者上載內容、程式設定，以及是否有定時匯入商品、產生通知或清理暫存資料。某些檔案可能在網站目錄之外，某些設定藏在環境變數；只備份公開頁面資料夾未必能重建網站。先以備份還原演練的方法找出可重建清單，再把各項交由負責人簽收。

域名、DNS 與電郵不可一筆帶過

列出管理域名的帳戶、目前名稱伺服器、網站相關 A 或 AAAA、CNAME 等紀錄，以及 MX、寄件驗證等電郵紀錄。網站切換通常不需要無端重寫所有 DNS 記錄；若要改名稱伺服器，更須保存整份原始區域資料並確認新位置有齊電郵紀錄。域名持有人及授權帳戶的核對，可參考公司域名管理事項。

搬站前，為網站寫一份測試與回復表

挑哪些網址及操作驗收

公司網站至少選首頁、常見服務頁、舊文章、搜尋及聯絡表單；網店另選商品頁、購物車、優惠、付款回覆和後台查單。每項寫下測試資料、預期畫面、是否會對外寄信或扣款。搬站測試應優先使用不會干擾真客人的隔離設定，避免為了驗證付款而觸發真實交易。功能清單應由日常營運同事覆核，因為他們知道哪些小工具其實每天都要用。

回復不是把 DNS 改回去四字

若新環境正式接單後才發現問題，舊環境的資料庫可能已落後。回復前要保存新環境新產生的資料、訂單與通知，判斷能否核對、合併或以人工方式跟進；若不能確保一致，可能需要暫停新訂單並通知相關人員。回復條件要包括誰批准、甚麼功能算重大故障、要保留哪些證據，以及誰向客服提供一致資訊。

• 訂出切換開始及最後驗收窗口。
• 列出測試網址、表單與交易狀態。
• 指定網站、資料庫、DNS 的操作和覆核人。
• 定義停止、回復與新資料核對的條件。

建立新環境：先用非公開入口驗證

配置相容版本和安全設定

新寄存環境先確定 PHP、資料庫、排程與檔案權限是否符合原網站需要；如要順便升級版本，宜把升級風險獨立列出，避免遷移問題與相容問題混在一起。設定資料庫登入、應用程式密鑰、發信服務和儲存路徑，並檢查不應公開的設定檔未被網站直接下載。網頁寄存方案比較可幫助把環境限制整理清楚。

用測試域名或受控方式看新站

測試入口應限制對外曝光，並避免被搜尋引擎收錄；搬到正式環境時又要確認暫時的限制不會跟着留在正式站。透過合適的測試網址或受控解析檢查證書、頁面載入、絕對網址、圖片和表單，不要只在本機「開到首頁」便視為完成。新舊站若共享外部系統，先隔離測試通知及寫入，免得預備站與正式站同時更改庫存。

資料同步：第一次複製與最後一次同步要分開

先複製大部分，再定最後寫入窗口

第一次可以先複製大量不常變動的網站檔案和資料，以便測試環境；正式切換前，資料庫、商品上載和新訂單仍可能改變，需要清楚記錄最後同步時間。若程式有建立暫存頁面或搜尋索引，也要知道它能否在新環境重新建立。不要把「兩台主機都有網站」當成資料必然一致，尤其是付款通知及用戶上載可能在搬站期間繼續到達。

決定何時停止舊站寫入

若網站容許顧客落單，切換期間需要一個能避免兩邊同時寫入的方案，例如短暫暫停交易並告知使用者。具體做法要依系統能力、業務繁忙時段和可以承受的暫停範圍決定。先在受控測試中計算最後同步與驗證所需工序，然後再向商戶提出時間安排。新站開放接單前，檢查舊站不再接受互相衝突的寫入。

1. 標記第一次複製的資料時間點。
2. 演練最後一次同步，核對資料筆數及抽樣內容。
3. 按批准程序限制舊站寫入。
4. 完成最後同步並由業務同事驗證。

DNS 切換：舊站需要保留一段觀察時間

預先核對 TTL 和授權帳戶

DNS 記錄的 TTL 影響快取持續時間，計劃切換時可事前調整，但仍要預期各地使用者在一段時間內看見不同環境。不能保證所有裝置在同一秒改去新站；亦不能以辦公室一部電腦的測試代表所有人。負責人應先確認自己有權修改正確的 DNS 區域，並保存原記錄；改完後從不同網絡核查實際解析。

何時可以關閉舊環境

新站正式開放後，舊主機先保留觀察，不要切換完立即終止。觀察網站請求、表單、訂單狀態和兩邊是否仍有寫入，必要時找出使用者是否因舊 DNS 快取仍到舊站。等實際使用路徑、資料核對及客服問題都完成，再按合約和安全程序退役舊環境，清走含客戶資料的舊副本。避免長期無人管理兩個可登入的正式站。

切換後檢查：前台、後台和搜尋入口一起看

真實網址和證書

用正式網址測試首頁、重要舊頁、圖片、下載檔案、登入、表單及安全連線，記下 HTTP 狀態和是否出現錯誤轉址。若網址未改，Google 對更換寄存有專門建議，但商戶仍須確認頁面可抓取、原本的標準網址設定無誤。DNS 更新並不會自動修正應用程式內寫死的舊主機地址或不安全資源。

工作系統和郵件路徑

檢查表單通知、訂單電郵、付款回覆及定時匯入是否由新站正常完成，並看發件人與客服收件路徑。若網站和電郵用同一域名，核對 MX 與寄件驗證記錄仍在，切勿把網站新 IP 誤用於公司郵箱。可由負責人各用一個正常收件帳戶做端到端測試，保留郵件標頭供故障排查。

搬站清單一：在第一天就找齊原站資料

不要假設網站只在一個帳戶裏

正式網站可能在一間寄存商，網域於另一個帳戶，DNS 交給第三方管理，圖片放在外部儲存，郵件再由其他服務處理。商戶應用一張簡單清單記下每項服務的用途、帳戶持有人、登入復原方法與實際操作人。登入資料不應散放在多人共用的聊天紀錄；需要交接時由授權人使用合適方式提供。若舊供應商只管理網站檔案，域名仍由商戶自行持有，搬站時要確認誰可改哪個環節。

另外盤點付款服務回調、外部 API 授權、檔案下載路徑與發件信箱。某些外部服務依來源 IP 或通知網址運作，主機環境改變後可能要重新核對；但不應猜測每個服務都必須改。向實際供應商索取設置清單，辨認真正依賴舊環境的項目，再在測試環境逐一驗證。

收集現況的方式要讓日後可對照

搬站前截取幾個重要頁面的實際內容、表單提交後的結果，以及後台代表性資料。對於網店，記下最後一張測試訂單的狀態和商品資料，用來驗證新環境是否一致。不要把客戶的完整個人資料散存於截圖；必要時使用授權的測試帳戶及虛構資料。記錄原本異常的頁面，避免搬站後把舊問題誤當新問題，浪費診斷時間。

對網站檔案，可核對總量、近期上載時間及抽樣檔案能否開啟；資料庫則要檢查主要資料表和欄位是否完整。不宜只用匯出檔案大小判斷成功，因為不同備份工具可能採用壓縮。做一次小規模復原和實際操作，較能證明資料可用。

搬站清單二：兩邊資料何時分岔

付款通知可能晚於客人離開結帳頁

客人按下付款後，網站可能需要等待付款服務回傳結果；若切換時只搬走當時的訂單資料，通知稍後送回舊環境，商戶便可能在新站看到未付款，實際卻已收款。切換計劃要標明付款回調的目的網址、舊站在觀察期是否仍接收通知，以及由誰核對未完成訂單。盡量以可追查的交易識別資訊確認結果，不能單看顧客瀏覽器返回頁面。

同一道理，客服可能在切換期間仍登入舊後台編輯文章，或供應商仍將庫存寫到舊資料庫。通知所有負責人最後可編輯的時間，必要時將舊後台改成只讀或短暫暫停寫入。實作方法要看程式能力，不能只發一封電郵要求大家小心；最終要有機制防止兩套同時當成正式資料來源。

分批搬檔案時核對改動過的部分

相片與下載資料較多的網站，可先複製大部分，再於最後同步期間搬新上載檔案。但要先確認檔案新增與刪除的處理方法：假設職員曾刪除一份過時文件，新站若仍保留早前複製的檔案，可能意外讓舊連結繼續可下載。除了比對新增，還要處理過時檔案、權限和安全設定；刪除涉及原件時先核對是否仍需保留備份。

用幾個不同年代、不同格式的檔案抽查實際下載，亦可找出搬站時大小寫路徑或檔案權限差異。首頁圖片顯示正常，不能證明舊文章附上的檔案仍可讀。將找不到的項目列給內容負責人，由他確認是否補回、改連結或正式移除。

搬站清單三：新主機先回答應用程式相容問題

版本差異需要獨立測試

若舊站採用一個較舊的 PHP 版本，新環境又只提供較新的版本，應先在測試環境找出相容問題，再決定是否先升級程式或調整搬站時間。MySQL 或 MariaDB 的預設排序、時區與字元編碼亦可能不同，關係到資料比對與中文內容顯示。實際設定要以程式原本要求和測試結果為準；不能只因頁面看見文字就推斷訂單排序、登入和特殊符號都沒有問題。

以公司自建 PHP 網站為例，先核對資料庫連線、上載路徑、排程任務、檔案權限和必要的 PHP 擴充。有時正式首頁能開，卻在執行後台大批量匯入時才報錯；因此測試清單應包含平日少用但很關鍵的管理功能。如果程式修改範圍很大，先與商戶分清「為搬站必須修」和「額外功能改善」，避免兩者同時發布增加回復難度。

快取與登入狀態必須在真實路徑測

新環境若使用快取，公開文章可能正常，但登入後台、購物車或個人資料頁若被錯誤快取，便是嚴重問題。以不同測試帳戶檢查彼此是否只見自己的資料；在瀏覽器返回與重新整理後確認購物車仍是正確狀態。不要為追求首頁載入快就快取不能共用的內容。必要時先以保守設定上線，再逐步啟用經驗收的快取項目。

同時核查伺服器日誌和錯誤通知會送給誰。搬站後錯誤若只留在舊供應商帳戶，業務同事可能很久後才知問題。交接文件除了寫新主機 IP，更要寫實際監察入口和故障聯絡方法。

搬站清單四：切換當晚按時間順序記錄

開始前的最後確認

負責人應確認最近的備份可取回、舊站資料最後更新時間、測試域名仍受控、新站證書有效，以及網域管理帳戶可以登入。營運同事要知道甚麼時候停止新增文章或處理訂單；客服應準備回應客人查詢。這份清單不需要看似精密的時間保證，但每個關鍵動作必須有實際負責人和可被確認的結果。

如果其中一個前提未滿足，例如備份檔無法讀取或 DNS 管理權限仍未找到，可以延期，而不應因為已向大家說了搬站日便硬做。延期的判斷權應在作業前寫好，避免現場由最焦急的人決定。把受影響的外部單位聯絡方式準備好，出現付款回調或寄件問題才不會臨時尋找資料。

切換後用不同位置觀察

改動 DNS 後，由不同網絡查正式網址的解析結果，記錄實際所見，並在新舊環境各看請求紀錄。若有人仍到舊站，先辨認是否本地快取或特定網絡，避免反覆改 DNS 令查證更混亂。對某些不能接受重複提交的流程，舊站可按預先定的方案暫停寫入，給客人一致說明，而不是讓兩套後台各出一張訂單。

觀察期間要用預定樣本實際完成查詢或測試落單，並查後台及通知。訪客能看首頁只是第一個門檻；操作資料對得上、員工找得到，以及舊站無新增矛盾資料，才是比較完整的判準。若發現超出回復條件的問題，先保存診斷紀錄再依指定程序處理。

退役舊環境前的四項交代

第一，確認新環境已建立自己的備份，並成功測試取回主要資料。第二，核對原有網址的內容、媒體及重要操作，在合理觀察期內沒有新缺漏。第三，清楚記錄舊環境是否仍收到郵件或付款通知，交由相關負責人處理。第四，按資料保留與保安要求，決定舊主機資料如何刪除或封存，不讓未更新的後台長期留在網上。

最後把網站現況交予公司管理：域名在甚麼帳戶、DNS 由誰操作、寄存環境版本、備份存放與回復方法、客服如何報錯，以及下一次更新要用哪個測試程序。日後若網站改版或遷走郵件，便有一份可信的起點；如果只留「已搬成功」四字，下一任負責人仍要重新摸索整個系統。

三種切換失敗，要有三種不同回應

網站打得開，訂單卻沒有進新後台

如果前台能接受顧客提交，但新後台沒有訂單，應先暫停可能重複接單的入口，保存顧客畫面、伺服器記錄及付款回調資料，再確定訂單實際寫到哪個資料庫。這可能是連線設定仍指向舊資料庫，也可能是後台查詢條件不符；未有證據前不能刪除任何一邊的資料。財務與客服要一起核對已付款的單，避免只因新後台看不到就通知顧客重新付款。

部分訪客仍到舊站

先看新舊主機的訪問紀錄與外部 DNS 解析，判斷哪些使用者仍受舊記錄影響。短時間內這種情況可能與快取更新步伐有關，但不能因此讓舊站繼續接收相互矛盾的訂單。按照事前協定暫停舊站寫入、顯示清楚的維護說明或引導至新站，具體方法須先在測試中確認可行；商戶亦要留意某些舊頁如果有硬寫的主機 IP，單改 DNS 不能修正。

圖片正常，表單與電郵卻失敗

頁面資源可由新主機讀出，不代表寄件設定、郵件驗證或表單後台都已接通。先用不含個人資料的測試查詢確認網站成功儲存，再沿寄件記錄查是否已送出、被退回或進入垃圾郵件。網域的 MX 管收件，不能將修改 MX 當成網站表單寄件失敗的通用修正。若公司業務需要即時回覆詢盤，先安排人工的後備聯絡方式並向客服交代，不要假裝網站功能已正常。

一頁搬站紀錄，給日後的負責人看

記錄每個版本及測試證據

交接單應有舊新環境的主要配置、備份位置、資料庫匯出時間、最後同步時間、DNS 更改內容及實際生效後觀察。附上重要任務的測試結果，列出誰測、用甚麼虛構資料、是否收到通知。不要在文件內放明文密碼，應記憑證由誰保管及如何按授權取得。若測試未通過但業務決定暫時上線，必須明確記下剩餘風險和暫行做法，避免下一班人以為問題已處理。

不同類型的問題要找不同負責人

域名解析錯誤找 DNS 管理者，資料庫內容不一致找網站與營運同事核對，證書或伺服器錯誤則找相關環境負責人；表單遺失要檢查應用程式與寄件路徑。將聯絡方法與通報次序寫在同一頁，遇到夜間故障時較易協調。不要等出事才查哪位舊供應商有登入權限，尤其是網站和網域不在同一個合約之下的情況。

業務部門也要確認哪些對外事項需要通知，例如表單暫停、下單功能短時間維護或新系統遲收郵件。公開訊息應講事實和下一步，不保證某時間必定完全恢復；技術團隊則用測試紀錄支持恢復決定。

搬站後的第一批內容更新也屬驗收

新環境上線後，安排編輯人員用一篇測試文章驗證建立草稿、上載圖片、預覽、發布與撤回。若網站有排程文章，核對香港時間、排程觸發和前台顯示，不要只測即時發布。管理員登入正常，也未必表示一般編輯者的權限和操作都正常；兩種角色應各完成一次工作。

同時安排客服完成一宗測試查詢、財務核對一張不產生真實扣款的受控交易流程，確保新環境已接住日常工作。完成之後，把測試資料清理規則交給有權限的人處理，不要在正式後台留下一批會干擾報表的假訂單。這一步能顯示網站究竟只是技術上「可開啟」，還是員工確實可以靠它工作。

如果網站在搬站前原本有週期性工作，例如定時寄出通知、更新商品資料或建立報表，應記下下一次預定執行時間，切換後監察該任務是否只在新環境運行一次。舊主機若仍保留排程，兩邊可能重複處理；新主機若忘了設定，則直到日後才有人發現工作停了。用受控資料先試跑，並檢查紀錄與後台結果。

搬站後的首個正常營運日，請日常使用網站的同事再走一次實際任務，不要只靠切換當晚的技術驗收。若有問題，記下出現時間、網址、使用者操作、預期與實際結果，再按影響程度處理。結案時可把這批問題加進下一次搬站的測試清單，讓公司累積自己的作業知識。

切換完亦要留意尚未更新的外部連結或外部服務設定。若供應商仍把通知送往舊主機地址，網站雖然可見，重要工作可能已中斷；應逐項向相關供應方確認現行入口，並保存變更的確認紀錄。

寫清楚搬站後由誰接手

網站搬站流程最後應留下一份可維護的現況：新寄存登入由誰持有、資料庫備份與還原如何做、DNS 管理在哪裏、舊環境何時退役，以及出了問題怎樣找操作紀錄。需要核對主機租用或網頁寄存條件時，把程式版本、網站檔案及重要任務先整理好；若連網站功能也要調整，可一起檢視網頁設計與程式工作。網店交易繁忙者則把網上商店的落單流程列為驗收重點；安排切換前可從聯絡 Black Media開始討論工作清單和回復條件。