客製軟體上線切換怎麼做
客製軟體要切到正式環境，先寫好一份有順序的切換手冊，寫明每一步由誰做、做到什麼算過、什麼情況退回舊環境。手冊上還沒有負責人和退回條件，就不要把正式環境交給使用者。使用者驗收看的是誰按清單操作，驗收標準看的是什麼算完成；這一份手冊看的是切換當晚的順序。
目錄
切換手冊和驗收清單分開寫
切換手冊是一份當晚照着做的順序：先停哪一項、再搬哪一批資料、改完哪一個位址才讓使用者進來、做完哪一項核對才算切完。使用者驗收回答的是預定使用者有沒有按清單把結果做出來。驗收標準回答的是旁人看得到的結果、誰負責、用示範還是使用者驗收。三份文件可以互相指到版本，不要把驗收清單直接改成切換步驟。驗收怎麼逐條操作，見 客製軟體 UAT 怎麼做。什麼算完成，見 客製軟體驗收標準怎麼寫。
範圍在切換前若還要改，另開變更請求，不要在切換會議上把剛做好的畫面寫進手冊。手冊對上的是已經核准的規格版本。變更怎麼留紀錄，見 客製軟體範圍變更怎麼管。交付仍走 客製軟件、網站與應用程式。手冊的第一行寫規格版本和預計切換的日期時刻，方便事後對回當時簽的是哪一版。
AWS 範本先問做什麼、誰做、何時做
2026年10月20日閱讀的 AWS Prescriptive Guidance 切換手冊範本 寫明，切換手冊應包含切換期間要做的全部活動，切換前的檢查清單同樣要寫。兩份可以併成一份文件，並回答三個問題：要做哪些活動、由誰做、應在何時做。該頁附了切換前檢查、切換手冊和退回計畫的例子，並用任務編號方便溝通。該頁沒有刊登日期，以上依這次閱讀。範本裡的任務是遷移例子，不是客製軟體必須照抄的步驟。
同一頁的切換表列出任務編號、任務、相依、團隊、負責人、計畫開始與結束、實際開始與結束、狀態和備註。例子從通知利害關係人停機、確認來源備份、停止來源服務，到遷移、核對基礎設施、改 DNS、在目標端啟動服務、做技術核對與業務核對、再通知遷移完成。退回表從停止目標端的應用與資料庫服務開始，接着關閉目標伺服器、把 DNS 指回來源、核對 DNS、啟動來源、必要時把資料同步回去、在來源端啟動服務，再做技術與業務核對，並通知已經退回。客製軟體的手冊沿用「每步有負責人、有計畫時間、有實際時間、有狀態」，步驟內容改寫成這次上線真正要動的環境。
微軟清單把切換和可否上線分開
2026年10月20日閱讀的 Microsoft Learn：用上線清單確認方案是否就緒 把清單分成上線就緒、切換、方案範圍覆核、方案驗收覆核、使用者驗收完成、效能測試完成、系統整合測試完成、資料遷移就緒與驗證、外部相依確認、初期營運的變更管理，以及營運支援就緒。該頁沒有刊登日期。切換這一節只列三項：按順序完成全部活動、達到退出條件、在切換的可否上線關口取得利害關係人簽核。
上線就緒裡有一項是建立切換計畫，並考慮全部相依、活動時點、角色與責任、操作說明、驗證步驟，以及每項活動附帶的其他文件。同一節還要求切換遷移用的腳本和程序先測試並由業務簽核，外部相依（例如夥伴系統）對上上線的時程和範圍，並備好正式環境的監控與維護、以及把支援交給支援團隊的安排。這些是該頁列出的準備，不是客製專案必須採購 Dynamics 365 才做得到的事。手冊上把「順序、退出條件、可否上線的簽核人」三行寫出來，才對得上這一節在問的事。
每一步寫負責人和先後
手冊每一行寫：步驟名稱、必須先完成的前一步、負責的人（寫名字，不寫整組）、計畫開始與結束、做完之後旁人看得到的結果、狀態。AWS 切換手冊最佳做法 寫明，要指明執行任務的個人，而不是整隊，才能把責任寫清楚；並建議至少開兩次走讀，邀請任務負責人，最後一次走讀放在實際切換前二至三日，以便當場提出最後的阻礙。該頁同樣沒有刊登日期，2026年10月20日閱讀。走讀的出席和結論寫在手冊封面，不留在聊天裡。
可以平行做的步驟要在手冊上標出來，例如備份和準備目標環境可以同時進行，改對外位址則要等資料停下來之後。同一頁最佳做法 以縮短停機為由，建議把能平行的任務歸在一起，並先標出遷移必須完成的停機時段；若超過這個時段，就對齊一份退回計畫。客製軟體的停機時段由負責正式環境的人寫在手冊上，並寫明逾時由誰宣布改走退回。宣布的人要在關口之前就指名，不要等當天才找。
可否上線由簽核人在關口決定
可否上線的關口放在使用者進來之前，不放在已經對外之後。關口上看三樣：順序裡標成必須完成的步驟是否都有實際完成時間、退出條件是否達到、簽核人是否在手冊上簽名。微軟切換節寫的就是按順序完成、達到退出條件、在可否上線關口取得簽核。簽核人的名字在走讀時寫定。人當天不在，由手冊上預先寫好的代理人簽，不在群組裡臨時改口。
退出條件用驗收裡已經通過、而且和這次切換有關的那幾條，加上這次手冊自己的核對，例如正式環境的登入、關鍵交易走完一筆、舊環境已停止寫入。沒有在驗收裡看過的新願望，不在關口上臨時加進退出條件。臨時要加，回到變更請求，這次切換維持原手冊。關口的結論只寫「上線」或「退回」，並寫時間和簽名。
退回條件事先寫在手冊上
退回不是切換失敗之後才開始設計。手冊裡單獨有一段退回：誰宣布、從哪一步開始、資料以哪一份為準、對外位址改回哪裡、做完哪一項核對才通知使用者仍用舊環境。AWS 應用遷移流程 寫明，應為失敗預做準備；遷移若不成功，就執行切換計畫裡已經寫出的退回程序。最佳做法頁則把「超過停機時段」寫成要對齊退回計畫的一種情況。兩頁都在 2026年10月20日閱讀，都沒有刊登日期。
客製軟體常見的退回觸發，寫在手冊上由負責人預先勾選，例如：技術核對或業務核對沒有過、停機時段已過仍不能讓使用者進來、正式環境寫入了無法對回舊環境的資料。觸發一出現，按退回表的順序做，不在當場改順序。AWS 範本的退回從停止目標端服務開始；若這次上線沒有「目標伺服器」這一步，退回表改寫成這次真正要還原的環境，仍保留負責人、狀態和通知。退回做完，在手冊末行寫實際完成時間和通知了誰。
切完之後核對再通知
切換表的後段是核對，不是宣布完成本身。AWS 範本把切換後的應用測試分成技術核對和業務核對，然後才通知主要利害關係人遷移完成。客製軟體沿這個次序：負責正式環境的人先看服務是否起來、關鍵交易是否走完；預定使用者或業務負責人再看一筆真實業務是否和手冊寫的結果一致。兩筆核對都有時間和簽名，才發「已經切到正式環境」的通知。通知裡寫支援由誰接、從什麼時候開始。
微軟營運支援就緒一節要求：正式環境有監控和維護計畫、實施團隊把營運支援交給支援團隊、支援人員受過訓練並有工具和權限、服務台和工單程序已經就位、系統可以進正式環境時通知利害關係人並提供支援聯絡人。該頁把上線後提高支援力度的安排稱為 hypercare，並把它列在營運支援與維護計畫應包含的項目裡。客製專案把這段支援的起迄、負責人和聯絡方式寫在手冊最後，不另發明一套時限。來源環境何時停用，等業務核對和健康狀況都寫進手冊之後再定。
手冊沒寫完就留在舊環境
負責人、退回條件、可否上線的簽核人，這三樣有一樣還沒寫上名字，切換日就繼續用舊環境。先補名字和退回表，再改切換日。走讀沒做、或最後一次走讀上仍有未關閉的阻礙，同樣不把使用者指到新環境。阻礙寫在手冊的問題紀錄裡，寫明誰跟、何時再看。
停機長度、缺陷數和支援時限留在公司自己的規則裡，並註明日期。AWS 範本頁和微軟清單頁都沒有給客製專案指定這些數字。手冊寫完之前，用三件事看這次切換有沒有準備好：每一步是否有個人負責人和先後、可否上線是否有簽核人、退回是否寫了觸發和順序。三件事都在手冊上，才把切換日寫進通知。