Majisemi 舉辦網路研討會：探討「為何 MySQL 8.0 EOL 遷移決策停滯不前」

## MySQL 8.0 EOL 對應：DBaaS 環境中的影響與風險

MySQL 8.0 的終止服務（EOL）即將於 2026 年 4 月到期。許多企業深知其必要性，卻因無法判斷從何處著手或如何設定優先順序而停滯不前。
特別是對於在生產環境中使用 Amazon RDS、Aurora 或 Cloud SQL 等 DBaaS 的企業而言，考量因素瞬間增加，例如因延伸支援（Extended Support）導致的成本上升、相容性、效能影響與停機風險，使得決策變得極為困難。這常導致許多企業陷入「僅進行調查卻無法做出決定」，或是因為焦慮而不斷推遲的情況。

## 為何 EOL 遷移變得困難

EOL 遷移不僅僅是版本升級，更需要連續進行多項決策，包括：
- 判斷影響範圍
- 風險梳理
- 釐清討論焦點
- 分配企業內部與供應商的職責

然而，許多團隊在未釐清上述重點的情況下貿然開始作業，最終導致意料之外的トラブル（問題）與成本增加。

## 依據 DBaaS 提供商整理對應方針的必要性

在規劃 EOL 遷移時，針對不同的 DBaaS（如 RDS、Aurora、Cloud SQL），考量重點各異。例如：
- Amazon RDS for MySQL：升級路徑與相容性風險
- Amazon Aurora MySQL：對獨家功能的依賴性與效能特性
- Google Cloud SQL：遷移選項與營運設計的差異

若未理解上述差異就盲目進行，可能導致停機、效能劣化以及工時超出預期，進而直接影響業務。

## 本研討會內容

本研討會聚焦於 DBaaS 環境（RDS/Aurora/Cloud SQL）下的 MySQL 8.0 EOL 遷移，將成功的升級策略整理為「決策軸」。目的不僅是程序說明，而是讓企業能夠自主判斷需要考量什麼、哪裡需要謹慎，以及如何整理作業流程。

主要學習內容包括：
- EOL 遷移所需掌握的影響範圍與風險概覽
- MySQL 8.0 EOL 會發生什麼（包含 DBaaS 特有觀點）
- RDS / Aurora / Cloud SQL 各自的對應方針與注意事項
- 基於服務特性的升級路徑構思
- 推動決策流程的視角
- 包含驗證與測試的實務操作方法
- 升級前後常見的錯誤與處理對策
- 常見的失敗模式與規避方法

## 推薦參與對象

- 在生產環境中使用 Amazon RDS / Aurora / Cloud SQL 的企業人員
- 使用 MySQL 8.0 但尚未著手規劃 EOL 遷移的企業
- 負責技術決策的資訊系統部門主管、開發負責人或 IT 負責人
- 需要憑自身判斷來解釋升級影響、風險與成本的人員
- 不希望完全依賴供應商，想要自主掌控決策過程的人員

## 主辦單位
- 主辦：株式會社 Pasona Data & Design
- 協力：Majisemi 株式會社