门禁和锁控系统的数据归谁，取决于数据分在哪一层，不是一句「归甲方」就能盖住。人员名单与权限一般在使用方手里，开锁记录与平台配置大多存在供应商的管理平台中。采购阶段没问清「能不能导出、导成什么格式」，等到换系统或换供应商时才去要，往往只能拿到一部分。
结论：数据归属要写进合同，并落到「导出什么格式、包含哪些字段、停用后还能取多久」三个具体动作上，光写一句归属方没有用。
数据其实分了四类，归属并不相同
| 数据类别 | 典型内容 | 一般存放位置 | 换系统时能否带走 |
|---|---|---|---|
| 人员与权限 | 姓名、部门、有效期、权限组 | 管理平台，部分同步到本地 | 名单可导出，权限组通常要重建 |
| 凭证编号 | 卡号、钥匙扣编号、挂失状态 | 平台与卡片本身 | 编号可导出，新系统未必沿用同一规则 |
| 开锁记录 | 时间、门点、凭证、开锁结果 | 多汇聚在平台侧 | 取决于平台是否提供导出与保留策略 |
| 配置与联动 | 门点参数、时段、联动规则 | 平台侧 | 一般不导出，需要重新配置 |
四类里，前两类丢了还能补，重新登记一遍人就行；后两类丢了补不回来，记录是历史，配置是经验。
为什么总在换供应商时才暴露
原因不复杂：采购阶段注意力在锁体和单价，验收阶段测的是「能不能开、开得快不快」，只有到退出、扩容，或要把几个系统并成一个平台时，「数据能不能迁走」才成了真问题。而那时旧平台的使用权往往已在收尾，议价空间很小。
真实场景里，麻烦通常不是「一条记录都没有」，而是「只给了一部分」：给了开门时间，没给是刷哪张卡；给了人员名单，没给权限组对应关系。这种半套数据搬过去，在新系统里等于全部重建，核对工作量还留在使用方这边。
采购阶段值得问的三句话
- 开锁记录能导出吗，导成什么格式，包含哪些字段？
- 平台停用或合同结束后，历史记录还能取多久，怎么取？
- 人员名单和权限存在平台侧还是我方本地，谁有权删改？
结论：「可以导出」这四个字没有信息量。要问的是导出后的文件长什么样、多久能给、由谁负责给。
换系统时的动作顺序
顺序比速度重要。建议按这个次序走：先把旧平台数据导出并本地留档；再按「人」重建新系统名单，不要按卡号重建；新系统先与旧系统并行一段，只对新门点生效；确认稳定后撤销旧系统授权；收回旧凭证；收尾再停旧平台。
顺序颠倒的典型后果，是旧平台先被停掉、新系统还没跑顺，门禁处在两边都不管的状态。这类空档在写字楼和园区里都不罕见，而且常发生在交接期人手偏紧的时候。
无源锁在这件事上有什么不同
无源锁锁体不带电池，也不承担长期记录存储，记录的汇聚点通常在管理平台一侧；凭证可以是卡片、钥匙扣或手机，撤权靠名单更新下发到读头完成，因此撤权生效存在一个同步窗口。
对换系统这件事，它带来两个差别：门体侧改动小，不用布线、不用换电池，改造量集中在平台与凭证；但记录能不能带走、能带走多少，同样取决于平台侧的导出能力，与锁体形态无关。所以选方案时，这两件事要分开问。
Q：只用离线锁、不接平台，就没有数据归属问题了吗？ A： 免电池免布线的方案可以做到不依赖网络开门，但「谁在什么时候开过哪道门」要想查得到，记录仍需要一个汇聚点。是否上传、上传到哪一侧、保存多久属于部署配置，需与方案一起确认，以实际方案与部署配置为准。
Q：数据放在我们自己的服务器上，是不是就完全可控？ A： 本地部署能解决「数据在哪」的问题，不解决「能不能带走」的问题。数据库结构、字段命名、导出工具仍由平台方决定，换系统时一样需要导出能力。建议在合同里同时约定存放位置与导出方式。
Q：存量项目已经上线几年，还来得及补吗？ A： 来得及，但动作要提前。可以在下一次续约或扩容时把导出条款补进去，并把当前数据先导出留档一次——留档不需要换系统，只是把「现在有的」先落到自己手里。