Sana 9.3 已过生命周期终止。这意味着什么，取决于谁在维护它。

发布：2026 年 8 月 20 日 · 阅读约 12 分钟

如果你运行着一套 Sana 9.3 商城，却没有人在维护，那么你今天运行的就是无支持软件。不是将来，是今天。这件事值得冷静理解，而不是慌张应对，因为诚实的答案并不自动等于「立刻重建」。

先把日期说清楚

• Sana 9.3.0 至 9.3.4：于 2024 年年底生命周期终止。
• Sana 9.3.5：于 2025 年年底生命周期终止。

两个日期都已过去。你此刻若运行任何 9.3 版本，都已越过生命周期终止，期间用于过渡的延长支持安排也已到期。Sana 的原始表述见其生命周期终止公告。

生命周期终止究竟拿走了什么

越过生命周期终止，并不意味着你的商城会在某个周二停止运行。没有任何东西被关闭，也没有许可证到期。上周的商城，今天还是那套商城。

消失的是它背后的那张安全网：

• 安全补丁。平台上新发现的漏洞，厂商将永久不再修补。
• 平台缺陷修复。Sana 自身代码里的缺陷，现在要由你自己绕过去。
• 升级上报的通道。当问题出在平台本身而非你的定制上时，你已经没有一张能真正换来修复的工单可提。
• 兼容性维护工作。这一条最容易让人措手不及，所以单独用一段来讲。

即便你的代码是静态的，你的商城也不是。浏览器在变。支付服务商会下线集成、调整要求。TLS 与证书实践在推进。你的 ERP 由另一支团队按另一套节奏升级，它与商城之间的契约会在你脚下悄悄挪动。在受支持的平台上，这些大部分由别人替你吸收；越过生命周期终止之后，除非你自己安排，否则没有人吸收。

这才是生命周期终止日期的真实含义。它不是悬崖，而是撤走了那个在世界不断变化时、默默让一套五年前的集成继续跑下去的东西。

如果打算留在 9.3，就必须有人维护它

这一部分是多数 9.3 用户没有算过成本的，因为多年来它包含在平台费用里，所以是隐形的。

留在 9.3 是一个正当的决定。对于一套跑得好、在赚钱、业务形态也没有改变的商城，这在相当长一段时间内都可能是正确选择。B2B 买家并没有吵着要重新设计，而为了重做而重做，替换平台要承担的风险太大。即使本页另外两条路对我们更有价值，我们还是把这句话说明白。

但只有在你补上厂商原本承担的那部分职责时，它才是正当的决定。这意味着要有一个真正读得懂代码、并为之负责的第三方，覆盖：

• 安全。盯住平台以及其下整个技术栈的问题，并进行修补或缓解，因为 Sana 不会再做了。
• ERP 契约。在 SAP、Dynamics 365、Business Central 或 NAV 按自己的节奏升级时，保证客户查询、价格、库存、下单、发运与发票继续可用。
• 外部世界的变动。浏览器、支付网关、证书，以及某个第三方默认「大家早就升级了」而带来的周期性意外。
• 修好坏掉的东西。不是上报，是修好，因为你上面已经没有人了。
• 在出事之前就熟悉这套系统。被维护的商城与被搁置的商城，差别几乎都体现在最糟糕的那一天，而那时再开始读代码已经太晚。

越过生命周期终止后无人担此职责地继续运行，与其说是决定，不如说是在赌不会出事。这个赌局你大多数月份都会赢。输的那个月，你会输在订单流程上，而且没有厂商可以求助。

顺带一提，这正是我们长期在做的工作。自 2020 年起，我们持续运行着一套深度定制、带真实 ERP 集成的 Sana 9 商城，经历过平台升级上报、集成意外和性能优化。也正因如此，本文后半部分对迁移的真实代价说得相当直白。

真要迁移时，先弄清你买的是什么

等你判断时机成熟，有一个预期值得先纠正，因为它是这次转换中代价最高的误解。

Sana Commerce Cloud 的首个版本在文档中标记为版本 10。你在 9.3。技术采购者被训练出来的所有直觉都会说：9.3 到 10 是一次递进，比 9.2 到 9.3 大一些，但性质相同。

它并非如此，而这正是 Sana 自己的立场，发布在其支持文档中一篇题为 Why a New Sana Product, and Not a New Version? 的页面里。

