Dynamics NAV 2018 支持将于 2028 年 1 月 11 日结束：在此之前该做什么

2028 年 1 月 11 日，Microsoft 将结束对 Dynamics NAV 2018 的扩展支持，这是它发布的最后一个 NAV 版本。NAV 2017 早一年结束，日期是 2027 年 1 月 11 日。这两个日期都不会关掉任何东西。Microsoft 并没有说过 NAV 会停止运行，永久许可证也会继续有效。停止的是安全更新和付费支持。

税务和法规更新停得更早。它们属于主流支持，而 NAV 2018 的主流支持已于 2023 年 1 月 10 日结束。所以，NAV 2018 的生命周期终止并不是 2028 年的一道悬崖。法规更新将近四年前就停了，安全修复将在 14 个月后停止，许可方面的变化则在 2031 年到来。

本文写给德语区（DACH）、北欧、比荷卢和英国的中型制造商、分销商和服务公司的财务和 IT 负责人。这些公司运行着 NAV 2009 至 2018 之间的某个版本，系统里积累了多年的定制，而做这些定制的合作伙伴，如今往往已经不在了。

什么结束，何时结束

NAV 2018 遵循 Microsoft 的固定生命周期策略，具体日期列在 NAV 2018 生命周期页面上。

扩展支持是 NAV 2018 自 2023 年 1 月以来所处的阶段，内容是安全更新和付费支持。2028 年 1 月 11 日之后，安全更新停止。按照该策略，超过这一日期的付费支持只能通过扩展安全更新计划获得，而 Microsoft 并不为 NAV 提供扩展安全更新。

税务和法规更新版本需要有效的 Enhancement Plan，并随主流支持一起提供。Microsoft 的 NAV 2018 累积更新列表止于 2023 年 1 月发布的 Cumulative Update 60。此后，没有任何一个 NAV 2018 本地化版本从 Microsoft 那里得到过新的法规功能：NAV 2018 的扩展支持不包括这些。

Microsoft 2026 年 7 月关于 NAV 迁移选项的文章列出了 2031 年 4 月 30 日的许可变化，并告诉 NAV 客户“现在就开始评估其长期 ERP 战略”。

底层平台

NAV 2018 的系统要求最高只到 SQL Server 2019 和 Windows Server 2022。SQL Server 2014 和 2016 已经结束扩展支持，Windows Server 2016 也将在 2027 年 1 月 12 日步其后尘。在 SQL Server 2019 和 Windows Server 2022 上，数据库的支持持续到 2030 年 1 月 8 日，操作系统的支持持续到 2031 年 10 月 14 日。运行在它们之上的 ERP 却没有这么长的支持期。

NAV 收不到的法规变化

Microsoft 为 NAV 2018 发布的最后一次法规更新是在 2023 年 1 月，早于以下任何一条规定生效。

• 德国。 据联邦财政部介绍，自 2025 年 1 月 1 日起，企业之间的国内销售以电子发票（E-Rechnung）为原则，每家企业都必须能够接收电子发票（有一个电子邮箱就够了）。其他形式的发票可以继续使用到 2026 年 12 月 31 日；对于上一年营业额不超过 800,000 欧元的开票方，可以用到 2027 年底。XRechnung 和 2.0.1 及以上版本的 ZUGFeRD 符合要求，但 MINIMUM 和 BASIC-WL 配置档除外。
• 比利时。 据联邦电子发票门户介绍，自 2026 年 1 月 1 日起，每家需缴纳增值税的比利时企业都必须使用结构化电子发票。Microsoft 针对比利时的 Business Central 文档指明，传输渠道是 Peppol 网络。
• 波兰。 KSeF（国家电子发票系统）自 2026 年 2 月 1 日起对 2024 年销售额超过 2 亿兹罗提的公司强制实施，自 2026 年 4 月 1 日起对其余企业强制实施；每月开票总额较小的企业享有例外，直到 2026 年 12 月 31 日。波兰不在 Microsoft 的 NAV 2018 本地化版本之列，所以波兰的 NAV 从来不是通过 Microsoft 的 NAV 2018 更新获得本地化的。

Business Central 的德国本地化版本列出了 XRechnung、ZUGFeRD 和 Peppol 开票功能，比利时本地化版本则列出了通过 Peppol 接入点开票。对于其他国家，请与您的税务顾问一起，把现行规定和您的 NAV 能发送、能接收的内容逐一对照。

您的版本和升级路线

Microsoft 的升级路径页面规定，从 NAV 2015、2016、2017 或 2018 升级分三步：先到 Business Central Spring 2019（版本 14），再到 Business Central 2024 release wave 2（版本 25），最后到当前的 Business Central 2026 release wave 2（版本 29）。该页面上有一句话决定了大部分预算：“这条路径要求您将应用程序从 C/AL 转换为 AL。”

