从 RHEL/Alma/Rocky 迁入 Stream
大多数迁移文档讲的是「离开 CentOS Stream」，本页讲反方向：已经有 RHEL 订阅或正在用 AlmaLinux、Rocky Linux 的团队，为什么要把机器迁到 CentOS Stream，以及在没有官方路径的情况下怎么把这件事做得可控。
谁需要这条反向路径
Section titled “谁需要这条反向路径”反向迁入通常不是「换一个更省钱的系统」，而是出于三类具体需求：
- 提前验证：业务要跟着 RHEL 的下一代小版本走，希望在正式升级之前，先在一条接收面向 RHEL 更新的流上把兼容性测出来；
- 跟着开发流走：团队要给上游提问题、参与修复验证，希望机器就在这条流上，而不是等发行版重建；
- 统一基线：混合环境里既有订阅系统又有重建版，想把「预览与验证」这一层的基线统一到同一条流上。
Stream 在方向上的位置
Section titled “Stream 在方向上的位置”官方在介绍 CentOS Stream 时写明：由于 CentOS Stream 只接收面向 RHEL 的更新，它由 RHEL 团队维护。这也是理解「反向迁入」的前提——你不是从一个下游系统换到另一个下游系统，而是把工作负载放到这条开发流上。
包与仓库差异：先弄清你要换掉什么
Section titled “包与仓库差异：先弄清你要换掉什么”反向迁入真正的工作量不在「装什么」，而在下面四处：
- 订阅与授权状态：从订阅系统迁出意味着放弃一部分官方支持关系与配套工具，这件事要由业务方确认，而不是由运维顺手做掉；
- 仓库来源与优先级：来源集合、启用状态与优先级规则都要重新对齐，混合来源是这类迁移最常见的后遗症；
- 第三方与自建内容：为原系统打包的第三方内容、内部自建包、语言运行时的私有源，都要确认在目标流上仍可用；
- 内容代差：不要把「同名包就一定是同一个版本」当成前提，需要按业务实际用到的包逐项核对可得性与版本走向。
Stream 自身提供哪些仓库、启用状态如何，见CentOS Stream 仓库与滚动内容；本页不重复登记那部分事实。
迁移步骤：本次核对未取得官方路径
Section titled “迁移步骤：本次核对未取得官方路径”取而代之的是两件你能自己决定的事：一是换机重建（按盘点清单在新机器上重装，验证通过后切换），二是保留回滚点（旧机器或快照在原处不动，直到观察窗结束）。两条都不依赖官方路径。
通用评估与切换流程（工程实践）
Section titled “通用评估与切换流程（工程实践）”- 备份与回滚点：整机镜像或快照先落地，回退步骤写成可执行清单；
- 应用与配置盘点：服务、端口、定时任务、账户、外部认证源、数据挂载点逐项登记；
- 依赖核对：把业务实际用到的包与运行时列出来，在目标流上确认可得性与版本走向；
- 并行验证：新机器与老机器同时在线，用同一批业务用例比对，含批处理与备份；
- 切换与观察窗：先切非关键流量，跑完一个完整业务周期再全量切换。
- 基线漂移：目标系统的基线会随内容更新而变化，变更窗口要按业务节奏安排，并定期复核依赖是否仍然满足；
- 支持关系的变化：从订阅系统迁出后，厂商支持渠道不再覆盖这些机器，问题处理方式要提前约定；
- 回退成本：迁移越远，回退越贵。保留旧机器或完整快照，是唯一把回退成本压到最低的办法；
- 混合状态：来源、代理与内部镜像没有一次改干净时，系统会长期停在半迁移状态——这类问题通常要几周后才暴露。
- CentOS Stream 定位与适用边界 — 先判断这条流适不适合你
- CentOS Stream 仓库与滚动内容 — 来源集合与滚动内容的影响
- Stream 上的模块流与应用流 — 需要非默认版本线时怎么选流
- 用 Stream 预览 RHEL 次版本 — 把开发流当预览环境用
- CentOS Stream 大版本升级 — 已经在流上之后的大版本动作
- CentOS Stream 运维基线 — 迁移后的最小运维规范
- 从 CentOS Linux 8 迁入 Stream — 另一类源系统的历史步骤与失效说明