推送应用至Heroku收到Heroku-16栈停服提示，求升级到Heroku-20的稳妥方案

为什么Heroku不再维护旧版本且不提供自动迁移服务？ #

• 停止维护旧版本的核心原因是底层依赖的生命周期限制：Heroku的官方栈均基于Ubuntu长期支持（LTS）版本构建，Heroku-16对应的Ubuntu 16.04本身已于2021年停止官方支持，Canonical不再提供安全补丁、漏洞修复和系统更新。如果Heroku继续维护已结束生命周期的底层系统，需要自行承担所有安全风险，且维护成本会随时间快速上升，不符合云服务的公共运维逻辑。
• 不提供自动迁移是因为应用兼容性差异过大：不同应用依赖的系统级库、语言 runtime 版本、第三方扩展、自定义编译逻辑千差万别，例如很多运行在Heroku-16上的老应用依赖的libssl1.0、低版本Python/Node.js运行环境在Heroku-20中已经被移除，自动迁移大概率会直接导致应用崩溃，且故障责任边界难以界定，因此Heroku只会提供迁移指引，不会做强制自动迁移。

低风险迁移到Heroku-20的可操作方案 #

整个流程可以做到零强制中断、随时回滚，操作门槛很低：

• 先做前置准备
  运行heroku stack确认当前应用的栈版本为heroku-16，导出应用的所有环境变量到本地备份，同时给当前线上的代码版本打标签，留作回滚基准。
• 先做测试环境验证，不要直接修改生产配置
  新建一个独立的测试应用，创建时直接指定栈为Heroku-20，命令为heroku create --stack heroku-20，把生产环境的配置变量同步到测试应用后部署代码，跑通所有核心功能测试、验证依赖是否正常，排查所有报错后再操作生产环境。
• 生产环境灰度升级
  测试通过后，运行heroku stack:set heroku-20修改生产应用的栈配置，该操作不会立刻生效，仅会在下次部署时启用新栈。选择业务低峰期做一次正常的代码部署，部署完成后验证所有功能正常即完成迁移。
• 预留回滚方案
  如果新栈部署后出现异常，直接执行heroku rollback就能回到上一个基于Heroku-16构建的正常版本，同时把栈配置改回heroku-16即可，不会造成长时间业务中断。

内容的提问来源于stack exchange，提问作者maudulus