SaaS解約與系統移轉實務｜自動續約的通知期限、資料匯出、雙軌並行

大家好，我是株式會社TIMEWELL的濱本 隆太。

決定解約SaaS、改由自家公司重新打造之後，第一個碰到的不是技術的牆，而是日期。以年為單位簽約的SaaS，常常附有自動續約條款；要停止續約，必須在續約日之前的某個期限內通知對方。只要晚一天，就得為原本打算不再使用的服務再付一年的費用。

熟悉更換雲端服務的公司並不多。日本公平交易委員會在2022年公布的報告中，詢問了年營收50億日圓以上、使用IaaS或PaaS的548家企業，過去10年曾更換雲端業者的只有15.7%。若目前使用的服務漲價5到10%，回答會改用其他服務或回到地端環境的，在排除「不知道」之後的回答中也只占14.1%¹。這些數字並非只針對SaaS，但可以推想，公司內部真正走過解約與移轉流程的人並不多。

本文是探討解約高價SaaS、轉為自行開發的五篇系列文章中的第四篇。要不要解約，請參考第一篇的判斷標準；自行開發與繼續使用的總成本，寫在第三篇的五年總成本試算。這一篇談的是決定之後的步驟，依序是通知期限、資料匯出、資料移轉、雙軌並行、終止後確認刪除，最後附上從續約日倒推的時程表。

先說明一點。本文談到的合約條款與法令都是一般性的說明，合約內容因業者、因合約而異。個別合約請務必與自家的合約文件及法務部門確認。

解約的真正期限是「續約日前30天」

以一家大型SaaS業者公開的主合約為例²。合約寫明，除非訂購單另有規定，訂閱會每年自動續約；只有在任一方於合約期間結束前至少30天以書面（可用電子郵件）通知時，才不會續約。換句話說，解約在實務上的截止日不是續約日，而是續約日的30天前。續約日若是4月1日，期限就落在3月初。

同一份合約裡，還有兩項容易被忽略的條款。一是費用條款：費用依購買的訂閱數量而非實際使用量計算，已付費用不予退還，合約期間中途也不能減少購買數量。就算有沒在用的帳號，期間內也只能繼續付費。

另一項是續約條款的後半段。若續約時的訂閱數量比前一期少，或合約期間縮短，續約價格會重新設定，不沿用前一期的單價。以促銷價或一次性價格簽約的，續約時也會改用當時的定價。

把這兩項合在一起看，就能明白為什麼「全部停用之前，先留幾個授權用來查閱資料」這種常見的階段性縮減方案，不一定像想像中那麼省錢。一減少數量，原本的折扣就可能消失。要縮減後保留，還是直接全部停用？應該先取得續約報價，再來比較。

除了期限，也要確認通知的方式與對象。需要書面嗎？電子郵件可以嗎？還是要在管理後台辦理？合約上的通知窗口是哪裡？如果是透過經銷商購買，通知的對象也可能是經銷商。不論用哪一種方式，都請留下日後能證明對方已收到的紀錄。

還有一點，手上的合約不一定是最新版。以線上服務條款簽約的SaaS，業者可能已經修改過條款。日本民法第548條之4規定，對於「定型約款」（業者為了與不特定多數人交易而預先準備的制式條款，概念接近台灣所說的定型化契約條款），若變更符合相對人的一般利益，或依變更的必要性、變更後內容的相當性等情況判斷屬於合理，業者可以不經個別同意而變更契約內容；相對地，業者必須訂出生效時間，並透過網路等適當方式公告變更的事實與內容³。企業用SaaS的條款是否屬於定型約款，需要個案判斷；但無論如何，該讀的不是幾年前簽下的版本，而是現在有效的版本和修訂紀錄。

資料匯出，要在決定解約之前先試一次

期限之後，最容易出問題的是資料匯出。日本資訊處理推進機構（IPA）的《中小企業雲端服務安全使用指南》（2026年6月）把「確保使用結束時的資料」列為第13項確認項目，要確認的內容包括：全部資料的返還或下載到自己的電腦、資料的相容性與可攜性、殘留資料的完全刪除，以及保證其他使用者無法再利用⁴。

