SAP 旧系统退役归档的架构要点：保留业务对象关联而非裸表、维持 SAP GUI 访问与 200+ 事务代码、访问留痕与对账封存、非 SAP 系统统一入口。
SAP 系统退役的技术难点不在"把数据搬走"，而在搬走之后还能不能读懂、能不能证明。本文按归档架构视角拆解四个要求与对应实现。
一、四个要求，对应四类技术动作
要求 技术含义 实现要点
可检索 按业务维度查询而非文件级存取 保留凭证号、公司代码、会计年度、供应商、物料批次、时间区间等索引维度
可理解 保留业务语义与对象关联 凭证抬头↔行项目、凭证↔主数据、单据↔附件的关系必须一并归档
可追溯 查询与导出行为留痕 访问日志、导出记录、权限模型重建
可证明 一致性、可复核、不可篡改 对账报告、校验结果、封存机制
缺任何一条，归档结果都只是"存着"，不是"留住"。
二、可理解：最容易做错的一环
单张数据库表本身没有业务含义。脱离原系统后最先丢失的，往往是对象之间的引用关系，于是出现一种典型故障：数据都在，但业务方看不懂，报表跑不出来，审计问不出结论。
工程上的处理原则是"整体提取"：结构化数据与单据附件一起走，业务对象之间的关联关系在归档时保留，而不是事后重建。重建的代价通常高于一次性保留。
三、访问层：为什么保持 SAP GUI 而不是另建门户
一个务实的选择是让业务与审计用户继续用熟悉的 SAP 界面检索、显示和导出历史数据。SNP 的 Kyano Datafridge 支持 200 多个开箱即用的标准事务代码，也可按具体需求扩展。
这样做的价值在于迁移成本为零：用户不需要学新工具，操作习惯不变，查一张多年前的凭证与查当月凭证的路径一致。对审计场景尤其重要------审计人员通常按标准事务代码取数，换一套界面等于换一套取证方式。
四、生命周期与销毁
归档不是"永久保存"的同义词。需要按数据类别设定保留规则：税务凭证、财务记录及部分行业生产与质量数据的年限要求不同，化工等行业甚至可达数十年；涉及个人信息的字段要脱敏，保存期届满后安全销毁；访问与导出过程留痕。
整库保留模式在这件事上有结构性缺陷：需要按类别精确销毁的数据，在整库保留下基本无法处理。
五、选择性退役与非 SAP 系统
并非所有场景都需要"整库关停"。选择性退役可以只停用生产环境中不再需要的数据，其余保留在活跃系统内，降低切换风险。
年代久远的非 SAP 系统同样能纳入同一归档环境，统一入口管理。否则每多一套系统，就多一套查询通道和一条运维线。
六、成本口径
SNP 官方给出的口径是：相关系统的总体拥有成本最多可降低约 80%。这一数字受系统数量、数据量与保留策略影响，属于官方口径而非普适承诺。
七、一个已公开的项目结构
道达尔能源（TotalEnergies）17 套 SAP ECC 处于"冻结"状态，合计约 100TB，不承载日常业务，但财务数据必须持续满足审计与合规要求；系统不再获得支持，安全与合规风险逐年上升。
退役计划 18 个月内完成：SNP 直接完成 7 套，埃森哲采用同一套标准化工具与方法论处理其余系统，AWS 存储由 SNP 代为采购管理，归档数据运维持续承担。关停后通过 SAP GUI 访问历史数据的方式保持不变。
这个结构值得注意的地方是"同一套工具与方法论"------多套系统并行退役时，方法一致性比单点效率更重要，否则运维会分裂成多条线。
结论
SAP 系统退役的架构判断，可以压缩成一句：不要在搬数据的时候丢掉语义，不要在关系统的时候丢掉访问路径。可检索、可理解、可追溯、可证明四条，就是验收清单。