Sana Commerce Cloud 是解耦架构，前端基于 React，后台是全新的，内容体系也完全重做，围绕可视化页面搭建器构建。Sana 9.3 则是运行在 .NET Framework 上的 ASP.NET MVC，服务端渲染 Razor，以经典管道模式跑在 IIS 上。这两者共享一个产品家族和一套 ERP 理念，但不共享代码。

实际后果是：按「升级」立项的项目，通常会在六周左右被重新定义为「更换平台」，而且通常发生在预算已经敲定之后。第一天就把范围界定对，几乎就是这个项目做得好与做得差的全部差别。

究竟哪些能带走

这部分值得直说，因为答案接近于「几乎没有」。

带不走

• 你的主题与模板。Razor 视图和 9.3 的主题覆盖层，没有通往 React 前端的路径。每一个页面模板都要重建。
• 你的 CMS 内容。Flexi 页面建立在旧内容模型上。Sana Commerce Cloud 使用新的可视化设计器，页面与区块结构都不同。内容需要重新撰写，而不是导入。
• 你的定制开发。自定义插件、HTTP 模块、视图覆盖，任何基于 9.3 SDK 编译的东西，一个都加载不了。这通常是预算里最大的一项，也最容易在估算中被遗漏，因为定制往往没有文档，其缘由只存在于某些人的记忆里。
• 与旧 DOM 绑定的前端 JavaScript 与 CSS。针对服务端渲染标记编写的选择器，将无处可依附。
• 后台配置。各项设置要在一个形态不同的新后台里重新录入。

能带走

• 你的 ERP。记录系统不需要迁移。SAP、Business Central、NAV、F&O，无论你用哪一套，都留在原地。
• 你的数据。客户、价格、库存、订单与发票都存在 ERP 里，而不是商城里。这是 Sana 实施方案在结构上最好的特性，也正是这件事之所以可以扛过去的原因。
• 你的集成契约。客户查询、价格查询、库存查询、下单并返回真实单号、发运状态轮询、发票获取。底层连接器会变，但商城向 ERP 索取的这六件事不会变。
• 你的业务需求。后台真正依赖的每一条业务规则。这才是真正的资产，也是唯一没人写下来的东西。

资产是需求，不是代码

连续多年运营一套 Sana 9 商城后得出的一个不太舒服的结论是：代码从来都不是有价值的那部分。有价值的是那些沉淀下来的决定：采购订单号必须填写且上限 25 个字符，因为 ERP 如此规定；只含空格的采购订单号必须被拒绝，而不是被悄悄接受；超出授权额度的子账号要转交给上级管理员审批；样品订单在 ERP 里是一种独立单据类型，而不是一个折扣；当 ERP 对该客户没有价格时必须禁用加入购物车，而不是放行一张注定会在下游失败的订单。

这些内容除了体现在你即将丢弃的那套代码的行为里，其他地方都没有记录。它们散落在多年的工单、邮件往来，以及当时理由显而易见、如今已无人记得的修复之中。

如果你从零开始重新做一轮需求调研再重建，你会以最艰难的方式、在生产环境中、从订单出问题的那些人口中，重新发现其中的一部分规则。所有失败的平台更换，都失败在这里。

这也是「即便你终究打算离开 9.3，也应当把它维护好」的最有力理由。被维护的商城，会保住一个熟悉这些规则的人；被搁置的商城，则把这些规则重新变回考古工作。

AI 真正帮得上忙的地方，和帮不上的地方

重建在很大程度上是一个翻译问题，而在已知边界之间做翻译，恰恰是当前 AI 工具真正擅长的事。有纪律地使用，它能显著改变这个项目的经济账；当成魔法棒来用，它只会一本正经地胡说八道。

帮得上的地方

• 从旧代码里提取需求。读完每一处定制、每一个视图覆盖、项目历史中的每一张工单，产出一份结构化的竣工记录，说明商城实际在做什么、为什么这么做。这是价值最高的用法，没有之一，因为它把你本来会销毁的资产，转化成了你能留下的资产。它同时也繁琐到以人力速度通常根本不会去做。
• 翻译模板。从 Razor 视图到 React 组件，是一种形态一致的机械变换。AI 擅长大批量处理形态一致的东西。
• 重新撰写内容。把旧的 Flexi 页面结构映射到新页面搭建器的区块上，在数百个页面的量级上，正好属于「手工做太大、又结构化到不值得专门写工具」的那类工作。
• 补上你从来没有过的回归测试。旧商城在被关停之前，一直是它自身行为的可运行规格说明。趁它还在跑的时候把这些行为固化成测试，你就有了检验新版本的基准。