前面提到的主合約寫明，只要在合約終止後30天內提出要求，業者就會讓客戶匯出或下載資料；超過30天，業者就沒有保存資料的義務，之後會刪除²。30天看起來夠用。但如果終止之後才第一次匯出，發現附件沒有匯出、變更紀錄不見了，那時已經無法再回到舊系統處理業務。

所以，請在決定解約之前，用正式環境的全部資料實際匯出一次。我認為至少要確認以下五點。

要確認的事	漏掉時會發生的事
匯出的筆數和系統畫面上的筆數是否一致	只匯出了一部分，卻沒有人發現缺漏
附件是否一起匯出	只有內文搬走，單據和圖面留在舊系統
變更紀錄、留言、簽核紀錄是否匯出	遇到稽核或客訴時，無法追溯經過
使用者、組織、權限資訊是否匯出	誰能看什麼，要在新系統從頭設定
字元編碼、日期格式、欄位意義是否清楚	匯入時出現亂碼或日期錯位

這張表不是從公家指南抄來的，而是我認為必須確認的項目。

資料匯出遇到困難，並不少見。日本公平交易委員會的報告中，收錄了使用者的意見：「群組軟體很難把資料帶出來，一旦開始使用就不容易更換服務，也曾經不得不接受漲價。」在針對IaaS與PaaS使用者的問卷中，也有使用者把取出資料的費用，以及新舊服務的資料格式不同、必須加工，列為難以更換的原因¹。

日本政府的方針也要求在一開始就確認這一點。日本數位廳的標準指引DS-310規定，應選擇資料可攜性有保障、並公開合理價格體系等條件的雲端服務，藉此避免被單一業者綁住（vendor lock-in）⁵。這原本應該在簽約前確認；但對現在正在考慮解約的人來說，只能從現在開始確認。

在歐盟設有據點、並在當地簽訂SaaS合約的公司，還多了一項可以運用的權利。歐盟《資料法》（Data Act）自2025年9月12日起適用，要求PaaS與SaaS業者提供開放介面，並至少能以常用、機器可讀的格式匯出資料。從2027年1月12日起，業者不得再收取包含資料傳輸費在內的更換費用⁶。根據律師事務所的解析，合約中也必須寫入讓客戶最多提前2個月通知即可開始更換、並在通知期間結束後最多30天內完成移轉等條款⁷。不過適用對象是提供給歐盟境內客戶的服務，不一定直接適用於日本或台灣總公司簽訂的合約。是否適用，請與法務確認。

移轉的資料要縮小範圍，並把後段的返工排進計畫

匯出的資料要怎麼放進新系統？這裡可以參考IPA的《引導系統重建成功的使用者指南（第2版）》。這份指南並非專門談從SaaS移轉，但關於資料移轉計畫的內容，可以直接套用⁸。

指南首先指出，資料移轉計畫若太晚開始檢討，可能嚴重影響整個專案的計畫甚至成本。因為事前要確認的面向很多，例如移轉對象和資料的版面配置，還需要資料清理（修正錯誤值與重複資料），準備很花時間。接著，指南列出容易出問題的六個面向：整理移轉對象、確認版面配置、資料清理、字元編碼的轉換對照、選定移轉方式、確認移轉結果。

我認為效果最大的是第一項「整理移轉對象」。指南說，全部移轉會增加工作量、時間與成本，最好縮小範圍，並舉例說明要明確訂出「運作期間3年以前的資料或交易資料就捨棄」這類移轉範圍的方針。SaaS用久了，會累積好幾年的紀錄，但新系統日常並不會用到全部。只移轉最近幾年的資料和仍在進行中的案件，較舊的資料就以匯出的檔案放在唯讀的保管空間。光是這樣，轉換和核對的工作都會大幅減少。不過，對於法令或公司規定有保存期限的紀錄，要確認放在保管空間的檔案隨時都找得到、取得出來。

