4. 修正階段

汰換系統或是擴大資料欄位，同時並修改相關的應用程式。倘發現程式有年序問題，則需修改程式，修改的地方除了程式外，也要查看資料庫有關年的欄位是否要一併修改。修改程式涉及資訊專業，若無資訊專業人員，強烈建議委託資訊專業人員修改，以免系統發生更大的錯誤。問題的修正，分為「原始程式及環境還存在」及「原始程式或環境已不完整」兩大項說明。

(1)           原始程式及環境還存在

除了原始程式外，尚需要確定其他的環境都完整，才有可能修改程式，否則修改過的程式不能被重新編譯成執行檔。如果原始程式及環境還存在，企業有以下的選擇：

ú             自行修改－自行修改程式比較可以控制時程，也較省錢。

ú             委託原開發資訊廠商修改－如果還能找到原開發的資訊廠商，委託原廠商修改是比較保險的作法。惟修改的時程、進度與品質要能掌控。

ú             委託資訊廠商重新開發系統－若覺得系統已老舊，或功能已不敷使用，或許委託資訊廠商重新開發新系統是聰明的決定。

ú             採購符合需求且市面已有之產品－如果市面上已有合用且成熟的產品，則購買新產品是更好的決定。

(2)           原始程式或環境已不完整

若原始程式或環境已不完整，則無法修改原程式，企業只有委託資訊廠商重新開發系統，或採購符合需求且市面已有之產品這兩種選擇。

5. 測試階段

除了基本的單元測試以外，須有嚴密的整合測試計畫，以檢視出清查與修改階段的疏漏。不管是自行修改程式或委託開發或採購新產品，必需對新系統做完整的測試，以確保新系統能正常運作。測試時最好在測試環境下進行，以免干擾到原系統的正常作業。測試的方式，通常至少要測三種狀況，一是輸入民國99年12月下旬日期的資料，看看是否正常輸出。二是輸入民國100年1月1日的資料，看看是否正常輸出。三是輸入民國100年1月2日以後的資料，看看是否正常輸出。

6. 上線階段

若測試通過，則開始準備新舊系統的轉換。系統轉換時需考量舊資料或舊資料庫資料是否要先轉換。如果是修改原程式，但沒有修改資料庫，應該不需做資料轉換。如果有修改資料庫或重新開發或採購新產品，則需要做資料的轉換。資料轉換完成，新系統才能上線。當新系統上線運作後，在跨民國百年過程中，仍要密切注意新系 統的運作，最好要先有緊急應變的方案，以免萬一發生意外，能降低災害的衝擊。

全球矚目的千禧蟲危機已過十個年頭，如今因民國紀年即將破百，百年蟲危機卻才剛開啟序幕，雖影響層面並非全球性，但畢竟華人世界使用民國年者不在少數，企業主仍應戒慎以待，尤其國內仍有使用老舊資訊系統的中小企業，其存在潛在的風險更是不可輕忽。

而除了Y2K和百年蟲外，事實上因年份導致系統”溢位”的未爆彈並不止這兩樁，過幾年還會遇到Y2K38，也就是所謂的Unix 千年蟲，因為它只存在世界上廣泛用作伺服器軟體的Unix系統中。根據維基百科的解釋，由於傳統的Unix系統使用32位元的整數來記錄時間，這個整數表示的是從1970年1月1日開始算起到現在時間經過多少秒。然後32位元整數最多可以表示到2的32次方，所以以此類推，到了西元2038年將會超過上限，而從0秒繼續計算。這就可能引發今日相同的問題。然而在未來可能大部分的作業系統都會變成64位元，預計會在2038年以前完成，新的64位元系統，可以記錄到約2900億年後的時間，所以也不用過度擔心。

另外還有被當作笑話看的”萬年蟲”，也就是西元10000年的問題，它是所有軟體可能在表示五位數年份時發生的問題的總稱。先前早在Y2K問題燒得火熱時，10000年問題就曾被以幽默的方式被人們在媒體中披露。實際上這一點也不令人意外！因為部份程式在處理日期時只會顯示末4碼的年份，導致10000年被顯示為"0000年"，這問題可以在目前相當普及的試算表軟體Microsoft Excel中發現。因為它以"自1899年12月31日起經過的天數"來儲存日期（以此規則，第1天是1900年1月1日）。

在資料庫軟體Microsoft Access中也有同樣的問題。它以"自1899年12月30日起經過的天數"來儲存日期（第一天是1899年12月31日）。在上述任一個程式中，輸入第2958465天會產生日期9999年12月31日。即便有些機構正嘗試促進以5位數，建立書寫與記錄年份的習慣，例如把2010年記錄為"02010"，如此將可預防10,000年問題，但這同樣將再次遇到100,000年問題。

從這個極端例子可以看出，日期問題其實對電腦計算來說，就如同浩瀚的宇宙般，都是無窮無盡的，除非地球停止轉動，否則蟲蟲危機續集將不會只有趴兔，還會有趴三、趴飼…，永遠也沒有上演最終回的一天，只不過那其實也沒啥太大影響就是了。