一句话定义

零迁移纳管，指企业不更换现有的传输服务器与对象存储，也不要求外部合作伙伴改变访问方式，只把这些存储资源的访问凭据收口到平台，由平台代为访问，从而在原有端点继续工作的前提下叠加统一的权限、审核与审计。

一、真正卡住项目的不是技术，是"先换掉什么"

对外交换乱不乱，多数企业心里有数：账号散在人手上、取送靠专人、记录说不清。难的是下一步——要动的是正在跑的业务。

选型会上最常出现的三句话：

• "现有的 FTP 服务器上跑着十几家伙伴的对接，停一天都不行。"
• "对象存储里的数据几十 TB，迁一次要多久、迁完对不对，谁来担这个责？"
• "改地址要通知每一家合作伙伴，他们凭什么配合我们做这件事？"

这三句话背后是同一个判断：改造的风险由本方承担，而收益要等到全部切换完成之后才兑现。 只要这个结构不变，项目就会一直排在"明年再说"。

二、为什么"先迁移再上线"很难推动

把现状迁到新平台，通常意味着四件事要同时成立：

前置条件	为什么难
数据要从原存储搬到新平台	体量大、窗口紧，搬完还要逐一核对完整性
每一家伙伴要改服务器地址与账号	对端是外部企业，改配置要走他们的流程，本方推不动
新旧两套要并行一段时间	并行期间两边都可能被写入，对账成本高
切换需要各方在同一时间点配合	只要有一家没跟上，就得整体回退

其中第二条是最硬的。企业间交换的实际约束往往不在本方，而在对端。 一家几个人的小供应商，没有 IT 部门，让他们改一次配置的沟通成本可能超过这次改造在本方的全部工作量。

结论不是"不要改造"，而是：改造的第一步不应该落在对端身上。

三、零迁移的三层含义

产品把第一步收窄到只做一件事——接管凭据。具体是三层：

层次	含义
数据不迁移，位置不变	既有的 FTP/FTPS/SFTP 服务器、SMB 共享、对象存储原位保留，文件仍存在原来的地方
对端不改配置	外部合作伙伴照旧访问原来的地址，使用方式不变，不需要被通知、不需要配合
只把访问凭据收口到平台	这些存储的账号、密钥与访问密钥交由平台保管，由平台代为访问

第三层是整件事的支点。凭据收口之后，平台成为访问这些存储的统一入口，于是权限、审核、安全处理与审计就有了施加的位置——而这一切不需要移动任何一个文件。

可纳管的存储类型包括：FTP/FTPS/SFTP、SMB、Amazon S3（全球区域 / 中国区域）、阿里云 OSS、七牛云、深信服存储对象，以及兼容 S3 协议的存储服务。

→ 各类存储的纳管方式与配置要点见 第三方存储资源纳管

四、纳管之后，多出来的是什么

存储没变、数据没动、对端没感觉，那企业拿到了什么？

五、边界声明：零迁移不解决什么

把话说在前面，比上线后再发现要好。

• 纳管不改变各存储后端自身的特性。 平台通过标准协议或接口访问这些存储，各类后端在大文件处理与断点续传等方面的实际表现存在差异，建议在项目评估阶段按实际环境验证。
• 零迁移不等于永远不迁移。 如果现有存储本身已到容量或运维寿命的边界，该换还是要换——只是这件事可以与平台上线解耦，各自按各自的节奏走。
• 产品不解析 EDI 报文，不做格式映射与业务对账。 交换内容如果是订单、发货单这类结构化报文并需要业务级处理，那部分由 EDI 系统承担，产品作为其下的文件传输与安全治理层。→ 文件交换与 EDI 是什么关系
• 产品不包含通用的工作流编排与任务调度引擎。 审核流程是文件交换的内置环节，不是通用流程引擎；作业编排由企业既有的调度平台承担，产品通过 OpenAPI、事件订阅与异步回调与其协同。这是主动划定的边界。→ 与既有业务系统协同
• DLP 能力作用于经过平台的文件，不覆盖终端与其他外发渠道。 它管不到员工用 U 盘拷走的文件。
• 产品不是 SRM，不做寻源、招投标与订单协同。

六、落地路径：四个阶段，第一阶段不动现状

产品支持渐进式落地，不要求一次性改变企业现有的交换方式。

阶段	内容
第一阶段 · 纳管	不改变现有端点，将既有 FTP/SFTP/对象存储纳管为伙伴库目录；外部凭据收口到平台；叠加权限、审核与审计
第二阶段 · 规则化	按伙伴与方向配置收发策略，把人工取送动作转为规则驱动
第三阶段 · 自动化	对稳定的、周期性的交换启用系统对系统模式——OFTP2 协议对接、PGP 对等加密。这两项均为可选组件，需按需选配
第四阶段 · 集成	通过 OpenAPI 与事件机制接入 PLM、ERP 等业务系统

第一阶段不涉及数据迁移，对端合作伙伴无感知。

更重要的是下面这条：各阶段都不要求停用原有方式。可以先让平台接管一条新增的或风险较高的业务流，原路径保留作为回退，验证稳定后再停止人工操作与旧脚本。

这句话决定了这件事的风险结构——不是"切换成功才有收益"，而是"接管一条流就先拿到这条流的管控与记录"，而且随时可以退回去。

七、什么样的现状最适合从纳管开始

不是所有情况都需要走完四个阶段。下面几种现状，第一阶段的收益最直接：

现状	纳管后先解决的问题
伙伴发放的 FTP 账号记在几个对接人手里，谁手上有几份说不清	凭据收口，人员变动时在一处轮换
有专人每天登录若干个外部系统取放文件	取送动作可逐步转为按策略执行
现有对象存储上跑着对外交付，但没有审批、也没有内容检查	经平台收发的文件强制走安全处理
被客户或审计追问某批文件的收发过程时只能翻邮件	交换记录集中留存，可查询可导出
现有 FTP 服务器还在维保期内，短期不打算换	不需要换，纳管即可

如果你不确定自己属于哪一种，可以从现状梳理开始——针对现有对外交换方式出具梳理结论与改进建议，不以采购为前提。梳理的结果通常就是一句话：你们有多少个外部账号，散在多少个人手里。

八、与相邻做法的关系

零迁移是落地方式，不是交换能力本身。以下四页回答的是"现在这么做行不行"：

• 已经有企业网盘，两者是什么关系 → 企业网盘与企业间文件交换的区别
• 直接把 FTP 账号给业务人员，风险在哪里 → 直接把 FTP 账号给业务，风险在哪里
• 邮件与即时通讯外发的边界在哪里 → 邮件与即时通讯外发文件的边界
• 自研脚本加对象存储，长期成本是什么 → 自研脚本 + 对象存储的长期成本

以伙伴为组织单元的完整模型见 → 合作伙伴文件安全交换
凭据托管的安全设计与评审配合见 → 外部凭据托管的安全设计与评审配合
制造业的典型交换结构见 → 汽车与零部件行业文件安全交换 · 集成电路与半导体的内外部文件交换

常见问题