指南還寫道，資料移轉造成的問題會在開發後段才浮現，因此解決問題的時間也要納入計畫。因為只有讓真實資料實際跑過，才會出現預料之外的數值，以及在畫面上看不到的欄位用法。移轉演練不要以為一次就能完成，請以至少兩次為前提安排時程。

移轉的難度也反映在統計上。IPA的《DX動向2025》詢問了334家正在推動自行開發的日本企業面臨哪些課題，「人才難以招募或培育」以82.3%遙遙領先，「外部開發的系統難以轉為自行開發維護」也有19.5%⁹。在自行開發的各項工作中，移轉是特別需要人手與經驗的環節。如果公司內部難以支應，只在這個環節借助外部力量，是合理的判斷。

雙軌並行，要在已付費的最後一個合約期間內結束

新系統上線後，會有一段時間讓舊SaaS和新系統同時處理相同業務，再比對結果，也就是雙軌並行。IPA的重建指南把雙軌並行列為上線後的風險對策之一，說明是在一定期間內，於現行系統與新系統上執行相同作業，找出故障。指南提醒兩點：業務單位的負擔會增加，要確認業務單位能承受多久的雙軌並行；以及要確認能否在現行系統的EOL（停止提供）或EOS（停止支援）期限內完成⁸。

對SaaS來說，這個「現行系統的期限」就是合約的終止日。由此可以導出我建議的做法：雙軌並行要在已經付費的最後一個合約期間內進行，並在解約通知期限之前做出結論。如果像範例合約那樣，費用依購買數量而非使用量計算、也不退款，那麼在這段期間繼續使用舊SaaS，不會產生額外費用。反過來說，如果雙軌並行還沒結束就碰上通知期限，就只剩兩個選擇：在還不知道新系統表現如何的情況下送出解約通知，或是保險起見再續約一年。這兩個都是想避免的選項。

雙軌並行該做多久？我沒有找到公開的參考標準。我的看法是，至少要讓業務跑完一個週期。有月底結帳的業務，就讓新舊系統各跑一次結帳；有季度彙總的，就跑一次季度彙總。因為日常輸入都正常、只有結帳處理得出不同結果，這種情況並不少見。

比期間更該先決定的，是結束的標準。重建指南指出，測試的完成標準若不明確，就無法判斷是否完成，可能陷入永遠做不完的狀況，而比對新舊結果的測試特別容易如此。因此，應以量化的標準定義「業務能持續運作」，並在實施前與相關人員取得共識⁸。例如「結帳金額新舊一致」「同期間的筆數一致」「若有差異，能說明原因」這類標準，要在雙軌並行開始前寫下來。對業務單位來說，知道重複輸入什麼時候結束，也是願意承擔負擔的理由。

附錄：從續約日倒推的解約與移轉時程表

以下把前面的內容整理成從續約日倒推的時程。這是以「續約日前30天為通知期限」為前提的一個例子，各階段需要多久，會因業務量和合約而不同。如果通知期限不同，請依差距調整表中的時間。

時間（以續約日為基準）	要做的事	主要負責
6個月前	蒐集合約、訂購單與現行有效的服務條款；確認續約日、通知期限、通知方式與對象、資料返還條款；開始盤點資料，區分要移轉的和只需保管的	採購、法務、資訊部門
5個月前	用正式環境全部資料試做匯出，核對筆數、附件、紀錄與權限；開始製作新系統的試作版	資訊部門、開發
3個月前	第一次移轉演練，修正不一致的資料；決定雙軌並行的完成標準，並與業務單位取得共識	資訊部門、業務單位
75天前至40天前	雙軌並行，跑完一個業務週期（例如月底結帳）；以第二次演練確定匯入程序	業務單位、資訊部門
40天前	依完成標準判定，公司內部決定是否解約；與縮減數量續約的報價比較	經營層、資訊部門、採購
通知期限（30天前）的前幾天	以規定的方式送出通知，並留下送達紀錄	採購、法務
續約日前一天為止	最後一次匯出與匯入，切換使用者	資訊部門
終止後30天內（以範例合約而言）	最後確認有無漏匯的資料，並假設超過期限就無法再取得	資訊部門
終止後	確認殘留資料已刪除；停止系統串接，刪除帳號與認證設定，確認已停止扣款	資訊部門、財會

