結論

跨 X process content（migration / upgrade / rollout / 演練 / playbook）的結構不是 universal、由 source 跟 target 之間的 差異維度組合 決定。固定套「6-phase playbook」「6-section deep article」會在 結構錯位 的場景失效。

實證：6 種 migration / process type 產出 6 種不同結構：

6 種結構是 常見 type、不是窮盡分類；source / target 配對可能同時屬多 type（多軸 High）、或不屬任一 type（6 維皆 Medium）— 處理規則見「多重歸類跟 tie-breaking」段。本卡前身是「最大差異維度決定結構」+ 5 維 audit、Redis re-sharding dogfood 揭露 data topology 是漏掉的第 6 維、Type F 是對應的第 6 type；本卡擴張為 6 維 audit + 6 type。

為什麼 universal phased 模板會失效

寫第一篇 migration playbook 時自然會想：「6 phase 是 migration 的標準結構吧」 — 套到 drop-in compatible migration 後發現 80% phase 不需要、文章變成「為了 phase 而 phase」；套到 paradigm shift 後發現 phased 假設 線性收斂、實際是 永遠混合架構、phased 模板強迫一個 不存在 的「cleanup phase」。

Universal phased 失效的三個機制：

1. Schema 差不顯著時、phased 多數 phase 變空白：drop-in compatible（如 Redis → DragonflyDB）的「Schema translation phase」內容空、強寫變廢話
2. Operational 差是主軸時、phased 把 operational redesign 壓進「phase 1」變太薄：PostgreSQL → Aurora 的 operational model 重設計 是核心、不該壓在一個 phase
3. Paradigm 差時、phased 假設 source 完全消失：Kafka ↔ NATS 是 永遠共存、phased cleanup phase 假設不存在

→ 結構必須跟差異維度對位、不能反向假設。

Diff dimension audit：寫作前的必要 step

寫 process content 前先做 audit、列出 source 跟 target 在 6 個維度的差異程度：

主導差異維度對映常見 type：

• Schema = High（其他 Low） → Type A phased rule translation
• Operational = High（其他 Low） → Type C operational redesign hybrid
• Paradigm = High → Type E partial + 混合架構
• Components = High（一站式 → multi-tool） → Type D parallel streams
• Topology = High（其他 Low） → Type F topology re-layout（見 #128）
• 全 Low → Type B drop-in、6-section + audit prefix

第 6 維 Data topology 是後續從 Redis cluster re-sharding dogfood 浮現補位、見 #128 Data topology 是 process content 的第 6 audit 維度；本卡原為 5 維 audit、被第二輪 batch evidence 揭露盲點後擴張為 6 維。

多重歸類跟 tie-breaking

實際 source / target 配對 很少 完美對映單一 type；常見情境跟處理規則：

關鍵原則：主導維度決定主結構、其他高維度獨立加段、不強迫單一 type 標籤。Backlog 的「Type A/D 混合」「Type B/D 混合」標示是 維度組合 的簡記、不是承認 5 type 互斥失效；下表多重歸類處理規則才是正式判讀。

6 type 是 axis-aligned simplification、非窮盡

本卡 6 type 來自兩輪 migration playbook 的 dogfood 觀察（第一輪 5 篇 → Type A-E、第二輪 Redis cluster re-sharding → Type F）、是 已浮現的 type、不是 涵蓋所有 migration 的完備分類。已知漏類至少 3 種：

未來累積更多 migration playbook 後、可能浮現第 7-9 type（identity / consistency / residency 候選 — 對應 #128 跟 self-aware limitation update 揭露的候選軸）、或對 6 type 重構。本卡的 type 集合是 open、不是 closed。

6 種結構的 anatomy

**「結構 differentiator」**是本系列引入的概念：每篇 process content 在開頭加一段、明示這篇用什麼結構、跟其他同 category content 的結構差異在哪。功能類似 type signature — 讓讀者一開始就知道接下來的章節組織方式、避免套錯預期。例：drop-in migration 的「結構 differentiator」段會說「跟 phased migration 對照、本篇是 6-section + audit、不是 6-phase」。

