粉絲抵達新空間，拿到的是錯的身分組。付費會員進不去。已經離開的人反而還進得來。管理員則失去了每一個舊決定背後的來龍去脈。解法不是寫一篇更好的公告，而是把身分、權限、對話和管理當成四件各自獨立、各自要拿出證據的工作。
創作者社群搬家會失敗，通常是因為公告跑在底層系統前面。粉絲抵達新空間卻拿到錯的身分組、付費會員進不去、已經離開的人還留著權限，而管理員失去了幾個月前那些決定背後的脈絡。這裡每一項都是系統問題，只是穿著溝通問題的外衣。
所以解法不是寫一篇更好的公告。解法是一次分階段的搬遷，把身分、權限、對話和管理當成四項各自獨立的職責，每一項都有自己的驗收證據。接下來是一份具體的切換計畫：盤點舊的系統組合、在取得同意的前提下連結身分、核對付費權限、保留你真正承諾過的歷史、讓兩套系統短暫並行、事先決定好回退規則，並且在關掉舊空間之前先證明新社群真的能運作。
在粉絲眼中，社群看起來是一個地方，但它通常是好幾套鬆散接在一起的系統。Discord 裝著討論和身分組，Patreon 決定誰付了錢，創作者網站放著政策和可搜尋的內容，Stripe 送出付款事件，而某個地方的一張試算表，裝著沒有記錄在任何其他地方的人工例外。動任何東西之前，先寫下每一項職責由哪個系統說了算。
這張表能擋掉整件事裡最常見的錯誤：把平台匯出檔當成一份完整的社群備份。匯出檔可能有貼文，但沒有當下的付款狀態；可能有帳號識別碼，但沒有重複使用聯絡資料的許可；也可能有一堆身分組，而它們的意義在這幾年裡早就悄悄變了。
Discord 的 OAuth2 文件在這裡值得一讀，因為它把身分授權和應用程式權限分開來談。使用者連結一個 Discord 帳號，跟創作者把一個使用者名稱抄進新系統，是完全不同的兩件事，而你的搬遷流程應該保留這個區別，不要把它抹平。
不要承諾「什麼都會搬過去」。決定成員在切換之後真正需要什麼，以及舊平台實際上允許你匯出或保留什麼，然後把每一類東西歸進上面四份清單之一。
受限的紀錄絕對不要混進任何大範圍的內容匯入。管理員可能需要知道某個帳號目前被限制中；一般成員不需要知道背後的案件經過。只搬執行那個決定所需要的最小紀錄，把它放在受限權限後面，並且給它一個保存期限。
這也是公開講清楚「哪些不會搬」的時機，而且要在搬之前講。私訊匯不出來，就說出來。舊的表情回應不會跟著過去，就說出來。封存只會留九十天而不是永遠，現在就把這條界線公布出來，而不是等到第九十一天跟成員一起發現。
名字不是穩定的識別碼。粉絲可以改掉 Discord 帳號名稱、在 Patreon 用另一個電子郵件，也可能跟一個完全不認識的人撞了顯示名稱。永遠不要只用顯示名稱去對資料：這是最容易把某位成員的付費權限，接到另一位成員帳號上的一個決定。
Discord 在 OAuth2 指南裡記載了它的授權流程和權限範圍，Patreon 也在 API 文件裡說明了創作者和成員的授權方式。只要提供者有這些機制就用它，不要叫粉絲傳截圖、密碼或身分證件過來。
給管理員一條人工修復的路，但要留窄。管理員可以重寄一次連結、透過金流系統查一張收據，或把某個帳號排進待審。管理員不該因為某個顯示名稱看起來很眼熟，就永久發一個付費身分組出去。每一次人工介入都要有負責人、理由、到期日和審查狀態。
付款事件不是「當下真相」的完整來源。Webhook 可能晚到、可能重複送達，也可能以跟實際變更順序不同的順序抵達。Stripe 明白告訴串接者要處理重複事件，而且不保證事件順序。所以只要提供者有「讀取當下訂閱狀態」的介面就用它，並且把 Webhook 當成「該去刷新狀態了」的提示，而不是必須照做的命令。
替每一位完成連結的成員，導出一筆權限紀錄，帶著：成員 ID、訂閱來源和來源訂閱 ID、狀態、付費到期日、權限等級、最後一次檢查的時間，以及人工例外的到期時間。這八個欄位，足以回答切換過程會問你的每一個問題。
上線前把對帳跑兩次。第一次會暴露對應錯誤；第二次刻意隔一段時間再跑，看事件和當下讀取的狀態會不會收斂到一起。而且要按方案分別比對人數，不要只看總數：一個漂亮的總數，可以輕鬆藏住二十位不見的進階會員，和二十位早該離開的舊會員。
先蓋出最小但完整的目的地。成員需要的是一條迎新路徑、規則、一條支援路徑、必要的討論房間，以及正確的權限。他們第一天並不需要每一個實驗性的頻道。
然後請每一位測試者，用粉絲會走的同一條路徑登入。從後台檢查是不夠的：一個身分組可以在資料庫裡看起來完全正確，而成員仍然看不到那個它應該打開的房間。
多主持人的節目要指定一位搬遷溝通的負責人，再加一位備援。個別主持人可以在公開場合回答問題，但政策變更和期限公告應該只有一個出口。否則同一個節目會發出三種關於封存、退款和舊空間何時關閉的承諾，而這三種都會被原話引用回來給你聽。
不要無限期地同時經營兩個完整的社群。短暫的雙軌期給成員時間搬過去，也給你證據證明新系統可行。無限期的雙軌期則會切開討論、讓管理工作重複一遍，而且兩邊都不算數，那比只有其中任何一邊還糟。
開放期間，在舊空間每一個還活著的入口，放上同一則簡短的搬遷通知，全部連到同一份指南。那份指南要說明：什麼會搬、什麼不會搬、期限、支援路徑，以及粉絲發現自己權限不對時該怎麼辦。
另外，不要讓成員為了求助而公開發文。權限出錯這件事會揭露一個人的訂閱狀態，也會招來假冒。用一張表單或支援信箱，收下已連結的帳號、應有的方案、實際看到的權限，以及願意讓你查看的同意。
回退不是失敗，它是一道安全控制。在舊系統還能運作的時候，定義出哪些條件會暫停或反轉這次搬遷，而且要在切換之前定義，不是在切換的正中間才想。
一份回退計畫要指名：誰做這個決定、權限的變更怎麼還原、成員會收到什麼訊息，以及這段期間哪一邊的紀錄說了算。在試營運通過之前，舊空間要保持可以發言。公開搬遷開放之後，寧可暫停，也不要把對話反覆搬來搬去：每搬一次，你付出的信任成本都比你要修的那個問題還高。
一篇成功的公告，不等於一次成功的搬遷。要去驗證底下那些真正的工作，而且要人工抽樣：從每一種方案和每一種生命週期狀態各挑幾位成員，比對訂閱來源、目的地的身分組，以及他實際看得到的權限。每次改規則就重跑一次對帳，並且把結果和核准的人一起記下來。
關閉之前，請管理員完成最後一次實戰演練：收到一則測試通報、限制一個測試帳號、找出對應的規則、聯絡溝通負責人，然後把那個帳號復原。這證明的是新的目的地撐得起社群的營運，而不只是撐得起登入和聊天，而這正是「一個大家能講話的地方」和「一個你管得動的地方」之間的差別。
在公告新平台之前，先把那張職責表做出來。指名身分、付費權限、討論、歷史、管理和支援各自由誰說了算，並且在每一項旁邊寫下驗收的證據。
接著把每一種生命週期狀態的帳號都測一遍，並且趁還沒有人有壓力的時候，訂出可以量測的回退觸發條件。等這些檢查都通過了，再邀請整個社群搬過來。搬得不順的那些案例，幾乎從來不是搬得慢的那些。