看到這張表，可能有人會發現離下次續約已經不到6個月。這種情況下，與其勉強在這一期停掉，不如把目標放在下一次續約日，從試做匯出開始，結果通常反而比較省。為了趕上這一期的期限而縮短雙軌並行，代價會在切換之後落到業務單位身上。

表上最後兩列，是最常被遺忘的工作。IPA的指南之所以把殘留資料的完全刪除，以及保證其他使用者無法再利用，列入使用結束時的確認項目，是因為解約不代表資料會自動消失⁴。有些業者像範例合約一樣，規定在寬限期後刪除資料，但使用者如何確認資料何時被刪除，各合約不同。能否請業者出具刪除證明？如果不能，要用什麼方式確認？最好在送出通知之前就問清楚。

資訊安全標準也開始關注這個步驟。資訊安全管理系統（ISMS）的驗證標準、日本工業標準JIS Q 27001:2023（等同ISO/IEC 27001:2022），在附錄A的控制措施中新增了「8.10 資訊刪除」¹⁰。對運作ISMS的公司而言，解約SaaS也是留下這項控制措施紀錄的時機。同時，也要停用原本連到舊SaaS的單一登入（SSO）設定、API金鑰，以及其他系統的自動串接。串接若還留著，其他系統會持續嘗試把資料送到已經解約的服務，造成難以追查的錯誤。

我們的FDE能做什麼

TIMEWELL提供FDE（Forward Deployed Engineer）服務。FDE是深入客戶現場，把問題做成可運作軟體的工程師。我認為SaaS的解約與移轉，正是FDE的工作方式可以直接套用的環節。

具體來說，在上面的時程表中，我們會和客戶一起推動從試做匯出到最後匯入的技術工作；是否解約的判斷，以及向業者送出通知，則由客戶自行處理。我們會建立匯出正式環境全部資料、核對筆數與附件的機制，用遮蔽個人資訊等內容的資料讓新系統的試作版跑起來，撰寫轉換與資料清理的程式，並在雙軌並行期間設置自動比對新舊結果的機制。和業務單位一起用數字訂出雙軌並行的完成標準，也是FDE在這個環節的工作。期間一開始就以45到90天為目標區隔，並先決定結束條件再開始。

新系統要放在哪裡、怎麼放，寫在第五篇：把業務應用程式放在自家雲端租戶的設計。一開始該把哪些業務列為自行開發的候選，請從第二篇的判斷方法看起。FDE的整體進行方式，整理在FDE的服務頁面。

與委外開發的差異

把移轉交給外部時，有一點要注意。停用SaaS的目的之一，應該是讓業務不必依賴特定業者也能運作。如果移轉後留下只有承包商才能修改的系統，只是把依賴的對象換掉而已。

這正是我們把FDE和委外開發分開看待的原因。委外開發的工時就是營收，雙軌並行拖得越久、返工越多，承包方的營收就越多。我們依期間而不是工時累積來決定費用，不簽拖得越久越有利的合約。我們把工時視為讓下一個案子更快的投資。像匯出核對、新舊比對這類其他公司也用得上的機制，會培養成我們產品的元件，在下一個案子再利用；只屬於客戶的流程，則作為客戶的設定保留下來。而且，一開始就決定結束的方式：當客戶的承辦人能自己修改移轉後的系統、自己匯出資料時，我們的工作就結束了。

我們的實務與限制

坦白說明。首先，合約談判和法律判斷不是我們的角色。我們可以協助從合約中找出續約日與通知期限、整理成時程表，但條款怎麼解讀、如何與業者談判，是客戶法務部門的工作，必要時則是律師的工作。送出解約通知的，也是身為合約當事人的客戶。

其次，匯不出來的資料，我們也匯不出來。SaaS的匯出功能或API不支援的資訊，只能從畫面手動抄寫，或是放棄。盡早試做匯出的理由之一，就是為了及早做出這個判斷。