Type A：Phased translation（schema 差為主）

1Phase 0 audit → Phase 1 schema 對位 → Phase 2 translation
2→ Phase 3 parallel run → Phase 4 cutover → Phase 5 cleanup

特徵：

• 線性 流程、phase 之間有 dependency
• 每 phase 有獨立 回退邊界
• Schema translation 是工作量主軸（4-12 週）

適用：Splunk → Elastic / Datadog APM → New Relic / MySQL → Postgres

Type B：6-section + audit prefix（drop-in compatible）

1為什麼遷 → 結構 differentiator → 相容性 audit
2→ Step-by-step cutover → 故障演練 → Capacity → 整合

特徵：

• 接近 deep article 6-section
• 多一段 相容性 audit（在 cutover 前列出風險點）
• 不需要 phased、單次 cutover

適用：Redis → DragonflyDB / OpenJDK → Adoptium / MariaDB → MySQL（部分版本）

Type C：Operational redesign hybrid

1為什麼遷 → 結構 differentiator → Operational redesign 對位
2→ 4-phase operational migration（Phase 0 audit + 3 active phase）→ Drop-in cutover → 故障演練 → Capacity → 整合

特徵：

• application code 不變、operational model 全換
• operational 表格對位 是內容主軸
• Cutover 本身簡單（protocol 相容）、operational 準備複雜

適用：PostgreSQL → Aurora / Self-managed Redis → ElastiCache / Self-managed Kafka → MSK

Type D：Parallel streams（multi-tool 拆分）

1為什麼遷 → 五個責任、五個 component → 5 parallel migration stream
2→ Stream-level audit / deploy / dual-ship / cutover → 故障演練 → Capacity → 整合

特徵：

• source 一站式、target N 個專責 component
• 每個 stream 獨立 audit / deploy / cutover、stream 間少 dependency
• 整體不是線性、是 staggered parallel

適用：Datadog → Grafana Stack / Splunk → Elastic + Tines + PagerDuty / Atlassian Suite → 各 specialized tool

Type E：Partial + 混合架構（paradigm shift）

1「不是 migration、是 paradigm 重設計」→ Paradigm 對位
2→ 什麼情境真的能換 → Application 重設計 → 部分 stream cutover → 長期混合架構

特徵：

• 不存在「complete migration」、是 按 use case 拆分 + 共存
• application 模式重設計（不是 SDK 換）
• 混合架構是 long-term default

適用：Kafka ↔ NATS / REST → gRPC / SQL → NoSQL / VM → Serverless

Type F：Topology re-layout（data topology = High）

1為什麼 re-layout → 結構 differentiator（re-layout 不是 migration）
2→ Pre-layout analysis（topology audit）→ Re-layout 機制
3→ Execution flow（per-step + rollback boundary）
4→ 故障演練 → Capacity / cost → 整合

特徵：

• Source / target 多數是 同 cluster 不同 state、不是跨 vendor
• 主軸是 topology audit + 重劃機制、不是 schema translation / paradigm shift
• Pre-layout analysis（識別 hot key / 當前 distribution）是 Type F 的核心 audit 段
• Execution flow per-step、含 rollback boundary

適用：Redis cluster re-sharding / PostgreSQL partition redesign / Kafka topic re-partitioning / Cassandra keyspace re-balance / 加 region / multi-master rollout

詳細 audit dimension 跟 sub-dimension 見 #128 Data topology 是 process content 的第 6 audit 維度。

跟 deep article methodology 的關係

Deep article methodology 的 6-section structure（問題情境 → 概念 → 配置 → 演練 → 容量 → 整合）是 single feature implementation 的模板、不是 cross-vendor process 的模板。Migration playbook 是 新 content category、需要自己的 methodology。