从 NAV 2009 出发，经由 NAV 2013 的路线同样要经过 NAV 2018。无论您的团队怎么称呼这套系统，从这些版本做 Navision 到 Business Central 的迁移，都是一连串的升级。

版本 14 是最后一个支持 C/AL 的版本，而把 C/AL 对象转换为 AL 的工具 Txt2Al 只随它一起提供。版本 14 本身已于 2025 年 10 月结束支持，新客户也不能在生产环境中使用它：它是一块垫脚石，不是落脚点。从版本 15 起，AL 取代了 C/AL，Business Central 完全改为基于扩展。版本 25 是必经的一站，因为自版本 26 起，不再支持从版本 14 直接升级到最新版本。

每一条路线，包括最终落在云端的那些，都要经过本地部署的 Business Central 14。

工作真正在哪里

工作量随系统里加进去的东西增长，而 NAV 的定制通常是直接写进 Microsoft 自己的对象里的。

定制

在 NAV 中，合作伙伴的定制方式是直接修改 Microsoft 的 C/AL 代码：在客户表里加一个字段，在过账例程里加几行代码。Business Central 则要求基础应用程序保持交付时的原样，您的修改放在它旁边，以响应事件的扩展的形式存在。

Txt2Al 转换的是语法，不是设计。Microsoft 把创建这些扩展称为升级的“第一步，也是最大的一步”。它的 NAV 定制迁移手册列出了处理方法：自定义表变成 AL 表；标准表上的自定义字段变成表扩展，数据一并迁移过去；Microsoft 代码单元（codeunit）内部的修改变成事件订阅者；XMLports 和查询则要重建。在 Windows 客户端中所做的个性化设置会丢失。

在本地部署中，Microsoft 仍然允许在代码层面定制基础应用程序，尽管它强烈建议使用扩展。它的本地部署许可指南（2023 年 6 月版）写道，从 NAV 迁移过来、其定制与“universal code”（通用代码）不兼容的客户，必须额外许可一个 universal code 模块。在云端，一切都必须是扩展。

清点被修改过的标准对象、自定义表和字段，以及其中哪些还有人在用。

报表

每一张 C/AL 报表都要用 AL 重建，要么做成新报表，要么做成报表扩展。布局可以保留：RDL 和 Word 都受支持，Microsoft 建议单据类报表使用 Word，因为 RDL 可能更慢。列出所有自定义报表，没人运行的就停用。

.NET 加载项

.NET 互操作只在本地部署中可用。在云端，Microsoft 给出的替代方案是控件加载项、Azure Functions 或外部 API。在本地部署中，用 .NET Framework 编译的加载项从版本 22 起已无法运行，必须迁移到 .NET Standard。列出每一个组件、它的用途，以及它的供应商是否还在。

集成与 Web 服务

从版本 29 起，Microsoft 的页面不能再发布为 SOAP 端点；从版本 30 起，也不能再发布为 OData 端点。Microsoft 针对 SOAP 给出的办法，是在您自己的扩展中复制一份该页面。在云端，集成只能通过 OAuth2 登录。因此，通过 SOAP 调用 NAV 标准页面的网店、EDI 连接或仓储系统，不做改动是过不了这次迁移的。要从系统本身构建清单（已发布的 Web 服务、计划任务、读写的文件），每一项都要有负责人和决定。

Windows 客户端

NAV 的 Windows 客户端在版本 15 中被移除。用户改用浏览器、移动应用或桌面应用。程序化打印也随之取消，所以凡是 NAV 无需用户点击打印就会打印的东西，都需要一条新的途径。还要规划培训：每一个界面都会变。

数据

带有代码定制的表中的数据，除非两端都有扩展来处理，否则无法进入云端的 Business Central。Microsoft 要求在切换之前，至少在沙盒中把完整迁移演练一次。要计划多次演练。把迁移及其校验写成代码，能在一份新的生产数据副本上反复运行，每次都比对余额和未清项。财务部门签字确认的依据是数字对得上，而不是任务跑完。

云端还是本地部署

在任何人开始转换代码之前就要做出这个决定：它决定了什么能保留下来。Microsoft 列出了本地部署中缺少的功能。

云端。 Microsoft 的云迁移工具要求从本地部署的版本 25 或更高版本出发，并运行在 SQL Server 2016 或更高版本上。因此，把 NAV 完整升级到云端 Business Central 的路线是：NAV，然后在本地部署中依次升级到版本 14 和版本 25，最后迁移。另一种做法是 Business Central 14 重新实施工具，它只把主数据、期初余额和设置从版本 14 迁移到云端。该工具处于预览阶段，而 Microsoft 表示，预览功能“不适合在生产环境中使用”。

