Tarragon

"Migration"

• 2026-06-26 升級的共通操作框架 任何環境或系統升級的四階段模型：差異評估、平行環境驗證、分批切換、退役舊環境，以及貫穿全程的升級紀律
• 2026-06-26 手動環境的可控底線與納管準備 還沒有 IaC 的環境怎麼守住底線、讓變更可追溯、降低未來納管成本，以及辨識何時該開始導入 IaC
• 2026-05-21 後端 migration、rollout 與 rollback 流程 說明後端 CI/CD 如何把程式、資料 migration、流量切換與 rollback 拆成可驗證的發布流程
• 2026-06-26 平台遷移 FTP 面板主機到 VPS、VPS 到雲端、地端到雲端的遷移路徑 — 資料同步策略、DNS 切換、驗證與回退
• 2026-06-11 10.3 託管形態遷出：資產線盤點與並行期執行 0.21 升級自建 tripwire 觸發後的執行劇本 — 把遷出拆成資料、身分、流量、整合各自的可攜性與斷點、設計舊平台與新系統的並行期與回切窗口、用部分遷出作為中繼形態
• 2026-05-07 營運後技術轉換：語言、工具與架構何時該換 服務營運一段時間後，如何判讀何時該轉語言、工具或架構，並用案例說明轉換動機。
• 2026-06-26 OS 與基礎軟體更換 EOL 作業系統的遷移評估、目標 OS 選型、原地升級 vs 平行建置的取捨、應用層遷移清單，以及 Apache → nginx 等基礎軟體切換的操作要點
• 2026-05-13 1.6 資料庫轉換實作：雙寫、回填、切流與回滾 同 DB 內 schema 演進與資料變更的可分段驗證流程、跟 1.12 cross-DB migration 分工
• 2026-05-11 1.7 Schema Migration Rollout 證據（Schema Migration Rollout Evidence）實作示範 以訂單付款狀態欄位演進示範 schema migration 如何產出 evidence、release gate 與 incident decision log。
• 2026-05-06 Migration 說明資料或結構變更如何在服務不中斷前提下受控推進
• 2026-06-22 DragonflyDB → Redis / Valkey：回退到標準生態的遷移路徑 從 DragonflyDB 遷回 Redis 或 Valkey，處理 snapshotting → RDB/AOF 差異、HA 架構切換與 Cluster mode 重建的階段化流程
• 2026-06-22 KeyDB → Redis / Valkey：從多線程 fork 回歸主線的遷移路徑 從 KeyDB 遷回 Redis 或 Valkey，處理 active-active replication 拆除、多線程 → 單線程效能差異、FLASH storage 移除與 Sentinel/Cluster 對齊
• 2026-06-16 AWS SQS → Google Pub/Sub：queue 模型搬到 topic + subscription 模型的跨雲遷移 SQS 是單一 region-scoped pull queue、Pub/Sub 是 global topic + first-class subscription 的 pub/sub 模型；這篇跨雲 migration playbook 走 6 維 diff dimension audit（components / data topology 軸 High）、對位 visibility timeout → ack deadline、maxReceiveCount → dead-letter topic、long polling → streaming pull、IAM policy → Service Account、SQS-to-many-consumer 要重設計成 topic fan-out；含 5 個 production 故障演練（fan-out 行為差 / ack deadline 太短重投 / ordering key vs FIFO / 跨雲網路成本 / DLT 設定差）跟 dual-publish 漸進 cutover
• 2026-06-16 RabbitMQ → Kafka：從『處理即承諾』到『寫入即承諾 + 可 replay』的 paradigm shift RabbitMQ 跟 Kafka 不是同類產品（work queue vs event streaming log）、把 work queue 直接搬成 topic 會踩 paradigm 落差；本文先跑 6 維 diff dimension audit（paradigm 跟 data topology 差最大）、釐清什麼 workload 真該遷什麼不該、再展開 application 重設計的 5 個踩雷（manual ack 觀念帶到 offset commit / routing key → partition key 的 ordering 邊界 / DLX → 自建 DLQ topic / prefetch → max.poll.records / 即刪 vs retention 的 replay 差異）、以及 dual-write / shadow consume 漸進 cutover 與長期混合架構
• 2026-06-16 Redis → Valkey：同一份程式碼、不同授權的 drop-in 遷移 Valkey 是 Redis 7.2.4 的 fork，bit-for-bit 幾乎同源、RDB/AOF 檔案相容、client 一行不改——這是技術上最容易的 cache 遷移。真正的工作不在搬資料，在授權合規驗證與 fork 後分歧（Redis 7.4+ 功能、Stack 商業 module）的盤點。本文走 Type B drop-in、相容性 audit 前置、5 個把『最容易的遷移』寫成事故的踩坑
• 2026-06-16 Redis Streams → Kafka：從 embedded stream 長成 dedicated event streaming Redis Streams 是 Redis 生態內的 append-only log data structure、Kafka 是專用 distributed event streaming platform；這趟遷移是 paradigm shift — 從 RAM-bound 單 stream key 換成 partition + log retention 的多節點系統。本文先用 Arcjet 反向案例點明多數中小規模 Redis Streams 就夠、不該為流行遷 Kafka、再講真的該遷的訊號（retention 超出 RAM 成本 / 長期 replay / consumer group 規模超出單 Redis）、XADD/XREADGROUP/XACK/MAXLEN/XCLAIM 的對位、retention 成本翻轉與 PEL→offset 誤用的故障演練、漸進 cutover
• 2026-06-16 從 Firestore 遷往自建 relational：撞牆驅動的 Type E 重建模、存取模型反轉與並行期 Firestore → 自建後端 + relational 不是匯資料而是反轉存取模型：client 直連變 API 中介、Security Rules 授權變後端授權、document 反正規化變正規 schema、realtime listener 與 offline 同步要重建；本文走 Type E paradigm shift 結構、展開為何字面遷移不成立、哪些該遷哪些先留、dual-write + shadow read 階段化與遷出代價判讀
• 2026-05-19 Docker Swarm → Kubernetes：5 個 Swarm production cluster 撞牆數據 Docker Swarm → Kubernetes 是 Type E paradigm shift — Swarm「simpler container orchestration」設計上限在 100-200 service 規模、跨 application 服務治理時 paradigm 不足；本文用 5 個 production cluster 量化數據開頭、5 個 production 踩雷
• 2026-05-19 DynamoDB Strongly Consistent → Eventually Consistent：same protocol, different contract DynamoDB consistency model 從 strongly consistent read 改 eventually consistent read 是 50% cost 優化但風險集中在 application contract — 同 vendor / 同 protocol / 同 table / 不同 read consistency；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 consistency axis 候選；涵蓋 read pattern audit / 5 個 production 踩雷
• 2026-05-19 Kafka ↔ NATS：不是 migration、是 messaging paradigm 重設計 Kafka 跟 NATS 不是同類產品（log-based event streaming vs subject-based messaging）、'migration' 字面上不成立；本文釐清兩家 paradigm 邊界、什麼情境真的能換、application 模式重設計的 5 個踩雷（consumer offset 觀念差 / retention model / exactly-once 假設 / schema registry 缺位 / fan-out 模式差）、跟 JetStream 對位 + 混合架構
• 2026-05-19 MongoDB → Atlas：Atlas 不是 MongoDB + managed、是另一個 product Atlas 號稱「MongoDB managed」但 operational model 完全不同（auto-scaling / VPC peering / IAM-driven access / 內建 backup / billing 模型）；本文採用 Type C operational redesign hybrid 結構、4-phase operational migration + drop-in cutover、5 個 production 踩雷（連線數限制 / IP whitelist / backup retention / IAM token 過期 / billing 暴漲）
• 2026-05-19 MySQL → PostgreSQL：從 SQL dialect diff 跑出來的 Type A 6-phase migration MySQL → PostgreSQL 是 Type A 高 schema 差 migration 的標準形態 — SQL dialect / collation / case sensitivity / replication 模型差異主導；用 pgloader / AWS DMS / 自管 dual-write 三條 path、5 個 production 踩雷（auto_increment vs SERIAL / charset 跟 collation / case sensitivity / index syntax / triggers）
• 2026-05-19 New Relic → Datadog：APM schema 對位 + agent 替換 + dashboard 重建 New Relic → Datadog 是 Type A schema diff migration — APM schema / NRQL ↔ Datadog query / agent / dashboard 全要對位；本文涵蓋 6-phase phased translation + 5 個 production 踩雷（NRQL 不直接對位 / synthetic alert 重建 / 計費模型反轉 / dashboard 自動轉失敗 / cross-platform metric 命名）
• 2026-05-19 Self-managed Prometheus → Grafana Cloud Metrics：feature × ops × cost 對照 Self-managed Prometheus → Grafana Cloud Metrics (Mimir-backed) 是 Type C operational redesign — Prometheus query API 完全相容、operational stack (HA / retention / scaling) 全託管；本文用 feature / ops / cost 三維對照表開頭、5 個 production 踩雷
• 2026-05-19 Sentry → Honeycomb：trace 不是 error、是不同 observability paradigm Sentry → Honeycomb 是 paradigm shift — Sentry 主軸是 error tracking + transaction trace、Honeycomb 主軸是 high-cardinality wide-event observability；本文釐清 paradigm 邊界、5 個 production 踩雷（event schema 對位 / sampling 行為 / error grouping 失效 / cost 模型差 / alert paradigm shift）
• 2026-05-19 Terraform → OpenTofu：HCL 跟 state file 級 drop-in、CI runner 切 binary 完成 OpenTofu 是 Terraform 在 BSL license 後的 fork、Terraform 1.5.x baseline 完全相容（HCL / state / provider）；本文是 Type B drop-in migration 的標準形態 — 用 code-led HCL / state diff sample 開頭、5 個 production 踩雷（provider version drift / state lock 微差 / Terraform Cloud feature 不支援 / CI binary name 假設 / registry routing）
• 2026-05-18 Splunk → Elastic Security Detection Rule Migration：6 段 phased playbook 跟 5 大踩雷 從 Splunk Enterprise Security 遷到 Elastic Security 的 detection rule translation playbook：SPL ↔ KQL/ES|QL schema 對位、AI-assisted translation pipeline、parallel run 比對、cutover routing、5 個 production 踩雷（macro 沒對應 / time zone 差異 / summary index 不對位 / alert dedup key 衝突 / 過早 decommission）、capacity / cost 對照
• 2026-06-22 ElastiCache → 自管 Redis / Valkey：脫離 managed 的遷移路徑 從 AWS ElastiCache 遷移到自管 Redis 或 Valkey，處理 RDB export、DNS 切換、IAM 認證移除與監控重建的階段化流程
• 2026-06-22 Kafka → Google Cloud Pub/Sub：從 partition 到 topic-subscription 的模型轉換 從 Apache Kafka 遷移到 Google Cloud Pub/Sub，處理 partition → topic 模型轉換、ordering 語意差異、consumer group → subscription 對應、offset → ack deadline 切換的階段化流程
• 2026-06-16 RabbitMQ → AWS SQS：交出 broker 維運、把 routing 收斂進 application 自管 RabbitMQ 叢集遷到 AWS SQS 是 operational redesign：protocol 不相容、application 要從 manual ack 改成 visibility timeout + delete、exchange routing 收斂成 SNS fan-out 或多 queue；本文跑 6 維 diff dimension audit（operational 差最大）、釐清什麼該遷什麼不該遷、5 個 production 故障演練（DLX → redrive policy / prefetch → batch + visibility / fan-out → SNS-to-SQS / 256KB 大小限制 / ordering 到 FIFO 的吞吐取捨）跟漸進 cutover
• 2026-05-19 Datadog → Grafana Stack：把 $50K/month bill 拆解到 self-hosted observability Datadog 五層計費（host APM / metric / log ingest / log retention / RUM）拆解、對位 Grafana Stack（Mimir / Loki / Tempo / Grafana / Alloy）的 5 層責任；OTel-based agent migration、5 個 production 踩雷（cardinality 爆 / log volume cost / dashboard 不直接轉 / alert routing 換邏輯 / SLO definition 差異）、cost reality check
• 2026-05-19 etcd → Consul：KV + N 個 extras feature matrix etcd → Consul 是 Type E paradigm shift expansion — 從 pure KV store 升到 service mesh / discovery / health check / multi-DC；本文用對照表 + paradigm expansion 路線、5 個 production 踩雷（API 對位 / lock semantics / watch event model / multi-DC topology / ACL system）
• 2026-05-19 Jenkins → GitHub Actions：Pipeline 5 段 lifecycle 的對位 + 翻譯 Jenkins → GHA 是 Type A 高 schema 差 migration、主軸是 Groovy DSL → YAML workflow 翻譯；本文按 pipeline 5 段 lifecycle（source → build → test → scan → deploy）逐段對位、5 個 production 踩雷（shared library equivalence / ephemeral workspace / plugin gap / self-hosted runner / matrix build 表達差）
• 2026-05-19 Redis → DragonflyDB：drop-in 相容下的容量躍升 + 5 個踩雷 DragonflyDB 號稱 Redis drop-in 替代、單機 throughput 25x、記憶體效率 30% 提升；遷移流程簡單但有 5 個 production 踩雷（RDB 版本差 / Lua 腳本不全支援 / Pub-Sub fanout 行為差異 / Cluster mode 兼容度 / Modules 不支援）、跟 Sentinel / Cluster 模式對位
• 2026-05-19 Self-managed ELK → Elastic Cloud：5 年 ELK 集群的 lifecycle 收尾 Self-managed ELK Stack → Elastic Cloud 是 Type C operational redesign — protocol drop-in、operational stack（cluster sizing / shard 治理 / upgrade / backup）全託管；本文按 5 年 ELK lifecycle (build → scale → degrade → save → migrate) 組織、5 個 production 踩雷
• 2026-05-19 Self-managed Kafka → AWS MSK：把 $15K/month operational cost 拆解到 managed Kafka self-managed → MSK 是 Type C operational redesign — protocol 完全相容、operational stack（ZooKeeper / brokers / monitoring / patching）全託管；本文用 cost 拆解開頭、5 個 production 踩雷（client connection pattern / version pinning / metric pipeline / IAM auth / cross-cluster mirror）
• 2026-05-19 Vault → AWS Secrets Manager：「secret」不是「secret」、identity model 才是核心差異 Vault → AWS Secrets Manager migration 表面是 secret store 替換、實際核心是 identity model 對位（Vault token + policy vs AWS IAM + resource policy）；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 identity axis 候選 — identity 是否獨立 audit 軸；5 個 production 踩雷（IAM principal 對位 / dynamic credential 對等失敗 / lease lifecycle 模型不同 / audit log 結構差 / 計費模型反轉）
• 2026-05-13 1.12 大規模 DB 遷移實戰 跨 DB 遷移的 dual-write、[shadow read](/backend/knowledge-cards/shadow-read/)、cutover、rollback 流程 — 從實戰案例提煉的工程做法
• 2026-05-19 Redis → Memcached：Memcached 不是 simpler Redis、是 cache paradigm Redis → Memcached 是 Type E paradigm reduction migration — 從 multi-paradigm（KV + 資料結構 + pub/sub + Lua + streams）退到 pure cache；不是「remove Redis features」、是「重新分配 Redis-specific feature 到對應 specialized 服務」；5 個 production 踩雷 + paradigm reduction 路線
• 2026-06-16 Memcached → Redis：不搬資料、搬存取層的能力升級遷移 Memcached → Redis 跟一般 migration 最大的不同：cache 是可重建的，所以這個遷移不搬資料、讓新 cache 重新 warm 就好，真正的工作在存取層（client、協定）跟可選的能力升級（data types）。本文跑 6 維 diff audit、用兩階段（drop-in pure KV → 採用 data types）結構、5 個把『outgrew pure KV』寫成事故的踩坑
• 2026-06-16 自管 Redis / Valkey → AWS ElastiCache：engine 不變、變的是誰運維 自管 Redis/Valkey 遷到 ElastiCache 的特殊之處：engine 沒變（Redis 還是 Redis）、data model 沒變、API 沒變——變的只有運維責任歸屬。本文跑 6 維 diff audit 對映 Type C operational hybrid、展開 VPC/安全/cutover 的實際工作、以及『把 failover/patching 交出去、同時交出哪些控制權』的責任邊界，5 個 production 踩坑
• 2026-05-19 MySQL 5.7 → 8.0 Major Version Upgrade：character set / authentication / atomic DDL 三條 paradigm 同時換軌 MySQL 5.7 → 8.0 三條 default 同時改：charset utf8 → utf8mb4、auth plugin native_password → caching_sha2_password、DDL non-atomic → atomic。本文走 Type E paradigm shift 結構、6 維 audit、4-phase upgrade、5 production 踩雷、何時不要升級。
• 2026-05-19 MySQL → Aurora MySQL：storage layer 轉手到 AWS、replication / HA / backup 全部 outsource 自管 MySQL → Aurora MySQL 是 Type C operational hybrid migration — wire protocol 一致、ops 責任轉到 AWS。本文走 6 維 audit（Operational High）、Aurora storage architecture 衝擊、4-phase migration、5 production 踩雷、何時維持原路線。
• 2026-05-19 MySQL → PlanetScale：managed Vitess + branch-based schema workflow 的 hybrid shift 自管 MySQL → PlanetScale 加上 Vitess sharding 跟 branch-based schema workflow。本文走 6 維 audit（Paradigm + Operational + Schema 多軸）、4-phase migration、5 production 踩雷、何時不要遷。
• 2026-05-19 自管 Vitess → PlanetScale：Vitess component ops outsource、加 schema workflow shift 自管 Vitess → PlanetScale 是 Type C operational hybrid — Vitess component（VTGate / VTTablet / VReplication / VSchema）ops outsource + branch workflow。本文走 6 維 audit、4-phase migration、5 production 踩雷、何時不要遷。
• 2026-05-27 Cosmos DB MongoDB API vs SQL API：遷移路徑、dogfood signal、multi-model、跨雲 hedging 從『MongoDB API 跟 SQL API 哪個快』推進到 vendor selection 的四層問題：三型遷移路徑、dogfood signal 怎麼讀、multi-model 差異化、跨雲 hedging — 從 Microsoft 365 dogfood 案例切入
• 2026-05-27 Migration Playbook：Cloud SQL for PostgreSQL → Cloud Spanner Cloud SQL → Spanner 是 paradigm shift 級遷移、不是 drop-in。本 playbook 走 6 規格面 Driver / Diff / Phase / Evidence / Cutover / Cleanup：Driver 段明示 sizing barrier（100 pu 起跳）跟 < 50ms write latency 兩條 no-go；Diff 段加 sizing / cost 第 7 規格面；Phase 0 含 sizing audit；Evidence 段補 cost crossover 報告；對照 9.C10 Google internal dogfood 邊界跟 Standard Chartered 受監管 banking case
• 2026-06-02 從 RDS / MongoDB 遷移到 DynamoDB：access-pattern-first 重建模、混合架構與 cost crossover RDS / MongoDB → DynamoDB 不是搬 schema 而是換 paradigm；本文走 Type E paradigm shift 結構，展開為何字面遷移不成立、access pattern 重建模、哪些 workload 該遷哪些該留的混合架構、dual-write + shadow read 階段化，以及 Zomato cost crossover 的長期成本判讀
• 2026-05-19 PostgreSQL → Aurora Migration：protocol 相容、operational 重設計 Aurora 號稱 PostgreSQL-compatible 但 operational model 不同（storage decouple / cluster endpoint / instance class / 自家備份）；遷移流程是混合（protocol drop-in + operational phased）、5 個 production 踩雷（extension 不支援 / replication slot 不直通 / autovacuum 行為差 / IAM 認證強制 / cost model 換算）、跟 Patroni / read replica / DR 對位
• 2026-05-19 PostgreSQL → Aurora DSQL Migration：PG wire-compatible Distributed SQL 的 Paradigm Shift Aurora DSQL（2024-12 re:Invent preview / 2025-05 GA）是 AWS 推的 PG wire-compatible *active-active distributed SQL*、跟 self-managed PG / Aurora PG 不同 paradigm（OCC + snapshot isolation + multi-region strong consistency）。Migration 結構是 *protocol drop-in + paradigm shift*：app SQL 不太改、但 transaction retry / extension 缺位 / 多 region 一致性需重設計。本文走 DSQL vs Aurora PG vs self-managed PG 三軸對比、為什麼遷的三條 driver（global write / operational zero-touch / region resiliency）、Type E phased plan、5 production 踩雷（transaction retry 沒處理 / extension 缺位 / sequence throughput 限制 / Aurora PG 直升 DSQL 不可行 / region failover semantic）、跟 PG → Aurora 跟 PG → CockroachDB 對比
• 2026-05-19 PostgreSQL → CockroachDB：三維皆 High 的多重歸類 migration PostgreSQL → CockroachDB 是 Schema / Operational / Paradigm 三維皆 High 的 multi-axis migration、實證 [#127](/report/content-structure-by-max-diff-dimension/) 的「多重歸類跟 tie-breaking」規則；主結構走 Type E paradigm shift、Schema 差 + Operational redesign 抽出獨立段；涵蓋 transaction model 重設計、SQL dialect gap、5 個 production 踩雷
• 2026-06-26 Database Migration 用版本化的 SQL 腳本管理資料庫 schema 的變更歷程，讓 schema 變更可追蹤、可重現、可回退
• 2026-05-19 PostgreSQL Multi-Region GDPR Rollout：政策驅動的 migration 屬本 methodology 嗎 PostgreSQL 單 region → multi-region 同時滿足 GDPR EU residency 是 *政策驅動* 兼 *topology 變動* 兼 *operational redesign* 的多軸 migration；驗證 [#128](/report/data-topology-as-audit-dimension/) self-aware limitation 提出的 residency axis 候選 — residency 是 driver 還是獨立 audit 軸；涵蓋 logical replication 配 GDPR / 5 個 production 踩雷 / cross-region cost
• 2026-05-27 從自管 PostgreSQL / MySQL 遷到 Aurora：operational redesign migration playbook PostgreSQL / MySQL → Aurora 的 Type C operational redesign hybrid playbook、6 規格面（Driver / Diff audit / Phase plan / Evidence / Cutover / Cleanup）、Standard Chartered 合規 lead time 模型、Netflix 非 all-purpose store 邊界
• 2026-06-02 從 MongoDB / Cassandra 遷入 Cosmos DB：protocol-compat API drop-in vs native API paradigm shift、相容性邊界與 dual-write cutover MongoDB / Cassandra 遷入 Azure Cosmos DB 的 migration playbook：用 Cosmos 的 MongoDB API / Cassandra API 做 wire-protocol drop-in（Type B）vs 換 native SQL API 的 paradigm shift（Type E）兩條路徑的取捨、6 維 diff audit、相容性邊界、dual-write 與 cutover — 從 Microsoft 365 / Forbes 遷移對照切入
• 2026-05-11 Validation Query 說明遷移、回填與修復期間如何用查詢證明資料語意是否一致
• 2026-05-11 Read Compatibility 說明資料或服務演進期間讀取路徑如何同時支援新舊語意
• 2026-05-11 Fallback Read 說明讀取路徑切換失敗時如何暫時回到舊資料語意或舊讀取來源
• 2026-05-11 Cutover Window 說明正式切換發生的觀察窗口、停止條件與回退判讀範圍
• 2026-05-11 Mapping Table 說明遷移或轉換期間如何把舊語意明確對應到新語意
• 2026-05-11 Rollback Window 說明變更進入 production 後還能用哪種方式回退或改路線的時間與條件
• 2026-05-22 PostgreSQL Schema Migration Evidence Lab PostgreSQL expand / contract migration、validation query、rollback condition 與 release gate evidence 的操作說明
• 2026-05-22 PostgreSQL to YugabyteDB / TiDB Migration PostgreSQL 轉向 YugabyteDB、TiDB 類 distributed SQL 的 compatibility audit、data topology、transaction、cutover 與 rollback
• 2026-05-21 PostgreSQL to SQLite Simplification PostgreSQL 降低操作成本轉向 SQLite 的適用條件、資料責任縮小、export/import、runbook 與 no-go condition
• 2026-05-21 SQLite Migration Fixture Lab SQLite user_version、table rebuild migration、fixture snapshot、rollback note 與 CI evidence 的操作說明
• 2026-05-21 SQLite Schema Migration and Versioning SQLite schema migration、user_version、table rebuild、ALTER TABLE 限制、app release compatibility 與 migration evidence
• 2026-05-21 SQLite to D1 / Turso Migration SQLite 轉向 Cloudflare D1、Turso / libSQL 的 edge driver、compatibility audit、data movement 與 rollback
• 2026-05-21 SQLite to PostgreSQL Migration SQLite 升級到 PostgreSQL 的 driver、schema diff、data copy、dual run、cutover、rollback 與 cleanup
• 2026-05-19 Atlassian Statuspage → Instatus：status page 成本下降、但 compatibility audit 不能跳 Atlassian Statuspage → Instatus 是 Type B drop-in migration、6 維 audit 全 Low；典型情境是從 Statuspage Business / Enterprise 降到 Instatus Pro / Business、但 savings 取決於 subscriber、SSO、audit 與 SLA report 需求。本文走 compatibility audit prefix（subscriber channel 完整度 / SAML SSO / audit log / metrics integration / SLA report / API parity）、4 階段 cutover（DNS TTL + parallel run）、5 個 production 踩雷（SSO tier 選錯、metrics 來源整合斷、subscriber import format / SLA report 缺、custom CSS 不完全相容）、何時不要切（enterprise compliance / 強 Atlassian 整合）
• 2026-05-19 JMeter → k6：k6 不是 JMeter 的「script 版本」、是 VU model 取代 thread model JMeter → k6 是 Type E paradigm shift、不是把 .jmx XML 翻成 JavaScript — VU (virtual user) model 跟 thread group model 是兩種對「使用者行為」不同的建模方式。本文走 6 維 audit（Schema High / Paradigm High / Operational Medium）、釐清反向定義、4-phase partial migration（多數 org 停 Phase 2-3 hybrid）、5 production 踩雷（thread group 翻譯失真 / arrival rate vs concurrent VU 混淆 / protocol gap / 結果 schema 改 / CI integration 重做）、protocol gap（JDBC / JMS / LDAP 在 k6 沒原生對應）、何時不要切
• 2026-05-19 PagerDuty → incident.io：「On-call」是個 retconned word、同名不同 contract PagerDuty → incident.io 不是 schema translation — 兩家的「on-call」字面相同、contract 不同（alert routing vs IR coordination + Slack-native + retrospective）。本文走 Type E paradigm shift、6 維 audit 顯示 paradigm / schema / operational 三軸 High、用 4-phase partial migration（不收斂、Phase 1-2 多數 org 停留）、5 個 production 踩雷（雙系統 state drift / severity 翻譯失真 / schedule layer 漏 / Slack channel 過載 / retrospective 斷層）、跟 PagerDuty Process Automation / AIOps 沒對應的 capability gap
• 2026-05-19 PagerDuty → Opsgenie：Atlassian 全家桶整合 vs Opsgenie 2027 EOL 的 vendor consolidation 取捨 PagerDuty → Opsgenie 是 Type A phased schema translation、但 Atlassian 已宣布 Opsgenie 2027-04 EOL — 這條 migration 只在 Atlassian-heavy org + 明確 JSM unification roadmap 下成立、本質是 PD → Opsgenie → JSM Cloud 的雙 hop migration。本文走 6 維 audit（Schema Medium-High 其他 Low）、PagerDuty ↔ Opsgenie ↔ JSM field mapping 對照、5 production 踩雷（escalation step / Heartbeat 缺對應 / integration key dedup 重設 / schedule 時區 / Atlassian Identity SSO 整合）、何時直接走 PD → JSM 跳過 Opsgenie
• 2026-05-19 Pyroscope → Datadog Continuous Profiler：profiling deployment lifecycle 各階段 operational ownership 轉手 Pyroscope → Datadog Continuous Profiler 是 Type C operational hybrid migration — pprof data model 接近、profile lifecycle 五階段（install / instrument / ingest / query / cost）的 ops ownership 從 self-host 轉到 SaaS。本文走 6 維 audit（Operational High 其他 Low）、4-phase migration（operational audit + agent parallel + tag reconcile + cutover）、5 production 踩雷（agent 重複 overhead / tag schema 不一致 / trace_id correlation 斷 / cost 突增 / retention 政策變動）、何時保留 Pyroscope（資料主權 / 內網 / OSS-first / cost sensitive）