兩者關係：

• Single feature deep article：6-section、200-400 行、focused on how to implement / debug feature X
• Migration playbook：6 種 structure（依 diff dimension）、200-400 行 / 篇、focused on how to move from A to B
• 共同：問題情境 / 故障演練 / 容量 / 整合段；差異：中間「process / structure」段

寫前的 content category 判讀 是新方法論議題、不是 deep article methodology 涵蓋。

反模式

跟其他抽象層原則的關係

判讀徵兆

核心：Process content 的結構由 source / target 差異維度組合 決定、不是 universal phased / 6-section 模板。寫作前必須跑 6 維 diff dimension audit（schema / operational / paradigm / components / application change / data topology）、選對應主結構、其他高維度獨立加段；跳過 audit 會套錯模板、phase 變空白或 process 強行線性。

Self-aware limitation：本卡的 sample-driven over-fit 風險

本卡 5 type 來自 5 篇 migration playbook 的 dogfood 觀察、本身就是 N=5 sample 推導出 5 type taxonomy — 跟本卡批判的「universal phased 模板」「#122 cadence collapse」「#125 reduce 多維到單格」是 同骨錯誤。

本卡是 current best understanding、不是 已驗證的完備理論。Tripwire：

• 若下一輪 migration batch 浮現 無法歸進現有 5 type 的新 structure、應該擴充 type 集合而不是強行歸類
• 若同一 source/target 配對出現 結構翻轉（例 PostgreSQL → CockroachDB 在不同 application context 走不同主結構）、應該檢視 主導維度 規則是否需要動態化
• 若 type 數量擴張到 8+、應該評估是否該重構為 維度 × 維度 grid 而不是 type list

承認 limitation 本身是 dogfood — #122 cadence 同質化 講「natural attractor 不規劃就 collapse」、本卡的 5 type 就是 5 個 sample 的 natural attractor；不在卡內承認、就重複了 #125 隱形預設 的 collapse pattern。本段是 self-correction、不是 disclaimer。

Update（2026-05-19）：第二輪 migration batch 驗證 limitation

第二輪 migration batch（5 篇）跑完、self-aware limitation 三項預測得到驗證：

新發現（不在 self-aware limitation 預測內、需要後續處理）：

• 新 audit 維度浮現：re-sharding 揭露「data topology」是 5 維沒有的軸；audit 擴張為 6 維（加 topology 軸）已執行、見 #128 Data topology 是 process content 的第 6 audit 維度 + 本卡 audit table 新加 row 跟 Type F anatomy
• 「為什麼這篇不套」是漏類文章的好結構模板：major-version-upgrade 跟 cluster-resharding 都用這個 frame 開頭、明示跟 5 type 的邊界
• 「高維度獨立段」對照表自然在 multi-axis 文章浮現（cockroachdb 篇）— 應該升級為 multi-axis migration 的標準結構元素

Update（2026-05-19 第三輪 4-reviewer audit 後）：6 維擴張的未解結構性質疑

第三輪 audit 揭露本卡擴 6 維 + Type F 仍有 6 項未解結構性 issue。完整列表跟 acknowledgment 見 #128 Self-aware limitation 段、本卡這裡 cross-reference：

1. 6 維非窮盡：identity / consistency / residency 三軸候選
2. Type F 跟 Type B 結構重疊度高：實質差異只 2 段、可能下次 evolution 降為 Type B variant
3. 「不需要 parallel run」claim 部分不成立（multi-region rollout 例外）
4. 主導維度優先序是 audience-dependent heuristic、非 universal
5. 「topology 不能塞進既有 5 維」拒絕理由依賴 narrow 既有 5 維定義
6. 既有 5 篇 playbook 沒 retroactive audit（silent grandfathering）

本卡的 6 type / 6 維框架是 current best understanding、不是 final taxonomy；累積到 10+ migration playbook 後可能觸發 retroactive audit + framework restructure。