QlikView 遷移：先盤點，再決定要不要動
什麼是 QlikView 遷移
QlikView 遷移，是指把既有的 QlikView 應用轉到 Qlik Sense 或 Qlik Cloud Analytics 的過程。由於兩者的應用結構不同，這不是一次版本升級，而是需要重建應用，但腳本邏輯與數據模型通常可以大量沿用。
真正的工作量不在技術轉換，而在判斷：哪些應用還有人在用、哪些可以直接廢棄、哪些該趁機重做。這一步做對了，項目規模往往比客戶原先預期的小很多。
除了 QlikView 轉 Qlik Sense，我們也承接本地環境轉雲端、雲平台之間的搬遷、Qlik NPrinting 環境遷移，以及 Qlik Sense 的版本升級。完整服務範圍見服務總覽。
QlikView 遷移：現在到底急不急
真正的壓力來自兩處。第一，自 12.60 起，原廠對每個 QlikView 初始版本只提供二十四個月的技術支援。第二，部分舊組件正在陸續退場 – 例如 QlikView OCX 與 QlikView Source Control，自 2026 年 9 月版本起不再維護或支援。
所以判斷急不急，看的不是傳言，是你現在跑的版本落在下表哪一格。
| 版本 | 發布日期 | 支援結束 | 你的處境 |
|---|---|---|---|
| 12.100 | 2025 年 9 月 | 2027 年 9 月 30 日 | 仍在支援 |
| 12.90 | 2024 年 5 月 | 2026 年 10 月 | 窗口將盡 |
| 12.80 | 2023 年 5 月 | 2025 年 5 月 23 日 | 已無支援 |
| 12.70 | 2022 年 5 月 | 2024 年 5 月 10 日 | 已無支援 |
| 12.60 及更早 | 2021 年 5 月及之前 | 2023 年 5 月及之前 | 已無支援 |
生命週期日期以原廠官方公布為準，實際請以 Qlik 官方 QlikView 生命週期頁為準；本表僅供快速對照。
仍在支援：可以慢慢規劃
不必趕。建議先做一次應用盤點，摸清楚哪些還在用，把遷移排進未來一到兩年的預算裡。盤點本身花不了多少時間，但能讓你之後的決策有依據。
窗口將盡：該啟動盤點了
支援結束後遇到問題只能靠自己。這個階段適合先做盤點與試點重建，驗證方法可行，再決定是升到新版 QlikView 續命，還是直接遷到 Qlik Sense。
已無支援：風險在累積
作業系統或資料庫一升級就可能出事，出事了原廠不受理。這種情況下，即使不立刻遷移，也建議先做一次環境健康檢查，至少知道風險在哪裡。
QlikView 遷移：我們怎麼做
圖 1 遷移項目的五個階段
第四階段是最容易被壓縮的一段，也是最不該壓縮的一段。跳過並行驗證直接切換，出問題時你既沒有對照組，也回不去。我們的做法是舊環境保留到業務簽字確認為止，這一條會寫進方案。
動手之前，先回答這六個問題
到底有多少支應用
不是伺服器上有多少個檔案，而是有多少支還在被實際打開。兩個數字往往差好幾倍。
誰在用，多久用一次
每天看的、每月看一次的、一年看一次的，處理方式完全不同。有些應用改成定時報表派送就夠了。
腳本現在誰看得懂
當初寫的人還在不在。不在的話，遷移同時就是一次補文件的機會，不要浪費。
數據源會不會一起變
如果 ERP 或資料庫也在換，兩件事最好排開做，不要同時動。同時動，出問題查不出是誰的責任。
授權夠不夠用
Qlik Sense 與 QlikView 的授權模型不同，用戶數與使用形態要重新算。這一步不做，預算會超。
有沒有不能停機的時段
月結、季結、年報期間通常動不得。切換窗口要提前圈出來，不然臨門一腳被迫延期。
產品線與版本的官方說明可參考 Qlik 官方網站。這六個問題我們可以在一次免費諮詢裡陪你過一遍，不需要你先準備資料。