【适合】如果业务确实无法在 2027 年 1 月 12 日前迁移，且现有授权与 Azure Arc 条件符合微软要求，Windows Server 2016 ESU 可作为有期限的安全更新过渡方案；能按期迁移，就优先迁移，不要把 ESU 当成长期支持。微软将 Windows Server 2016 的扩展支持截止日定为 2027 年 1 月 12 日，ESU 配置已于 2026 年 8 月 3 日开放，相关计费自 2027 年 1 月 13 日开始。(生命周期日期；ESU 实施安排)
仍有 Windows Server 2016 生产负载、需要确认支持截止后如何维持安全更新的 IT 管理员，可以从资格和覆盖范围开始核对。
需要确认现有授权、Azure Arc 连接及更新管理方式的运维负责人，也适合参考本文清单。
如果团队正在比较继续运行旧环境与迁移到受支持 Windows Server 版本，文中的决策表可帮助确定下一步。
最后更新于 2026 年 11 月 6 日；数据核实自 Microsoft Lifecycle、Microsoft Learn 的 Windows Server 2016 ESU 与 Azure Arc 资料。
先按时限判断：ESU 是过渡方案，不是延长完整支持
“Windows Server 2016 停止支持”并不表示服务器会在截止日自动停机；关键变化是常规支持结束，不能再把旧有系统当作持续获得常规安全更新、功能改进和技术支持的受支持平台。对仍承担 IIS 网站、ASP.NET 应用或业务软件的主机，应该把2027 年 1 月 12 日视为迁移决策截止点，而不是继续运行的保证期限。
ESU 的定位是迁移过渡期间的扩展安全更新。它提供符合条件的关键和重要安全更新，微软说明 Windows Server 2016 ESU 最长可延续至 2030 年；它不会恢复完整产品支持，也不包含新功能、客户要求的非安全修复或设计变更。更新也以微软实际发布为准，不能据此假定所有软件故障都能获得修复。(ESU 更新范围与限制；Windows Server 2016 ESU 准备指南)
核对 ESU 开始时间：可提前配置，更新覆盖从支持结束后衔接
Windows Server 2016 ESU 可在 Azure 门户中从 2026 年 8 月 3 日起配置；Azure Arc 启用的 ESU 相关计费从 2027 年 1 月 13 日开始。该安排说明可以提前做资格和接入准备，但“已在门户配置”不代表可以跳过许可核验，也不代表迁移计划可以无限期搁置。
| 核验事项 | 微软资料说明 | 对计划的影响 |
|---|---|---|
| 扩展支持截止 | 2027 年 1 月 12 日 | 把迁移决策和测试安排在截止前完成 |
| Azure Arc ESU 配置开放 | 2026 年 8 月 3 日 | 可提前检查接入、许可和覆盖状态 |
| Azure Arc ESU 相关计费开始 | 2027 年 1 月 13 日 | 预算和账单应按实际资格、组织合同及微软当前条款核实 |
| ESU 更新期限 | 最长至 2030 年 | 只为有明确迁移计划的过渡期评估，不当作长期平台承诺 |
| 更新范围 | 关键和重要安全更新 | 不把非安全修复、新功能或设计请求纳入预期 |
至于“ESU 什么时候开始”，要区分提前配置与支持结束后的 ESU 更新阶段：前者已开放，后者围绕支持截止之后的安全更新衔接。制定内部维护日历时，应再查微软当期说明和组织自己的授权记录；不要只凭 Azure 门户里出现一项服务器资源就判断许可已经生效。
第一步：按版本与授权核对资格，不要从“已租用”推定符合
微软资料列出的 Windows Server 2016 ESU 适用版本为 Standard 和 Datacenter。资格还涉及原系统授权、ESU 授权方式及组织适用的合同条件；常见核对点包括 Software Assurance（SA）或等效服务器订阅，以及实际采用的授权计划。Hosted 环境的规则也应结合微软现行说明和合同逐台确认。(Windows Server 2016 ESU 授权指引)
通过 Azure Arc 配置 ESU 时，授权方式还涉及实体核心或虚拟核心，以及 Standard 或 Datacenter 的许可属性。微软的许可指引列出实体核心授权每台至少 16 个实体核心，虚拟核心授权每台虚拟机至少 8 个虚拟核心；这些是该许可方案的规则，不是对某台主机硬件规格或价格的描述。
按下面顺序检查，比只问“这台机器能不能装 Arc”更可靠：
- 先记录每台服务器的 Windows Server 版本、版本分支和 Standard／Datacenter 版本信息。
- 找到原始授权凭据及适用的 SA、等效订阅或合同记录；不确定时向组织授权负责人或微软授权渠道核实。
- 将实体机、虚拟机及灾备实例分别列出，按对应方式确认授权范围和核心数。
- 核对 ESU 许可是否已在目标 Azure 订阅中配置、激活，并覆盖这台服务器所需的核心范围。
- 把核验结果保存到资产记录中；不要仅凭服务商销售页面或租用 Windows Server 的描述推断 ESU 资格。
第二步：检查 Azure Arc 接入，区分“连接成功”和“覆盖生效”
要通过 Azure Arc 获取 Windows Server 2016 ESU，服务器不仅要接入 Azure Arc，还要满足 ESU 的注册和许可要求。微软当前的故障排查资料要求 Windows Server 2016 使用 1.62 或更高版本的 Connected Machine Agent，并核对 Azure Arc 服务器处于 Connected 状态、ESU 许可已激活且核心分配充分。接入 Arc 只是前置环节，不是覆盖资格的最终结论。(Azure Arc ESU 故障排查条件)
网络管理也要在生产变更前验证：检查出站代理、防火墙和证书访问是否允许代理建立连接，并确认组织现有更新管理流程能够发现和部署所需更新。微软的 Azure Arc 网络要求文档应作为端点核对依据；如果机器只能在受限网络中运行，就先让网络团队验证规则，不能把“安装程序运行完毕”当作连通性验收。(Connected Machine Agent 网络要求)
可由运维人员按图形界面和命令行完成初步检查：
- 确认操作系统。 在“设置”或“系统信息”中查看版本和版本信息；也可以用管理员 PowerShell 执行：
powershell Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber - 确认代理服务状态。 在“服务”中查找 Azure Connected Machine Agent 对应服务；也可以执行
Get-Service himds查看服务是否运行。服务在运行并不等于 ESU 已生效。 - 确认代理版本与 Arc 状态。 在 Azure 门户的 Azure Arc 服务器资源中核对连接状态和代理版本；发现版本不符合微软当前要求时，先按官方安装指引升级，再复查连接。
- 确认 ESU 许可关联。 在相关 Azure 资源和 ESU 许可配置中检查授权是否激活、许可核心范围是否覆盖目标服务器，并确认该服务器已关联相应许可。
- 确认更新链路。 按组织既有更新管理流程检查 ESU 覆盖状态、适用更新是否可见，以及服务器是否能按维护流程接收并安装更新。
- 留存验收证据。 保存门户状态、代理版本、许可关联信息和最近更新记录；如状态异常，按微软故障排查文档逐项定位，不能仅凭 Arc 资源列表判定合格。
如果代理显示已连接，但许可未激活或服务器未关联许可，处理方向是补齐 ESU 授权与注册，不是重复安装代理。若网络或代理版本不满足要求，则应先修复接入条件，再判断 ESU 是否适用。
用迁移就绪度作比较：符合 ESU 资格也未必值得继续留在旧环境
ESU 解决的是一段时间内的安全更新覆盖问题，不会替业务团队解决应用兼容、供应商支持、备份恢复和切换回退等迁移问题。对于 IIS 和 ASP.NET 业务，至少要盘点运行时与组件、站点绑定和证书、计划任务、文件权限、外部依赖及部署流程；Windows 专用软件还要拿到供应商对目标 Windows Server 版本的兼容和支持确认。
| 现状与判断 | 下一步优先动作 | 为什么 |
|---|---|---|
| 符合 ESU 条件，但迁移尚未完成准备 | 评估 ESU 是否能覆盖明确的过渡期，同时建立新环境兼容性测试和退出日期 | 先保留安全更新过渡选择，但避免让 ESU 变成无期限续用理由 |
| 符合条件，且迁移测试正在推进 | 继续准备新环境；按微软资格配置 ESU 作为切换前后的有限过渡 | 过渡期间仍须管理补丁、备份与回退，不应因此取消迁移 |
| 授权或 Arc 条件不明确 | 暂不假定有 ESU；先找齐合同、授权和网络证据，并同步制定迁移备选方案 | 连接 Arc 不等于授权合格，核验等待期间存在覆盖不确定性 |
| 无法确认授权资格，或能够按期迁移 | 优先迁移到受支持的 Windows Server 版本 | 避免把迁移窗口押在尚未确认的 ESU 资格上 |
选择新目标版本时，也要对照业务软件供应商的支持矩阵和目标系统生命周期，而不是单凭版本更新就认定兼容。微软当前的 Windows Server 版本信息可用于核对 Windows Server 2022、Windows Server 2025 等受支持目标的生命周期；版本适配结论仍需应用供应商确认。(Windows Server 版本及生命周期信息)
用可勾选清单确认迁移准备：把备份、测试和回退写成任务
兼容性尚未核实，或没有可验证的恢复方案时，ESU 可以作为待评估的过渡路线，但不能替代迁移准备。以下清单用于判断迁移窗口是否真实可行；各团队应根据自身系统依赖安排日期，不以通用工期估算替代测试结果。
- [ ] 列出资产。 逐台登记系统版本、版本信息、角色、应用负责人、业务优先级和授权凭据。
- [ ] 盘点应用依赖。 记录 IIS 站点、应用程序池、ASP.NET／.NET 运行环境、证书、身份验证方式、计划任务、共享目录与外部接口。
- [ ] 确认供应商支持。 获取 Windows Server 目标版本和业务软件版本的兼容依据；仍在支持不明确状态的系统先单独标记。
- [ ] 验证备份可恢复。 确认数据库、应用配置和文件备份完整，并在隔离测试环境中执行恢复验证，保存结果。
- [ ] 搭建测试目标。 在新环境复现关键配置，跑通登录、业务读写、打印或文件交换、外部接口及计划任务等关键路径。
- [ ] 制定切换与回退。 指明切换负责人、变更窗口、数据同步方式、验收条件和触发回退的条件；写清回退时如何避免新旧环境数据分叉。
- [ ] 做出 ESU 决策记录。 若选择过渡，记录资格核验依据、覆盖服务器清单、复查日期和计划退出条件；若选择迁移，记录应用测试和回退验收结果。
应用兼容性盘点和并行迁移的具体做法属于不同的实施问题，应按本文的资格与就绪度判断结果继续展开：先把依赖列齐，再决定是否需要专门设计迁移路径。这里不预设固定迁移时长，因为业务依赖数量、数据量、供应商配合和维护窗口都不同。
完成下一步核对：ESU 资格不明时，先选可验证的迁移路线
如果当前方案是在未经核实的授权状态下继续运行 Windows Server 2016，主要风险是 ESU 覆盖可能不成立、旧系统支持已经临近截止，以及团队可能没有经过验证的恢复与回退方案；若当前主机还是共享虚拟实例，还要另外核对资源争用和底层配置限制。此时不应把“服务器仍能开机”当成长期可用的依据。
当业务需要稳定运行的 Windows 服务、专属硬件资源或更可控的系统环境时，可以把独享 AMD 物理服务器纳入迁移目标比较；它与共享 VPS 的资源隔离方式不同，但仍不能替代微软授权，也不会自动附带 ESU 或 Azure Arc 服务。准备新环境前，可先查看 XFP Cloud 的服务器选项 和 机器配置页面，按页面实际列出的 Windows Server 版本与语言核对；购买后还可对照付款后流程说明确认后续步骤。最终选项以页面当前产品表为准，产品可选项不代表 ESU 资格，也不代表提供 Azure Arc 配置或迁移代运维。