專案uat測試簽字通過後，準備期初資料（資料需提前收集、整理）及cutover plan。上線業務範圍，是先試點關鍵業務部門，還是全業務線使用？上線的功能範圍，先上哪幾個模組（保證業務正常流轉前提下），或者全平台上線？舊系統如何處理，是雙系統並存，在途單據在舊系統走完，還是直接關停，資料遷移到新系統中？歷史資料是全部遷移到新系統，還是不處理，舊系統保留查詢入口？再對照上線check list，各方達成一致，確定是否具備上線條件及上線日期。
涉及到主要輸出物，包括：
資料準備情況。應單獨輸出資料遷移策略
全量資料收集策略會議，盡可能地提前召開。明確哪些由it提供，哪些由業務提供，界定業務各自負責的資料範圍；明確哪些是上線前必須提供，哪些可以上線後補錄。劃分的顆粒度要細，否則無法有效驅動資料收集進度，往往該任務為專案關鍵路徑。
除了明確交付時間點，還需明確交付標準。批量匯入的方式，一般需按照新系統的資料模板格式才可以匯入，提前確認模板格式，因為可能與已有系統資料格式差異較大。明確資料匯出、清理、匹配、轉換及匯入的任務項由誰負責。此外，甲方最終提供的匯入資料，即使符合系統模板要求，標準模板可能會存在問題，無法適用，則需匯入校驗或再修改資料格式（資料的么蛾子特別多，因此注重盡可能地提前）。
各項資料交付截止時間點需以郵件方式正式通知相關方。
拉取資料時，保留時間點。
上線後的業務資料補錄，明確到具體哪些資料，分幾批次提供。
系統切換策略及計畫
uat收尾。各模組培訓需覆蓋到不同角色，由甲方種子人員進行培訓利於知識轉移；uat問題列表的處理結果達成共識，同時更新系統配置；進行藍圖設計與uat的匯報工作，對收尾工作進行確認，遺留的藍圖設計文件完成簽字工作。
系統配置策略。配置文件、模組配置的邏輯先後順序、彈性域及值集的更新配置。
資料策略
外圍系統介面策略
上線並行策略。舊系統資料並行時間。功能限制、
上線後運維策略確認
系統上線驗收報告
確認部署上線前，乙方需提供的文件明細項包括：
資料遷移指令碼
清洗後的資料
系統遷移指令碼（遷移步驟描述，遷移任務分派和角色分工，使用者、角色、布局分配、共享規則、觸發器等所有相關技術部署遷移的指令碼以及出現問題的應對措施）
整合點及相關技術部署說明
測試指令碼
部署上線移交過程管理
使用者、角色、布局分配、共享規則、觸發器等系統內部技術規格設定的詳細說明
常見問題-faq
整合相關技術說明
cutover plan步驟
通知使用者
準備通知內容
go/no-go decision
系統通知
凍結使用者
部署功能模組
初始化設定
資料匯入
冒煙測試
啟用解凍使用者
通知使用者
上線交付物checklis
其他
管理預期的重要性。強調系統上線並不意味著業務會馬上被帶動，因為有一些改變，從上線到使用者接受，到最後形成生產力需要乙個過程。需要專案團隊與系統的磨合、理解和接受，先僵化，再優化
衝刺月計畫表
S1專案 開發階段
因s1專案為公有雲部署，開發團隊異地集中，採用遠端辦公方式，無需客戶開發人員承接。所以開發階段主要工作一是跟進度，二是協調介面開發。遠端開發，難在進度把控。特別公有雲專案，若評審通過後定為產品標準功能開發，則要遵照產品的版本規劃。有時由於方案變更 或產品 設計團隊進一步討論，專案二開與產品開發發生轉...
S1專案 專案集
s1專案實施期間，並行開展了其他6個專案，其中與3個存在關聯。碰到的問題如下，乙個業務需求，可以拖長達兩個月。兩個系統互相推脫，對於由哪個系統承載，無法達成共識 對接系統提出的要求，業務對財務 財務對上游系統，兩個專案組調研 方案不同步，進度受影響，方案面臨大改 介面開發，各系統進度不一致 都走企業...
S1專案 測試階段
排主計畫時，uat一般只預留1 2周時間，且遇到趕進度需調整主計畫時，壓縮的往往是測試時間。一是侯世達定律作祟，大家想著萬一uat順利呢，一周使用者測試 一周改bug，時間足夠了 二是從整個專案交付來看，測試顯的 不重要 開發完乙個功能 介面，體現的是實際進度變化，無法縮減，否則系統少功能，是顯性取...