帮不上的地方

• 判断哪些规则应当保留。你的 9.3 商城所做的事情里，有些是刻意设计的业务规则，有些是为绕开某个已不复存在的平台限制而留下的变通，还有些干脆是大家默默适应了的缺陷。要分清这三者，必须与实际经营业务的人交谈。没有任何模型知道哪个是哪个。
• ERP 语义。连接器换了。字段长度、单据类型和错误行为都需要针对新集成重新验证，而不能假定原样沿用。
• 任何你没有验证的东西。一个能渲染出来的生成组件，不等于一个正确的组件。评审的工作量是实打实的，并不会消失。

诚实的说法是：AI 并不能免掉重建。它免掉的是绝大部分考古工作、绝大部分机械翻译，以及「需求没写下来」这个借口。这已经是成本中很大的一块，以及几乎全部的风险。

一套行之有效的顺序

当你决定迁移时：

1. 先趁 9.3 还在运行时，把竣工状态记录下来。要早于任何新平台上的工作。如果这份清单你只做一件事，就做这件，因为旧商城一关，这扇窗就合上了。
2. 盘点所有定制，并逐一分类。保留、放弃，或改用平台原生功能替代。9.3 上相当一部分定制，本来就是为了绕开 Sana Commerce Cloud 现已原生支持的能力缺口，重建它们纯属浪费。
3. 在敲定前端方案之前，先用新连接器验证那六项 ERP 契约。集成上的意外是进度杀手。
4. 重建前端时，从流量最高的模板开始。分类页和商品页既最能带来收入，也最能暴露渲染问题。
5. 切换之前，让一个真实的经销商群体在新商城上与旧商城并行运行。B2B 买家对意外的容忍度异常低，而试点群体能揪出那些没人记录过的规则。

联系任何人之前，先做两件事

两件事，都不花钱，而且即使你从不雇任何人也有用：

1. 弄清楚你到底在哪个 9.3 版本上，以及谁在维护它。9.3.0 至 9.3.4 比 9.3.5 早整整一年到达生命周期终止。这两个问题都会改变事情的紧急程度，而第二个问题的影响比第一个更大。
2. 把你的后台一旦失去就会立刻察觉的每一条业务规则写下来。和处理订单异常的那个人坐下来，问他这个网站有哪些他依赖的行为。你会得到一份没人预料到的清单。那份清单就是接下来无论做什么的真正规格说明，它比你将收到的任何方案书都更有价值。

结论

从生命周期终止这个日期往前走，有三条诚实的路，而它们的排序并不取决于哪条对供应商更值钱。

1. 留在 9.3，但要有真正的维护。可以稳妥支撑数年。前提是有一个懂这套代码的第三方，承担 Sana 不再承担的安全、ERP 契约与故障修复。这是成本最低的选项，对不少商城来说也是当下正确的选项。
2. 迁移到 Sana Commerce Cloud。在几乎每一个真正重要的维度上都优于 9.3，也是产品线的走向。只是请按「披着版本号外衣的重建」来编预算，因为它就是。
3. 把视野放得更宽一些。如果自你采购 Sana 以来业务形态已经改变，那么以 ERP 集成为核心的模式，也许已经不再是合适的框架。这是一个值得摊开来谈、而不是回避的话题；比起看着你精心重建一个错误的东西，我们更愿意和你把话说明白。

真正会出问题的是第四条路，也是没有人主动选择的那条：留在 9.3，无人维护，并把这称为一个决定。

有本文涉及的实际项目吗？

自 2020 年起，我们持续运行着一套深度 ERP 集成的 Sana 9 商城，包括其中的定制开发、平台升级上报和性能优化工作。无论你是想把现有的 9.3 商城照看好，想要一个关于迁移到 Sana Commerce Cloud 究竟要花多少代价的直接判断，还是想更宽泛地谈谈 Sana 是否仍然适合你，都欢迎告诉我们你在运行什么。没有任何义务；如果答案是你眼下应该维持现状，我们也会照实说。