已經天天在用飛書的團隊，當海外分公司、遠端員工與國外客戶越來越多，遲早會問一句：要不要把重心搬到 Lark？真正卡住這個決定的，通常不是介面（飛書與 Lark 長得幾乎一樣），而是帳號體系分離、資料落地與跨境合規這幾件事。介面好學，但帳號、資料與流程要在新家重新長出來，這才是遷移真正的工作量。
利益先講在前面：我們是 Lark 台灣授權代理商，立場自然有偏向，所以只寫可被檢驗的事。品牌關係與資料存放附官方頁面與查核日期（2026-08-13 查核），Lark 的產品行為附我們的知識中心出處，庫裡沒有的做法就老實寫「建議與我們確認」，不替官方發明不存在的一鍵工具。想先弄懂飛書與 Lark 到底是什麼關係、該不該搬，可以先看飛書 vs Lark 的選擇指南；這一篇則假設你已經決定要搬，把搬的過程拆開來講。
為什麼跨境團隊會想從飛書搬到 Lark
跨境團隊把重心從飛書換到 Lark，動機通常集中在三個地方：資料存放地、海外連線的順暢度，以及在地合規與服務。功能本身反而很少是主因，因為兩者核心模組高度重疊，日常用起來差別不大。
第一個、也是最該先確認的，是資料存放地。依飛書官方隱私說明，飛書會依法把境內運營過程中收集的個人資訊存放於中國大陸境內；而依 Lark 官方隱私權政策，Lark 的伺服器位於美國、新加坡與日本。對在中國大陸以外營運、需要向客戶或稽核交代「資料不落地中國大陸」的企業，Lark 的存放地通常更貼近需求。企業對自己持有的個人資料本來就負有安全維護責任，跨境資料的落點與合規細節，導入前建議一併諮詢法律與資安專業，別只憑一頁隱私政策就下結論。
第二個是海外連線的順暢度。飛書的基礎設施以中國大陸為主，海外或跨國團隊跨境存取時，體驗會受兩地網路環境影響；Lark 的基礎設施面向海外，跨國團隊使用通常較順。對於有海外分公司、遠端員工，或常跟國外客戶開會的團隊，這個落差可能反映在會議與檔案存取的順暢度上，值得在導入前用實際情境測一輪再決定，而不是聽人說了就信。
第三個是在地服務。Lark 本身就內建繁體中文介面，語言不是問題，任何管道導入都能切換，繁中並不是「找代理才有」的東西。真正的差別在採購與支援：透過台灣官方授權代理導入，可取得在地技術支援、正式發票與導入輔導，這些在跨境直接向原廠採購時往往拿不到。想先認識這套產品整體能做什麼，可延伸讀認識 Lark。
要先釐清一個常被混淆的點：搬到 Lark，跟「飛書與 Lark 兩邊並用」是兩條不同的路。官方確實有跨境關聯的機制能讓兩邊協作，但那是橋接、不是搬家；如果你的重心其實還在中國大陸，也許並用才是答案。
遷移前盤點：組織、文件、Base 與機器人四類資產
動手搬之前，先把飛書上的資產盤成四類：組織與成員、雲端文件與知識庫、多維表格（Base）、機器人與自動化。每一類的搬法和難度都不一樣，混在一起想只會越想越亂，而盤點這一步花的時間，會在後續每個環節省回來。
組織與成員是第一類，也是最需要重做的一類。飛書與 Lark 帳號體系分離、客戶端預設不互通，成員無法沿用飛書帳號直接登入 Lark，組織架構、部門與權限角色都要在 Lark 端重新開通與設定（管理後台的成員與組織管理是這一段的操作起點）。盤點時先把「誰要開通、對應哪個部門、給什麼權限」列清楚，這份名單也是之後分批切換的依據。
第二類是雲端文件與知識庫。文件、表格與知識庫頁面不會跟著帳號自動搬家，需要匯出再匯入。這一步正好是重整單一真實來源的機會：先分流出「還要繼續維護的」與「只需封存查詢的」，別把用不到的舊資料一起扛過去。Lark 知識庫的匯入清單支援 Confluence、Word、Excel、CSV、多維表格（.base）、PowerPoint、XMind 等格式轉為對應的雲端檔案，雲端文件也可以匯入本機檔案，遷移前先對照一下你手上的檔案格式落在哪裡。這一輪盤點做得細，順手也把長年累積的資訊孤島清一遍。
第三類是多維表格（Base），通常是搬家工程裡資料密度最高的一塊。客戶名單、訂單、專案這類結構化資料，走 Base 的匯出再匯入最直接：Base 支援 .base、.xlsx、.csv 三種格式，單次匯入上限為 100 欄、20,000 列（筆記錄）、20 MB，並另受方案權益限制（官方匯出入說明，2026-08-13 查核，以官方最新公告為準）。同體系之間用 .base 這個原生格式匯出再匯入，比轉成 .xlsx 或 .csv 更能保留原本的表結構；超過上限就分批或分表處理。單張資料表的列數上限也依方案不同，導入前對著自己的資料量先估，可參考定價頁現值。
第四類是機器人與自動化，最容易在盤點時被漏掉。Base 自動化的觸發條件包含新增記錄、修改記錄、到達記錄中的時間、定時等，動作包含發送訊息、新增或修改記錄等，執行次數依方案有月配額。這些自動化、群組機器人與 webhook 串接，都依附在帳號與 API 上，跨品牌不會自動帶走，需要在 Lark 端重建。飛書端自訂機器人與外部系統的相容性屬於庫外資訊，遷移做法建議與我們確認，別預設它能原封不動搬過去。
官方遷移工具能搬什麼、不能搬什麼
把飛書資料搬進 Lark，可用的官方工具大致分成三層：能自動或半自動搬的、要手動重建的、以及目前沒有公開一鍵工具、得靠人工或顧問協助的。把這三層分清楚，預期就會準，不會卡在「怎麼找不到一鍵搬家按鈕」。
能自動或半自動搬的，主要是結構化與檔案類資料。Base 用 .base、.xlsx、.csv 匯出再匯入是相對完整的一條路，雲端文件可匯入本機檔案，知識庫支援從 Confluence 等格式匯入。另外，Lark 管理後台備有一組通用的資料遷移入口：Google Drive 轉雲端文件、Confluence 轉知識庫、第三方信箱搬家（Gmail、Exchange 走 API，騰訊、阿里、網易、Zoho 等走 IMAP/SMTP）、以及與 Exchange、Google 日曆的同步。要特別講清楚：這些入口對接的是 Google、Confluence 與第三方信箱日曆，並不是「飛書專用」的搬遷工具；如果你的文件與日曆本來就在這些第三方系統上，這條路才用得上。
要手動重建的，是帳號與組織這一層。成員帳號要在 Lark 端重新開通、組織架構與部門要重建、群組與權限要重設，這些沒有辦法靠匯入檔案代勞。介面相近讓重建的學習成本低，但工作量還是實打實地存在，排時程時要算進去。
至於沒有公開一鍵工具、需要人工或顧問協助的，就要老實承認。把整個飛書組織一鍵搬成 Lark 組織的官方公開工具目前並不存在，機器人與自訂應用的跨品牌相容性也沒有現成保證，這些情境建議與我們確認具體做法，而不是假設有個按鈕能全自動完成。
還有一種常被拿來跟遷移混淆的做法要講清楚：飛書與 Lark 之間有官方的跨境關聯組織機制，能讓兩邊在共享範圍內協作，但它需要雙方管理員配置、彼此同意才會開通（見官方的跨品牌關聯說明），預設狀態下兩邊並不互通。關鍵是要分清楚你要的是哪一種：關聯是「兩邊並用、橋接協作」，遷移是「把重心整個搬到 Lark」。重心已經在海外，就走遷移；還要長期跟中國大陸的團隊協作，才需要認真評估關聯並用。
分批切換的節奏：先試點、後全員，雙軌並行
遷移不要一次砍過去，先挑一個部門試跑、把結構定好再擴大，是把切換風險壓到最低的做法。一次全公司搬，等於把所有未爆點同時引爆；分批搬，則是讓問題一批一批浮現、一批一批解決。
試點部門先跑一輪，目的是把可複製的結構定下來：權限怎麼分、群組怎麼開、Base 的欄位與視圖怎麼設，在小範圍先試錯，成本低得多。試點跑順了，這套結構與踩過的雷，就是後面每個部門的樣板。
在資料本身的搬遷順序上，有一層常被忽略：主表先於從表。客戶、專案這種會被別人參照的主表先搬，訂單、任務這種掛在主表底下的從表後搬，跨表的關聯才接得起來，因為要先有客戶記錄，訂單才掛得上所屬客戶。同一時間，別急著把自動化與通知一起開，先讓流程在 Lark 上跑順一輪，等資料校正穩定了再把自動化疊上去，才不會在資料還在搬的時候亂發一堆通知。
切換期保留一段雙軌並行，是每一種遷移都適用的收尾。飛書端先轉為唯讀或封存、不要立刻關掉，讓大家有時間把習慣改過來；需要回頭查舊資料時也還在。如果團隊還得同時跟中國大陸的成員協作，這段期間正好可以評估要不要用官方的跨境關聯機制來橋接兩邊。別追求「一次搬乾淨」，搬得越急、上線越亂。
員工溝通與訓練：介面相近不等於零學習成本
飛書與 Lark 介面相近讓員工上手快，但流程、權限與群組結構要在 Lark 重設一次，溝通與訓練這一關不能省。工具搬得再乾淨，人的習慣沒跟著搬，系統就是空的。
溝通要先講清楚三件事：為什麼要搬、對每個人的日常有什麼影響、時程怎麼走。跨境團隊尤其要把「資料落地與合規」這個動機說明白，讓大家知道這不是為改而改，而是有實際的營運與合規考量。訊息越透明，抵抗越少。
訓練上，讓試點部門的成員當種子是最省力的做法。把登入、找文件、用 Base、跑審批、開會這些每天會碰的操作，先整理成一份繁中的簡短指引，新部門上線時照著走，比每個人自己摸索快得多。介面雖然像，但檔案放哪、群組怎麼開、權限怎麼要，這些習慣還是得重新建立。
最後是最關鍵、也最容易被低估的一點：管理層要帶頭用。依我們協助台灣企業導入的經驗，管理層不帶頭實際使用的案子，多半三個月內就退回原狀。讓主管先在 Lark 上完成一次真實的工作（批一張單、開一次會、在群組裡交辦一件事），團隊才會相信這次是玩真的。這也是台灣代理商導入輔導能幫上忙的地方：把溝通腳本、訓練教材與帶頭節奏一起規劃進去，而不是把一套新工具丟給員工自己想辦法。
切換後驗收：宣布飛書退役前逐項確認
搬完不等於搬對，宣布飛書退役前，用一份清單逐項確認資料、權限、流程與習慣都到位，才不會關掉舊系統之後才發現有東西沒搬。回頭補的成本，往往比當初好好搬還高。退役前把下面幾項逐條打勾：
- 成員與組織：該開通的帳號都開通了，部門結構與權限角色和原本對得上，沒有人被漏在門外。
- 文件到位：要帶走的文件與知識庫頁面都在新家了，該封存的舊資料也標記清楚，沒有停在飛書裡漏搬。
- Base 資料：新舊兩邊抽樣比對筆記錄數與關鍵欄位加總，數字兜得起來；欄位型別正確、跨表關聯已重建、附件已放進附件欄或雲端文件。
- 機器人與自動化：Base 自動化、通知與群組機器人都實際觸發過一輪，確認在新家會動，而不只是設定看起來對。
- 安全與合規：管理後台的安全與合規設定（兩步驗證、SSO、日誌審計、權限審計、資料保留與資料駐留等）已依需求設好，這些通常需要法務、資安、IT 與業務共同決策。
- 習慣切換：團隊已經在 Lark 上完整跑過一次真實流程（開一張單、走一次簽核、結一次案），飛書端同步轉為唯讀。
每一個模組、每一張搬過來的表，最好都指定一位負責人，資料進了新家也要有人養。全部打勾、每項都有人顧之後，再把飛書轉唯讀封存，這趟遷移才算真的落地。想把整段路走得穩一點，也歡迎讓我們陪你走一遍：身為 Lark 台灣授權代理商，艾瑞特資訊可以依你們在中國大陸與海外的人員分布，規劃遷移順序、權限與切換時程，預約導入諮詢就能安排。工具在整體協作架構裡怎麼定位，也可延伸讀企業協作平台選型指南。
常見問題
從飛書搬到 Lark 的評估過程，最常被問到的問題整理如下；品牌關係與資料存放以官方頁面為出處（2026-08-13 查核），Lark 產品行為以我們的知識中心與定價頁現值為準。
Q1：飛書帳號可以直接登入 Lark、把資料帶過去嗎？
飛書帳號無法直接登入 Lark，資料也不會跟著帳號自動搬過去。兩者帳號體系分離、客戶端預設不互通，成員必須在 Lark 端重新開通帳號，文件、表格、通訊錄等資料需要匯出再匯入。若只是想讓飛書與 Lark 兩邊並用協作，則要另外透過官方跨境關聯組織機制、由雙方管理員配置同意開通，那屬於橋接而不是搬家。
Q2：從飛書搬到 Lark 有官方一鍵遷移工具嗎？
從飛書到 Lark 目前沒有把整個組織一鍵搬過去的官方公開工具。可用的官方做法分層來看：多維表格（Base）能以 .base、.xlsx、.csv 匯出再匯入（單次上限 100 欄、20,000 列、20 MB，另受方案權益限制，2026-08-13 查核官方說明，以官方最新公告為準），雲端文件可匯入本機檔案；Lark 端另有對接 Google Drive、Confluence、第三方信箱與日曆的通用搬遷入口，但那些對接的是第三方系統、不是飛書專用。組織通訊錄與機器人多半要在 Lark 端重建，複雜情境建議與我們確認搬遷做法。
Q3：飛書和 Lark 的資料分別存在哪裡？跨境團隊該在意什麼？
飛書依官方隱私說明會把境內運營收集的個人資料存放於中國大陸境內，Lark 的伺服器則位於美國、新加坡與日本。對在中國大陸以外營運、需要向客戶或稽核說明資料不落地中國大陸的跨境團隊，存放地是評估遷移時最該先確認的一項。企業對持有的個人資料負有安全維護責任，跨境資料的落點與合規細節建議一併諮詢法律與資安專業，不要只憑一頁政策就拍板。
Q4：遷移要多久？可以邊用飛書邊搬到 Lark 嗎？
遷移時間取決於資料量與流程複雜度，建議採分批切換、雙軌並行，而不是一次全公司砍過去。實務上先挑一個部門試跑、把結構與權限定好再擴大，飛書端在過渡期先轉為唯讀或封存；若跨境團隊仍需與中國大陸的成員協作，可用官方跨境關聯組織機制橋接兩邊。依我們協助台灣企業導入的經驗，管理層不帶頭實際使用的案子多半三個月內就退回原狀，訓練與帶頭往往比工具本身更關鍵。
Q5：Lark 有繁體中文和發票嗎？和直接向原廠買差在哪？
Lark 內建繁體中文介面，任何管道導入都能切換使用，這一點與採購來源無關。真正的差別在採購與支援：透過台灣官方授權代理導入，可取得正式發票、在地技術支援與導入輔導，這些在跨境直接向原廠採購時通常拿不到，也常是遷移案能不能走公司採購與報帳流程的關鍵。Lark 自家方案與價格請以官方最新公告為準，可先看定價頁了解計價邏輯。