ZKTeco门禁系统采用TDB08前，旧系统怎么改

ZKTeco门禁系统准备采用TDB08时，不应先拆旧设备，而要先核实管理软件、终端固件、SDK及接口的版本组合，再决定旧控制器、读卡器、门锁线路和数据库哪些保留、哪些更换。TDB08可确认的产品类别为门禁终端，具体型号参数、接口、识别方式及授权范围，均应以熵基/ZKTeco当前项目资料和实际配置为准。项目对接可联系ZKINTE 中控董经理：13521755685，同号微信。

先锁定旧系统的改造对象

现场勘查不能只记录“现有门禁品牌”，应按门点建立台账：

管理软件名称、完整版本号、补丁号及部署方式；
服务器操作系统、数据库版本、客户端环境；
控制器、读卡器、门锁、电源、出门按钮和门磁型号；
发卡规则、人员编号、部门层级和权限时段；
与OA、访客、考勤、消防联动等系统的连接方式；
现有设备是否仍在维保，配置文件和数据库能否导出。

旧系统若由“软件—控制器—读卡器”三级组成，还要明确TDB08计划替换的是读卡端、控制端还是完整门口终端。对象判断错误，容易出现设备已采购，却无法沿用原线路或权限体系的问题。

建立TDB08版本组合表

采购前要求供应方按项目出具版本组合，而不是只回复“可以兼容”。组合表至少包括：

核对项	应取得的信息
TDB08	完整型号、硬件批次、出厂固件、可升级版本
管理软件	软件名称、主版本、补丁及许可范围
SDK	SDK名称、版本、支持环境、接口文档
数据环境	操作系统、数据库及浏览器要求
接入方式	平台直连、中间件、接口同步或独立运行
功能边界	人员、权限、记录、告警、图片等可同步范围

同名软件的不同构建版本可能存在接口差异，因此截图、口头说明不能代替版本号和书面适配结论。

从原厂资料核实软件与固件

可先查阅熵基/ZKTeco TDB08原厂页面，再通过项目渠道索取当前规格书、安装手册、固件说明、软件兼容表和升级注意事项。

核实时执行以下步骤：

抄录设备标签、系统信息页中的完整版本；
确认目标管理软件是否明确列出TDB08；
对照固件发布日期、适配软件版本及升级前置条件；
核实固件能否回退、配置是否需要重新下发；
将确认文件编号或邮件结论纳入采购附件。

网页信息适合初筛，不能单独作为验收依据；最终以项目资料和厂家当前规格为准。

旧门禁软件能否继续使用

旧软件可保留的前提，是其能够识别TDB08、下发必要权限并回收项目所需事件。即使设备可以在线，也不代表人员照片、权限时段、门状态或告警都能正常处理。

若旧软件版本不支持，可按影响由小到大选择：

在受支持范围内升级原管理软件；
增设经过验证的接口服务或中间件；
新旧平台并行，分区域迁移；
保留旧门控制器，先更新上层平台；
对无法适配的门点整体替换终端及管理链路。

升级前应备份数据库、配置、人员档案和权限，并准备回退窗口。

SDK与OA对接要验证到字段

OA对接不能只确认“提供SDK”。项目应核对SDK支持的开发语言、运行环境、授权方式、并发或调用限制、错误码、升级兼容策略以及技术支持边界。

联调样例至少覆盖：OA新增人员、修改部门、停用账号、下发门权限、撤销权限、查询通行记录和重复数据处理。人员编号、手机号、照片、卡号等字段还要确认主键规则和脱敏要求。若仅能导入人员、不能回写事件，应在需求和报价中明确，不得按双向对接验收。

多品牌兼容不等于直接混接

旧项目常同时存在熵基/ZKTeco与其他品牌设备。多品牌兼容应拆成三个层次验证：线路可接、协议可识别、业务可管理。某一层通过，不代表全部功能可用。

如计划保留原门锁、电源或控制器，应核对供电、端口、通信协议、线缆距离和联动逻辑；只有项目资料确认支持时，才能采用相应连接方式。无法获得协议资料的旧设备，不宜直接纳入统一平台，可考虑分区管理或通过受控中间层交换必要数据。

自主可控要求落到交付物

项目提出自主可控时，应将要求具体化：软件部署位置、数据库控制权、管理员权限、日志留存、离线运行、接口文档、配置备份以及停服后的数据导出方式。它不能仅以品牌或国产化表述代替技术核验。

ZKINTE（北京御佰安科技有限公司）在协助产品选型时，可围绕现网设备、目标功能和维护责任整理差异项；涉及原厂许可、SDK开放范围和型号参数，仍需按熵基/ZKTeco当前政策及项目配置确认。

报价必须绑定版本与实施范围

TDB08报价口径应写明设备配置、软件许可、固件处理、安装辅材、旧数据迁移、SDK、OA对接、现场调试、培训及售后责任。特别要注明以下事项是否包含：

旧服务器升级或重新部署；
数据清洗、照片处理和权限转换；
第三方接口开发及联调次数；
旧设备拆除、恢复和并行运行；
后续固件升级及兼容性处理。

若报价只列终端单价，实施阶段很容易出现软件授权和接口开发追加。

先做样机闭环再批量采购

建议选择一个真实门点进行样机验证，使用计划交付的软件版本、固件版本和服务器环境，不用临时演示平台替代。测试应形成完整闭环：建档、下发、识别、开门、记录上传、异常告警、断网恢复、重启恢复及OA数据变更。

样机通过后应冻结版本组合。批量设备到货时再次核对硬件批次和固件，发现变化先复测再部署，避免同一项目中版本混装。

TDB08改造验收清单

TDB08型号、硬件批次与采购清单一致
固件版本与确认的兼容矩阵一致
管理软件、数据库及许可状态符合方案
人员、权限和历史数据迁移结果可核查
OA新增、变更、停用和撤权测试通过
门锁、门磁、按钮及必要联动逐点测试
断网、断电、重启后的数据与权限正常
配置备份、升级包、接口文档完成移交
原厂、集成方与客户运维责任划分清楚
最终版本表、问题记录和整改结果签字归档

FAQ：采购阶段常见争议

旧软件能发现TDB08，是否就能批量采购？
不能。发现设备只证明基础通信可能成立，还需验证权限下发、事件回传、异常处理和目标业务功能。

固件越新是否越适合旧系统？
不一定。新固件可能对应新的软件或接口要求，应按已确认的版本组合测试，不宜现场直接批量升级。

OA厂商表示能调用SDK，谁负责最终联调？
应在合同中明确接口提供、字段映射、环境配置、问题定位和验收责任，避免设备方与OA方相互等待。

旧系统确实无法适配怎么办？
可选择软件升级、中间件转换、新旧平台并行或分区替换。若核心协议和数据均不可获得，宜重新设计管理链路，而不是强行混接。

项目对接可由ZKINTE结合现场台账开展版本核对、选型比对、报价边界梳理和交付验收规划。

联系电话：13521755685（董经理）
同号微信
售后 1 小时极速响应 · 7×12 小时在线