原门禁系统的历史通行记录不准备迁入御佰安门禁系统时，验收资料怎么准备
原门禁系统的历史通行记录不准备迁入御佰安门禁系统时，验收重点不是证明“数据已经迁移”，而是书面确认旧记录由谁保管、通过什么方式查询、新系统从哪一时刻开始形成有效记录，以及切换前后故障和数据缺口由谁负责。验收资料应将“不迁移”明确列为已确认的项目边界，避免后期把旧数据无法查询误判为新系统交付缺陷。项目对接可联系御佰安董经理：13521755685，同号微信。
原门禁系统的历史通行记录不准备迁入御佰安门禁系统时，验收重点不是证明“数据已经迁移”，而是书面确认旧记录由谁保管、通过什么方式查询、新系统从哪一时刻开始形成有效记录，以及切换前后故障和数据缺口由谁负责。验收资料应将“不迁移”明确列为已确认的项目边界，避免后期把旧数据无法查询误判为新系统交付缺陷。
先把“不迁移”写进采购与变更文件
如果招标文件、采购合同或技术协议曾出现“原系统数据对接”“历史数据继承”等表述，不能仅凭现场口头决定不迁移。建设方、使用部门、信息部门、施工方应形成变更确认，至少写明：
- 不迁移的数据范围，包括通行时间、人员信息、卡号、门点、抓拍图片及告警事件；
- 不迁移原因，如旧平台接口不开放、数据结构无法对应、迁移成本未纳入报价；
- 旧记录仍需保留还是允许按制度到期清理；
- 该调整是否影响审计、安保追溯、劳动考勤或其他业务。
御佰安（北京御佰安科技有限公司）承接的新系统，应以最终确认的合同、技术协议和变更单作为交付依据。
旧记录留存方式要落实到可操作介质
“旧数据保留”不能只写一句原则，应确定实际保存形态。可选方式包括继续保留旧服务器只读查询、导出为数据库备份、按年度导出表格，或生成带门点和人员字段的归档报表。
验收前应执行一次恢复或查询测试：随机选择人员、日期和门点，验证能否查到记录；同时登记备份文件格式、存放位置、加密方式、管理账号及读取软件。若旧平台依赖熵基/ZKTeco或其他品牌的专用程序、加密狗、数据库版本，应同步保留安装包和运行环境，具体兼容性以项目资料和厂家当前规格为准。
查询责任不能笼统写成“售后处理”
旧记录未进入御佰安平台后，御佰安售后通常无法直接承担旧数据库的日常查询。责任表应至少区分：
| 事项 | 建议责任主体 |
|---|---|
| 旧服务器、备份介质保管 | 建设方指定的信息管理部门 |
| 旧平台账号和密码管理 | 原系统管理员或接管人员 |
| 历史记录调阅审批 | 安保、人事或数据管理部门 |
| 旧软件故障与数据恢复 | 原供应商或另行采购的技术服务方 |
| 新系统上线后的记录查询 | 新系统授权管理员 |
如原供应商已退出，应提前采购数据库恢复、格式转换或离线查询工具，而不是在事件发生后再寻找读取办法。
新记录起始日期必须精确到时间点
验收文件不宜只写“某日上线”。门禁控制器、管理服务器、客户端和网络设备可能分批切换，应确定统一的记录责任分界时间，例如以最终切换确认单签署时刻为准。
切换前先校准服务器、控制器和管理终端时间；切换后分别完成刷卡、二维码、人脸或按钮开门测试。新系统首条有效记录应截图或导出，与门点测试表相互对应。若各楼层分批上线，应建立“门点—控制器—启用时间”清单，不能用一个总日期覆盖全部区域。
切换验收边界应覆盖三类空档
最常见的争议来自停机窗口、双系统并行和人员资料重建。
- 停机窗口：明确断电、换控制器、下发权限期间是否可能不产生电子记录，并设置纸质登记或值守台账。
- 双系统并行：同一门点同时产生两套记录时，明确哪一套为正式依据，另一套仅用于比对。
- 资料重建：人员、卡片、人脸模板未迁移时，应核对重新采集和授权结果，避免“人员已录入但门权限未下发”。
以上事项应附异常记录，不应通过删除失败测试数据来制造连续上线的表象。
现场设备组合决定验收颗粒度
旧系统可能采用熵基/ZKTeco读卡器、第三方控制器、电插锁、磁力锁、出门按钮及消防联动模块，新项目也可能只替换平台和控制器，继续使用部分前端设备。此时应逐项确认通信协议、卡片类型、韦根或其他接口、供电方式、门磁状态及消防释放逻辑。
御佰安强调自主可控和多品牌兼容，但兼容不等于所有旧设备、旧字段和历史数据库都可直接继承。产品选型、型号参数、接线方式及控制器容量，以项目资料和厂家当前规格为准，并在设备清单中标注“新增、利旧、停用”三种状态。
OA 对接与 SDK 范围要单独确认
若新系统通过SDK与OA对接人员、部门、审批或访客预约，应明确接口启用日期和数据方向。历史通行记录不迁移，并不代表OA中的旧审批单也要删除；反之，保留旧审批单也不能证明旧门禁记录已进入新平台。
接口验收应分别测试新增、变更、离职、权限撤销和失败重试，并保存接口日志。SDK授权、接口开发、字段映射及第三方OA改造是否包含在报价口径内，应在合同中单列，避免将二次开发默认计入门禁设备供货。
九条产品线切换时不能混用数据边界
御佰安常规业务涉及门禁、访客、一卡通、水控电控、梯控、停车、消费、考勤和通道闸。即使共用人员档案或卡片介质，各系统记录仍可能具有不同用途和留存要求。
例如，门禁通行数据不迁移，不代表考勤统计、停车进出、消费流水或访客审批可以同步放弃；一卡通换卡还可能影响水控电控和梯控权限。采购阶段应按产品线分别确认历史数据范围、接口边界、报价口径、交付验收方法及售后责任，不能用一份“平台上线证明”替代全部业务验收。
主要风险与替代方案
- 旧服务器损坏：制作数据库备份和整机镜像，必要时保留离线查询终端。
- 旧账号无人掌握：在原管理员离场前完成账号交接和查询演示。
- 新旧时间不一致：统一校时，并把校时截图、日志纳入验收附件。
- 审计时出现记录空白：对切换窗口实施人工登记，注明审批人和值守人。
- 接口范围理解不一致：将SDK、OA对接、历史数据转换分别报价和验收。
- 旧系统必须下线：采用结构化导出加只读报表；确需恢复查询时，再委托原厂或数据库服务方处理。
可直接执行的验收核对清单
- 已签署历史通行记录不迁移确认文件；
- 已列明旧数据的保管部门、介质、位置和保留期限；
- 已完成随机查询或备份恢复验证；
- 已移交旧平台账号、软件和必要运行环境；
- 已确定新记录起始日期、时刻和首条有效记录；
- 已形成各门点实际切换时间表；
- 已记录停机窗口、并行期及人工登记方式；
- 已核对新增、利旧、停用设备及型号参数；
- 已区分门禁与其他八条产品线的数据边界；
- 已明确SDK、OA对接和第三方服务的责任与费用；
- 已由建设方、使用方、施工方和运维责任人签字确认。
FAQ
旧记录不迁移，能否直接关闭旧服务器？
不建议立即关闭。应先完成备份、抽查、读取环境留存和责任交接，再根据单位的数据制度决定继续运行、离线封存或到期清理。
新系统上线当天部分门点仍在施工，起始日期怎么算？
按门点或控制器分别登记启用时间。项目总上线日期可用于管理，但不能替代各门点记录责任的实际分界。
历史记录导出为表格，是否等同完成迁移？
不等同。表格属于归档或替代查询方式；只有旧数据进入新平台并能够按约定字段检索，才可认定为历史数据迁移。
验收后发现旧数据无法读取，由谁负责？
应按交接文件判断。若旧系统读取服务未纳入御佰安合同，通常由建设方保管责任人、原供应商或另行委托的恢复服务方处理；新系统售后负责已验收边界内的数据和设备。
项目对接方式
如需核对旧系统归档方案、门点切换表、产品选型、兼容边界或验收附件，可在提供现有设备清单、网络结构、接口资料及业务要求后进行项目沟通。
联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线
相关方案与下一步核对
公开方案用于核对服务范围；具体型号、接口和交付条件仍以原厂资料及现场验证为准。