Sana 停下之后，9.3 的支持由谁来接。

Sana 对 9.3.0 至 9.3.4 的支持在 2024 年年底结束，对 9.3.5 的支持在 2025 年年底结束。两个日期都已过去，期间用于过渡的延长支持安排也已到期。

这些都不会关掉任何东西。没有许可证到期，没有开关被触发，上周的商城今天还是那套商城。不少 Sana 9 商城至今仍在稳定创收，而且还能再跑很多年。

结束的是商城背后那张安全网：安全补丁、平台缺陷修复、升级上报的通道，以及那项默默进行的兼容性工作，正是它让一套五年前的 ERP 集成在浏览器、支付服务商和你自己的 ERP 不断变化时继续跑下去。

留下是一个正当的决定。但只有当有人把这张安全网接过去时，它才正当。越过生命周期终止后无人担此职责地继续运行，与其说是决定，不如说是在赌不会出事。这个赌局你大多数月份都会赢。输的那个月，你会输在订单流程里，而且没有厂商可以求助。

大多数被报成「Sana 的问题」的事，最后都不是。它们出在底层技术栈、某处定制、ERP 的一次变更，或者干脆是公司之外的因素。把这些迅速分开，就已经是这份工作的大半；而这恰恰是没在这套代码里待过的人做不好的部分。

当问题确实出在平台时，处理是分层推进的：

• 在我们能控制流量的地方先把它挡住。防火墙规则、边缘与反向代理策略、响应头、应用配置，以及关闭你并未使用的暴露面。相当可观的一部分平台层风险，在这里就能收口，完全不必改动应用本身。
• 把平台所依赖的一切都打上补丁。在一套典型的 9.3 安装中，这已是绝大部分暴露面，而微软对其中几乎全部仍在提供支持。
• 让问题先被我们知道。持续跟踪平台及其依赖的安全公告，让消息经由我们传到你这里，而不是来自客户或审计方。
• 把真实的选项摆给你。包括那些诚实答案是「继续推迟迁移，现在已经是更贵的选择」的情形。

最后这一条，是我们自己作为买方时最想读到的。一家商业利益在于「你永远别走」的维护商，显然有不提这件事的动机；我们宁愿做那个早点开口的人。

「我们在一个没有支持的平台上」通常被当成一个不可分割的整体问题。其实不是。一套 Sana 9.3 安装，是运行在 .NET Framework 上的 ASP.NET MVC 应用，由 IIS 以经典管道模式提供服务，跑在 Windows Server 上。Sana 只是这个技术栈中的一个组件，其余大部分微软仍在支持。

实际上，一套疏于照料的 9.3 商城，真正可修复的风险往往在这些地方：

• .NET Framework 版本。Sana 9 的安装常见于 .NET Framework 4.6.x，而微软已于 2022 年 4 月停止对其支持。升到 4.8 通常并不复杂，仍受完整支持，并且确实堵上了一个真实缺口。它也往往要等到有人来审计时才被发现。
• 操作系统。Windows Server 2012 R2 已于 2023 年 10 月退出支持。相当数量的长期运行的 B2B 商城仍停在上面。
• TLS 与加密套件配置。从 2019 年那次部署沿用至今的旧协议版本与旧加密套件，既通不过现代安全扫描，也越来越多地导致支付集成失败。
• 应用周边的依赖。你自己定制代码里引用的各类库，本来就该由你更新，但一直没人更新。

一个有用的重新表述：一套无人维护的 Sana 9.3 商城，并不是「一件没有支持的东西」。它是一个没有支持的组件，压在一个往往已经落后数年、而那些补丁本来谁都没被拦着不让打的技术栈之上。把这部分补齐，就消化掉了大部分风险，而且这项工作可以立刻开始。

对于跑在冻结平台上的商城，收益最高的一件事，就是别再指望应用自己保护自己。在它前面放一层现代边缘，威胁模型中的很大一部分根本到不了你的代码。

• Web 应用防火墙。由别人持续维护的托管规则集，替你吸收每一家公开商城都在不停承受的通用扫描与注入流量，而它挡在一套不再更新的应用前面。
• 机器人与滥用治理。针对 B2B 登录的撞库、对客户专属价格的抓取，以及对结账流程的试探，这三件才是 B2B 真正要紧的。三者在边缘缓解都很便宜，在老应用内部处理则都很贵。
• 对昂贵路径做限流。搜索、价格查询，以及任何会一路打到 ERP 的请求。这对 ERP 的保护不亚于对商城本身。
• 无论源站如何，先提供当前的 TLS。在边缘终结现代协议与加密套件，意味着安全扫描或支付服务商看到的是一份当前配置，哪怕源站还在逐步跟上。
• 缓存与可用性。把静态与半静态内容放到边缘提供，既减轻了你并不想去扩容的源站负载，也能在源站发生故障时让页面上还有东西可看。

这些都不需要动 Sana。它是一套 9.3 商城能拿到的、性价比最高的实质性安全改进，而且通常以天为单位交付，而不是以月。