Bridge to Cloud 3。 Microsoft 的合作伙伴公告规定，加入期限为 2026 年 1 月 1 日至 2027 年 12 月 31 日：通过 Cloud Solution Provider（云解决方案提供商）购买，在固定且不可续订的三年期限内，可在商业目录价基础上优惠 30%。它适用于 2024 年 9 月 1 日之前购买、且 Enhancement Plan 仍然有效的本地部署许可证，并且只适用于您此前从未许可过的云端产品。Microsoft 的合作伙伴网站还提到了一种 Business Central 迁移代金券，其条款没有公开。

本地部署。 每个版本的支持期约为 18 个月（2026 年 10 月发布的版本 29 支持到 2028 年 4 月），因此要保持受支持状态，就得按这个节奏升级，每次都重新测试您的扩展。自 2025 年 4 月起，新的本地部署客户只能购买订阅。对于把永久许可证转过来的 NAV 客户，一位 Microsoft 社区经理在 2025 年 2 月写道，过渡政策没有变化。我们没有找到 Microsoft 为这项权利设定的截止日期，所以请把您的条款落实为书面形式。

决策框架

现实的路径有四条。

在本地部署中升级到当前版本。 在您自己的服务器上，先到版本 14，再到 25，然后到当前版本。这适合有 .NET 加载项，或有暂时无法替换的集成的公司。您要接受大约每 18 个月升级一次；如果代码留在基础应用程序中，还要多许可一个模块。

先升级，再迁移到云端。 沿同样的路线升级到版本 25，然后使用云迁移工具。每一项定制都要变成扩展，每一个 .NET 加载项都要被替换，所以这条路上的转换工作量最大。如果您符合 Bridge to Cloud 3 的条件，它 2027 年 12 月 31 日的截止日期就落在项目期间。

在云端 Business Central 中重新开始。 带上主数据、期初余额和设置，保留旧系统供查阅，只重建仍然需要的定制。Microsoft 为此提供的工具处于预览阶段，并且以版本 14 为起点。选择另一套 ERP 的公司，面对的数据和集成工作也大致相同。

在限定期限内继续使用 NAV。 它会继续运行。从 2028 年 1 月 11 日起，它得不到任何安全修复，每一种新的电子发票格式都要您自己开发。只有满足以下条件，这条路才站得住：有一位指定的人负责维护，系统与公共互联网隔离，并且定好结束日期。

接下来几个月，无论您选哪条路

距离 NAV 2018 停止支持还有 14 个月。如果您的财年在 12 月结束，1 月初切换就会撞上年终结账，所以现实的目标是在 2027 年秋季上线。如果您用的是 NAV 2017，日期只剩两个月：项目期间会有一段时间在无支持状态下运行，尽量让这段时间短一些。

从现在到 2027 年 3 月底：

1. 确认您的起点：NAV 版本、SQL Server 和 Windows Server 版本，以及您的 Enhancement Plan 是否有效。Bridge to Cloud 3 和本地部署许可证的过渡都取决于这一点。
2. 保护好代码。 导出 C/AL 对象并纳入版本控制，尤其是当编写这些代码的合作伙伴已经不在的时候。
3. 清点定制，以及其中哪些在用。要一个数字，而不是一个印象。
4. 建立集成清单：每一个 Web 服务、文件交换和 .NET 加载项，都要有负责人和决定。
5. 核实您在每个开票国家的电子发票义务。
6. 决定走云端还是本地部署，而且要在代码转换开始之前。
7. 预订资源：合作伙伴、负责测试的您自己的财务和 IT 人员，以及切换窗口。

从 2027 年秋季上线倒推：夏季做演练和用户测试，春季开发扩展、改造集成，这个冬季做分析和决策。

从哪里获得帮助

迁移期间必须稳住的是业务本身：发票要符合法律现在要求的格式，仓库要继续发货。我们与您的 Business Central 合作伙伴并肩工作；如果当初开发您 NAV 的合作伙伴已经不在，我们也直接与您合作。工作内容包括：把 C/AL 定制转换为 AL 扩展，重建集成和报表，编写数据迁移代码并完成对账，以及处理 NAV 周边那些必须在迁移后继续运行的应用。这些工作在我们的 ERP 现代化页面上有介绍，而遗留系统维护则覆盖在您迁移之前原地保留的系统。如果您希望在签订升级项目之前，先把您的定制和集成清点清楚，请写信到 office@c9group.dev。