从 Rocky Linux 迁出
多数迁移文档讲的是迁入 Rocky。本页讲反方向：已经在用 Rocky 的团队，什么情况下该考虑换掉它，以及在没有官方「迁出工具」的前提下怎么把这件事做得可控。
官方有没有「迁出工具」
Section titled “官方有没有「迁出工具」”在官方文档的迁移类指南组里查不到「从 Rocky 迁出到其它发行版」的条目：该组只覆盖 guides/migrate2rocky（把别的 EL 迁入 Rocky）与 guides/migrating_cgroup_v1_to_c2（同一系统内部的 cgroup 代际迁移），gemstones/dnf-swap 是包级替换示例。这不等于「没有迁出手段」——/migrate-to 页已登记两条官方/官方脚本支撑的原地转换路径（AlmaLinux 的 almalinux-deploy.sh 与 Red Hat 的 convert2rhel）。整个指南组里不存在「从 Rocky 迁出到其它发行版」的条目，也没有对应的一键工具。
这不等于「不可能迁出」，而是说：迁出没有官方路径可依，只能按重建（重装 + 数据/配置迁移）来规划。
迁移方向的事实背景
Section titled “迁移方向的事实背景”判断「要不要迁」时，先把支持窗口这条事实对齐：官方把生命周期分成两段——Active Support（亦称 Full Support）期间每 6 个月出一次小版本，Security Support（亦称 Maintenance Support）期间只提供安全更新。也就是说，进入 Security Support 之后你仍然拿得到安全补丁，但不再有新功能与常规缺陷修复。
迁出的触发条件
Section titled “迁出的触发条件”把「感觉该换了」变成可判断的条件，通常来自这几类：
- 合规或采购要求：需要厂商支持合同、认证清单或特定发行版；
- 生态锁定：某个商业软件只在其兼容矩阵里列了别的发行版；
- 团队技能：运维团队已有另一发行版的成熟流程与自动化资产；
- 版本策略：你的场景需要与 Rocky 的节奏不同的发布模式。
评估与切换的可控做法
Section titled “评估与切换的可控做法”没有官方工具，就意味着迁出是一次重建项目，而不是一条命令。按下面的顺序推进可以把风险压到最低：
- 盘点与分级：把主机按「无状态 / 有状态 / 特殊依赖」分三类，先迁无状态的；
- 配置即代码：把服务配置、systemd 单元、定时任务、防火墙规则先落进版本库——迁出时才不用靠回忆；
- 数据先行：数据库与文件存储的迁移方案先跑通（可用备份与恢复里的官方备份工具做搬运与校验）；
- 并行验证：新旧环境同时在线一段时间，比对业务指标后再切流量；
- 保留回滚点：切换前留一份可启动的旧系统快照，并明确回滚的决策人与时间窗。
- 从 RHEL / Alma / Oracle / CentOS 迁入 Rocky — 反方向的官方工具路径
- 备份与恢复 — 官方备份工具与策略
- Rocky 版本与生命周期 — 支持窗口与 EOL 日期
- 常见问题 — 兼容性与支持边界