你的买家根本不知道你在哪个版本上。他们只知道这个站看起来是不是当下的、在手机上能不能用、以及能不能找到自己要的那个件。一套 2019 年做的主题，通常这三样全输，而其中没有一样是平台的限制。

这正是我们真正的手艺。在 Sana 支持的主题模型之内做，而不是绕过它，一套 9.3 商城依然可以拿到：

• 一次视觉焕新。字体、间距、色彩与图像全部更新到当下，而不改动任何一条业务规则。
• 真正好用的移动端。很多 Sana 9 商城在技术上是响应式的，实际用起来在手机上很难受；而随着买家越来越多地在仓库现场而不是办公桌前补单，这一点每年都更重要。
• 更快的页面。图片格式、体积克制与缓存，通常能带来比人们对老技术栈预期更大的实测提升。
• 无障碍改造。语义化标记、对比度、键盘导航与标签。在 B2B 的部分领域这已成为采购硬性要求，也是被悄悄淘汰、却从来不会被告知原因的常见理由。
• 在真正创收的路径上做转化优化。搜索、商品详情、重复下单与结账。

现在就做而不是留到重建时再做，还有一个战略理由：设计与内容恰恰是能带走的那部分。结构、需求和一套设计体系迁移到新平台，比代码容易得多。

过去两年里发生了一个变化，而多数 B2B 商城还没有回应它：买家调研中有相当一部分，如今发生在 AI 助手里，而不是搜索结果页上；让一份商品目录对助手「可读」的东西，和 2019 年让它排上去的东西并不相同。

好在这基本上是内容与标记层面的问题，因此一套 9.3 商城完全可以在不更换平台的前提下补到当下水准：

• 覆盖整个目录的结构化数据。商品、报价、价格、库存状态与各类标识符，全部在服务端渲染。它既支撑富媒体结果和比价引擎，也越来越多地成为助手判断「能不能回答关于你产品的问题」时所读取的依据。
• 真正能被读取的商品内容。规格参数用真实标记呈现，而不是一张表格的图片，让爬虫和模型都能解析。
• 明确的机器可读摘要。用助手可以直接消费的形式，讲清楚你是谁、卖什么、卖给谁。
• 那些会悄悄退化的技术基础。上线时本来正确、却在多年目录变更中逐渐跑偏的规范链接、站点地图与跳转，以及被大量消耗在没人想收录的筛选参数 URL 上的抓取预算。
• 一份由你自己决定的 AI 爬虫策略。主动决定哪些助手可以读取你的目录，而不是交给一个从没人设定过的默认值。

能否被助手引用，取决于表达是否清晰、结构是否规整，远多于取决于域名权重；这让它成为少数几个中型分销商有机会赢过体量大得多的竞争对手的渠道。而且这项工作在更换平台之后依然完好保留。

不是审计过一套，也不是实施完就走人。我们持续运营着一套深度定制、带真实 ERP 集成的 Sana 9 商城，年复一年：经历过平台升级上报、集成意外、性能优化，以及那些永远进不了案例集的、普通星期二的故障。

这一点在维护场景里，比在新建项目里更重要。维护是一门「认得出来」的生意。知道某个症状意味着 ERP 改了字段长度，或者某次结账失败是支付服务商换了要求、而不是你的代码坏了，这不是能从文档里读到的东西。

ProjectThunder 是 Sana 认证的网页代理机构，而不是 ERP VAR。我们从 2004 年开始做电商。如果你另有 ERP 合作伙伴，我们与其并肩协作，而不是取而代之。

没有人能对一套自己没看过的商城报出维护价格；任何这么做的供应商，都是在猜你的定制内容。我们先把四件事弄清楚：

1. 你到底在哪个版本上。9.3.0 至 9.3.4 比 9.3.5 早整整一年到达生命周期终止，这会改变事情的紧急程度。
2. 做过哪些定制，以及为什么。把插件、模块、视图覆盖和前端改动逐一清点，包括埋在其中、却从没人写下来的业务规则。
3. 技术栈的状态。操作系统、.NET Framework 版本、IIS 与 TLS 配置、证书处理，以及各自落后了多少。
4. ERP 集成的健康度。商城依赖的那六项契约，以及是否已经有哪一项在悄悄失败、而由某个人手工在兜着。

这会形成一份关于「你实际拥有什么」的书面画像。范围与条款由此推导。如果评估结论是你需要的比预期更少，我们也会照实说。

维护的目的不是让你永远留在 9.3，而是把时间的主动权还给你：让迁移到 Sana Commerce Cloud 发生在你自己选定并做过预算的时间点，而不是某次事故之后的慌乱之中。

等那一刻到来，值得先弄清楚你买的是什么。Sana Commerce Cloud 是另一个产品，而不是你手上这套的版本 10，几乎没有任何东西能自动带走。我们把这件事完整写过一遍，包括哪些确实能带走，以及 AI 究竟在哪里真正降低成本：Sana 9.3 已过生命周期终止：这意味着什么，取决于谁在维护它。

在此期间把商城维护好，也保护了将来重建时最要紧的东西。被维护的商城，会保住一个熟悉你业务规则的人；被搁置的商城，则把这些规则重新变回考古工作。