在移轉作業中，如果我們會接觸到個人資料，我們就是受託處理個人資料的一方。日本個人資訊保護法第25條要求委託方對受託者進行必要且適當的監督¹¹。我們已取得ISO/IEC 27001驗證（驗證範圍：運用AI技術的SaaS產品之企劃、開發與提供），但這並不會免除委託方的監督義務。委託合約以及會接觸的資料範圍，會在作業開始前確定。

我們也不認為所有SaaS都應該解約。像會計、薪資這類必須持續跟上法令與會計規則變動的業務，交給SaaS或套裝軟體，多半更合理。本文的步驟是根據公開的指南與公開的合約條款整理而成，並非特定客戶的案例。最後是產能：我們是小公司，能同時進入的現場數量有限。

總結

SaaS的解約與移轉，要從續約日往回推算。重點有四個。

• 通知期限不是續約日當天，而是更早。範例合約是30天前，減少數量續約時單價會重新設定
• 資料匯出要在決定解約之前，用正式環境全部資料試做。範例合約終止後的寬限期只有30天
• 移轉的資料要縮小範圍，並以後段會出問題為前提，安排兩次演練
• 雙軌並行要在已付費的最後一個合約期間內，依事先訂好的標準結束

這些都是不起眼的工作。但只要錯過一次通知期限，停用SaaS原本能省下的錢就會延後一年。不妨先打開手邊的合約，把續約日和通知期限寫進行事曆。

如果您正在找能一起推動解約、移轉與雙軌並行的夥伴，歡迎參考FDE的服務頁面，或透過FDE個別諮詢和我們聊聊。如果想重新確認是否真的該解約，請回到系列的第一篇（判斷標準）。

Footnotes

1. 雲端服務領域交易實況報告（日本公平交易委員會，2022年6月28日）。更換經驗與漲價時的因應見第49至50頁（IaaS使用者419家與PaaS使用者129家的問卷，2021年7至8月實施），難以更換的原因見第52頁，使用者對群組軟體漲價的意見見第92頁。另見新聞稿。日文，書名與引文為筆者譯 ↩ ↩²

2. 依據一家大型SaaS業者公開的主合約（英文版為2026年9月1日版，日文版最後更新於2026年6月1日）中關於費用、合約期間與客戶資料返還的條款。本文目的不在評價特定業者，故省略業者名稱與連結。合約條件因業者與合約而異 ↩ ↩²

3. 日本民法（明治二十九年法律第八十九號）第548條之2（定型約款的合意）、第548條之4（定型約款的變更）。e-Gov法令檢索，日文 ↩

4. 中小企業雲端服務安全使用指南（IPA，2026年6月）。確認項目第13項「確保使用結束時的資料」（第27頁），日文，書名為筆者譯 ↩ ↩²

5. DS-310 政府資訊系統適當使用雲端服務的基本方針（日本數位廳，2025年5月27日）。「3.3 關於供應商鎖定」（第12頁），日文，書名為筆者譯 ↩

6. Data Act explained（European Commission）。適用日期、PaaS與SaaS的資料匯出、更換費用的廢除依該頁面 ↩

7. EU Data Act: Significant New Switching Requirements Due to Take Effect for Data Processing Services（Latham & Watkins，2025年8月19日）。通知期間與移轉期間的上限依該解析（條文編號本文未確認） ↩

8. 引導系統重建成功的使用者指南 第2版（IPA，2018年2月）。測試完成標準見第114頁，表3.9「風險對策範例」（雙軌並行）見第115頁，3.8「資料移轉計畫」與表3.11見第119至121頁。日文，書名與引文為筆者譯 ↩ ↩² ↩³

9. DX動向2025（IPA，2025年6月）。圖表2-16「推動自行開發的課題」（第45頁，2024年度調查，推動自行開發的日本企業 n=334），日文 ↩

10. ISMS使用者指南（JIPDEC，JIP-ISMS111-4.0，2025年3月31日）。表A-2「新增的控制措施」（第74頁），日文 ↩

11. 日本個人資訊保護法（平成十五年法律第五十七號）第25條（對受託者的監督）。e-Gov法令檢索，日文 ↩