Cambiar un reloj checador antiguo no debería comenzar con la compra de un equipo nuevo. Para una empresa mexicana, la migración funciona mejor cuando primero se protege la información existente, se documentan horarios y reglas, se valida la compatibilidad del nuevo ecosistema y se planea la transición sin interrumpir el registro diario. Esta guía explica cómo hacerlo por etapas, qué conservar y qué revisar antes de elegir hardware o software.

¿Cuándo deja de ser suficiente un reloj checador antiguo?

La antigüedad por sí sola no obliga a sustituir un dispositivo. Un equipo puede seguir siendo útil si registra correctamente, permite recuperar la información necesaria y encaja con el proceso actual. La señal de cambio aparece cuando el sistema completo empieza a generar fricción: reportes manuales difíciles de consolidar, software sin soporte, incompatibilidad con equipos nuevos, dependencia de una sola computadora, dificultad para administrar varias sedes o falta de trazabilidad sobre correcciones e incidencias.

También conviene revisar la continuidad operativa. Si la empresa depende de un programa que ya no puede instalarse en equipos actuales, de un puerto de comunicación obsoleto o de procedimientos que solo conoce una persona, el riesgo no está únicamente en el reloj: está en la dependencia creada alrededor de él.

Antes de decidir, separa tres preguntas: ¿el dispositivo todavía registra de forma confiable?, ¿el software todavía permite administrar y recuperar la información?, ¿la arquitectura actual puede acompañar el crecimiento de la empresa? Si una o varias respuestas son negativas, la migración puede justificarse por operación y continuidad, no por moda tecnológica.

Reloj antiguo frente a sistema moderno: qué cambia realmente

Aspecto	Enfoque tradicional	Sistema moderno	Qué validar
Administración	Frecuentemente local y ligada a una PC o proceso específico.	Puede centralizar dispositivos, usuarios, horarios e incidencias.	Arquitectura, licencias, roles y acceso administrativo.
Obtención de registros	Descarga manual, USB o comunicación puntual.	Sincronización por red o plataforma, según solución.	Protocolo, conectividad, contingencia y frecuencia.
Escalabilidad	Agregar sedes o equipos puede aumentar tareas manuales.	Puede facilitar administración de múltiples dispositivos o ubicaciones.	Límites de licencia, capacidad e infraestructura.
Trazabilidad	Puede depender de archivos y procedimientos manuales.	Puede concentrar registros, incidencias y reportes.	Historial, permisos, respaldos y auditoría.
Integración	Exportaciones o procesos aislados.	Puede ofrecer archivos, API u otros mecanismos.	Compatibilidad real; una API no equivale a integración terminada.

 

«Moderno» no significa necesariamente «en la nube» ni «biométrico». Un sistema actual puede ser local, web, híbrido o en la nube. Lo importante es que responda al proceso de la empresa, pueda mantenerse y permita recuperar información con controles adecuados.

Paso 1: Haz un inventario antes de desconectar nada

El error más costoso de una migración es descubrir después que el sistema anterior contenía información que nadie respaldó. Antes de retirar equipos, documenta qué existe y quién lo usa.

• Modelo y variante exacta de cada reloj checador.
• Cantidad de usuarios enrolados y método de identificación utilizado.
• Software, versión y computadora o servidor donde opera.
• Forma de comunicación: red, USB, Wi-Fi u otro mecanismo disponible.
• Horarios, turnos, calendarios, tolerancias y reglas configuradas.
• Reportes utilizados por Recursos Humanos y frecuencia de generación.
• Archivos históricos y periodos que deben conservarse.
• Integraciones, exportaciones o plantillas utilizadas para nómina.
• Personas con acceso administrativo y responsables del proceso.

No des por hecho que una base de datos antigua podrá importarse directamente a una plataforma nueva. El formato, los identificadores, las plantillas biométricas y la estructura de datos pueden variar. La posibilidad de migrar usuarios, registros o configuraciones debe confirmarse específicamente para el sistema de origen y el de destino.

Paso 2: Respalda registros y define qué información sí debe migrarse

Migrar no significa copiar todo. Conviene separar información histórica que debe conservarse, información operativa que necesita continuar en el nuevo sistema y datos que pueden archivarse fuera de la plataforma nueva.

Información	¿Migrar, archivar o recrear?	Qué revisar antes
Empleados activos	Normalmente migrar o dar de alta de forma controlada.	Identificador único, estatus, departamento y duplicados.
Marcajes históricos	Pueden archivarse o importarse si existe compatibilidad.	Formato, integridad, periodo y necesidad de consulta.
Horarios y turnos	A menudo conviene recrearlos y validarlos.	Reglas vigentes, turnos nocturnos, descansos y tolerancias.
Biometría	No asumir que es transferible entre plataformas o modelos.	Compatibilidad técnica, finalidad, privacidad y reenrolamiento.
Reportes cerrados	Conservar como evidencia administrativa cuando corresponda.	Ubicación, acceso, respaldo y política de conservación.
Incidencias pendientes	Revisar antes del corte.	Autorizaciones y responsable de cierre.

 

Una práctica prudente es generar respaldos verificables antes del cambio y conservar temporalmente el entorno anterior en modo de consulta, si técnicamente es posible y la política de la organización lo permite. El objetivo es evitar que el nuevo sistema se convierta en la única vía para consultar información que todavía no ha sido validada.

Paso 3: Limpia la información antes de llevarla al nuevo sistema

Una migración es una oportunidad para evitar trasladar problemas acumulados. Antes de importar empleados, identifica duplicados, usuarios dados de baja, departamentos que ya no existen, identificadores inconsistentes y horarios obsoletos. Si el sistema anterior utiliza un número de empleado diferente al de Recursos Humanos o al de nómina, define cuál será el identificador maestro.

La limpieza también debe incluir permisos. No todos los usuarios administrativos del sistema anterior necesitan conservar el mismo acceso. Define perfiles para Recursos Humanos, supervisores, TI u otras áreas y aplica el principio de acceso necesario para cada función.

Paso 4: Define primero el proceso y después la tecnología

Antes de comparar modelos, documenta cómo debería funcionar el proceso futuro. ¿Cuántas personas registrarán asistencia? ¿Cuántas ubicaciones existen? ¿Hay turnos nocturnos o rotativos? ¿Se necesita consultar información desde varias oficinas? ¿Qué incidencias revisa Recursos Humanos? ¿La nómina recibe archivos o existe un proyecto de integración? ¿Qué debe ocurrir si una sede pierde conectividad?

Estas respuestas permiten decidir si la empresa necesita un equipo autónomo, una plataforma centralizada, una solución local, una solución en la nube o una arquitectura distinta. El número de empleados ayuda a dimensionar, pero no debe utilizarse como único criterio.

Paso 5: Elige el método de identificación sin convertirlo en la única decisión

Método	Puede ser útil cuando…	Ventaja operativa	Qué validar
Huella	El entorno favorece lecturas consistentes y se busca vincular el registro con la persona.	No depende de portar una tarjeta.	Condiciones de manos, flujo, privacidad y compatibilidad.
Rostro	Se busca registro sin contacto y flujo ágil.	Experiencia de identificación rápida en condiciones adecuadas.	Iluminación, ubicación, privacidad y condiciones de instalación.
RFID	Se prefiere una credencial física y evitar biometría.	El alta y la sustitución de credenciales pueden ser sencillas.	Préstamo, pérdida, reposición y administración.
Multimodal	Existen perfiles o escenarios distintos.	Permite combinar métodos según necesidades.	Métodos exactos del modelo y reglas de uso.

 

Si la empresa ya utiliza biometría, no debe suponerse que las plantillas del reloj anterior podrán transferirse. En muchos proyectos puede ser necesario reenrolar usuarios. Esto debe incluirse en el calendario y en la comunicación interna para evitar que el primer día de operación se convierta en una fila de altas pendientes.

Paso 6: Valida compatibilidad entre reloj, software y arquitectura

El nuevo reloj no debe evaluarse de forma aislada. Confirma qué software lo administra, qué protocolo utiliza, cómo se comunica, qué funciones están disponibles en la versión que se contratará y qué infraestructura necesita. En ZKTeco, por ejemplo, la documentación vigente del SpeedFace-V5L identifica ADMS y los protocolos AC Push/TA Push, y señala distintas compatibilidades de software según el despliegue: ZKBio Time para asistencia local y ZKBio Zlink para escenarios en la nube, entre otras opciones documentadas (ZKTeco, 2026a).

La propia base de soporte de ZKTeco documenta el procedimiento para conectar SpeedFace-V5L con ZKBio Time 9.0 mediante el tipo de dispositivo Att Push y la configuración del servidor ADMS; esto ilustra por qué el modelo, el firmware, el protocolo y la versión del software deben validarse en conjunto, no por separado (ZKTeco, s. f.-a).

Si existe un sistema de nómina, ERP o Recursos Humanos, confirma el mecanismo de intercambio. Una exportación compatible puede ser suficiente para algunos procesos; otros requieren API o desarrollo. No asumas que «tiene API» significa «ya se integra con mi nómina».

Paso 7: Diseña una migración por etapas

Cuando la operación lo permita, evita un cambio de un día para otro sin pruebas. Una transición controlada puede dividirse en preparación, piloto, operación paralela y corte definitivo.

Etapa	Objetivo	Validación mínima
1. Preparación	Respaldar, limpiar datos y configurar el nuevo entorno.	Usuarios, horarios, dispositivos, red, permisos y reportes.
2. Piloto	Probar con un grupo, sede o turno controlado.	Marcajes, incidencias, sincronización y reportes.
3. Paralelo	Comparar temporalmente los resultados del sistema anterior y del nuevo.	Diferencias explicadas y procedimiento de contingencia.
4. Corte	Adoptar el nuevo sistema como operación principal.	Responsables, soporte, respaldos y comunicación.
5. Cierre	Retirar o archivar el sistema anterior de forma controlada.	Información histórica accesible y credenciales administrativas gestionadas.

 

El periodo paralelo no necesita ser indefinido. Debe tener un objetivo y criterios de salida: por ejemplo, comprobar que los empleados activos están correctamente asociados, que los horarios producen las incidencias esperadas y que los reportes utilizados por Recursos Humanos pueden generarse de forma consistente.

Paso 8: Protege los datos personales durante la transición

Un proyecto de asistencia puede tratar nombres, identificadores laborales, horarios y, dependiendo del método, datos derivados de características biométricas. La Ley Federal de Protección de Datos Personales en Posesión de los Particulares establece obligaciones para el tratamiento de datos personales por particulares, por lo que la migración debe considerar finalidad, aviso de privacidad, acceso, seguridad y conservación, entre otros aspectos aplicables (Cámara de Diputados del H. Congreso de la Unión, 2025).

En la práctica, esto significa evitar copias innecesarias de bases de datos, controlar quién recibe respaldos, proteger los archivos de migración y definir qué ocurrirá con la información del sistema retirado. Si se cambia el método de identificación o se realiza un nuevo enrolamiento biométrico, conviene revisar específicamente el tratamiento previsto antes de desplegarlo.

Esta información es de carácter informativo y no sustituye asesoría jurídica, fiscal o especializada para un caso concreto.

¿Qué solución ZKTeco puede evaluarse al modernizar asistencia?

ZKBio Time

ZKTeco mantiene ZKBio Time como una plataforma de tiempo y asistencia y, en septiembre de 2026, publicó documentación de ZKBio Time 9.0 en su centro oficial de descargas (ZKTeco, 2026b). Puede evaluarse cuando la empresa busca centralizar dispositivos compatibles y administrar asistencia desde una plataforma. Antes de migrar, deben confirmarse edición, licenciamiento, dispositivos soportados, infraestructura y ruta de importación o alta de datos.

SpeedFace-V5L

SpeedFace-V5L puede evaluarse cuando el proyecto requiere un terminal con métodos de identificación y comunicación compatibles con la arquitectura seleccionada. La ficha oficial vigente documenta TCP/IP, ADMS, TA Push y soporte de ZKBio Time en despliegues locales (on-premise); también documenta ZKBio Zlink como software en la nube compatible (ZKTeco, 2026a). La variante exacta y las funciones necesarias deben verificarse antes de comprar.

ZKBio Zlink y escenarios en la nube

Si el objetivo es evolucionar hacia una administración en la nube, debe revisarse qué dispositivos y funciones admite la plataforma elegida. ZKTeco documenta actualmente ZKBio Zlink en soluciones de asistencia y casos de administración centralizada, pero la conveniencia depende de la conectividad, las funciones requeridas, el licenciamiento y la compatibilidad del parque de equipos (ZKTeco, 2026c).

Si ya tienes relojes ZKTeco y estás considerando modernizar la plataforma, el primer paso comercial útil es revisar los modelos y versiones existentes antes de cotizar reemplazos.

Qué buscar según el tamaño y la operación de la empresa

Microempresa

Puede ser suficiente un esquema sencillo con un punto de registro, reportes claros y administración básica. Antes de migrar, conviene priorizar facilidad de uso, respaldo de información y una ruta de crecimiento razonable.

Pequeña empresa

A medida que la empresa incorpora más empleados, turnos o responsables, adquieren más importancia la administración centralizada, los horarios, las incidencias y la posibilidad de conectar equipos a software de asistencia.

Empresa mediana

Conviene analizar múltiples dispositivos, departamentos, autorizaciones, perfiles administrativos, integración con otros procesos y mecanismos de respaldo. Un piloto previo al corte cobra mayor valor.

Empresa grande o multisucursal

La decisión debe centrarse en arquitectura, disponibilidad, conectividad entre sedes, volumen de transacciones, roles, seguridad, escalabilidad e integraciones. En este nivel, cambiar terminales sin diseñar primero la plataforma puede trasladar los problemas existentes a equipos más nuevos.

Errores comunes al migrar un reloj checador

1. Desconectar el sistema anterior antes de generar respaldos. Puede dejar registros históricos o configuraciones inaccesibles. Genera respaldos y comprueba que pueden consultarse.
2. Comprar el nuevo reloj antes de validar el software. El método de identificación no garantiza compatibilidad con la plataforma que la empresa necesita.
3. Asumir que toda la biometría se puede importar. La compatibilidad de plantillas depende de la tecnología, el modelo y la plataforma; contempla reenrolamiento si es necesario.
4. Copiar datos sin limpiarlos. Los duplicados y usuarios obsoletos también migran. Depura primero.
5. Cambiar todo el mismo día sin piloto. Los errores de horarios, red o permisos aparecen en producción. Prueba con un alcance controlado.
6. No definir contingencia. La empresa debe saber cómo registrar y recuperar información si fallan la red, el servidor o la plataforma.
7. Confundir modernización con nube. Una solución en la nube puede ser adecuada en ciertos escenarios, pero una solución local o híbrida puede responder mejor a otros.
8. No involucrar a Recursos Humanos y TI. La migración combina reglas de asistencia, datos, red, seguridad y operación; requiere responsables claros.

Lista de verificación antes del corte definitivo

• Respaldo del sistema anterior generado y verificado.
• Lista de empleados activos depurada.
• Identificadores únicos validados.
• Horarios, turnos y calendarios configurados y probados.
• Dispositivos comunicando con la plataforma correcta.
• Métodos de identificación enrolados y probados.
• Perfiles y permisos administrativos revisados.
• Reportes de RR. HH. validados.
• Proceso de incidencias documentado.
• Contingencia por pérdida de conectividad definida.
• Privacidad y tratamiento de datos revisados.
• Responsable del soporte durante el corte identificado.
• Fecha para retirar o archivar el sistema anterior definida.

Si varios puntos siguen sin respuesta, es preferible resolverlos antes de sustituir el equipo en producción. Una cotización también será más precisa si desde el inicio se comparte la cantidad de empleados, sedes, turnos, modelos actuales, software utilizado y método de identificación deseado.

Preguntas frecuentes

¿Puedo conservar los registros de mi reloj checador anterior?

En muchos casos pueden exportarse o archivarse, pero depende del equipo y del software. Antes de migrar, confirma el formato, la integridad y el método de consulta futura.

¿Se pueden pasar las huellas o rostros al equipo nuevo?

No debe asumirse. La compatibilidad de plantillas biométricas depende de la tecnología, los modelos y la plataforma. El proyecto debe contemplar reenrolamiento cuando no exista una ruta confirmada.

¿Tengo que cambiar todos los relojes al mismo tiempo?

No necesariamente. Si la arquitectura admite coexistencia y el proyecto está bien controlado, puede plantearse una migración por sedes o etapas.

¿Un sistema moderno tiene que estar en la nube?

No. Puede ser local, en la nube o responder a otra arquitectura. La elección depende de la operación, la conectividad, la administración, la seguridad y la integración.

¿Qué debo probar antes del cambio definitivo?

Altas de usuarios, marcajes, horarios, turnos, incidencias, comunicación, reportes, permisos, respaldos y contingencias.

¿SpeedFace-V5L puede trabajar con ZKBio Time?

La documentación oficial vigente de ZKTeco incluye ZKBio Time como software local (on-premise) compatible mediante TA Push para la serie SpeedFace-V5L; deben verificarse la variante, el firmware y la versión del proyecto (ZKTeco, 2026a).

¿Cuánto tiempo debe durar una migración?

No existe un periodo universal. Depende del número de sedes y usuarios, de la complejidad de los horarios, de la limpieza de datos, del enrolamiento, de las integraciones y del alcance de las pruebas.

Conclusión: modernizar no es cambiar un reloj, es ordenar el proceso

Una migración exitosa conserva lo que todavía tiene valor, elimina dependencias innecesarias y valida el nuevo flujo antes de retirar el anterior. El orden recomendado es inventariar, respaldar, limpiar, definir el proceso, seleccionar la arquitectura y los métodos de identificación, probar, operar en paralelo cuando corresponda y, finalmente, realizar el corte.

Para una empresa mexicana, el resultado más útil no es simplemente tener un reloj más nuevo, sino contar con registros de asistencia que puedan administrarse de forma consistente, recuperarse cuando se necesiten y acompañar el crecimiento de la operación.

Si ya conoces los modelos de tus equipos actuales, el número de empleados, las sedes y el software utilizado, puedes usar esa información para solicitar una evaluación de compatibilidad y dimensionar la migración antes de comprar nuevos dispositivos.

Referencias

• Cámara de Diputados del H. Congreso de la Unión. (2025). Ley Federal de Protección de Datos Personales en Posesión de los Particulares. https://www.diputados.gob.mx/LeyesBiblio/pdf/LFPDPPP.pdf
• ZKTeco. (s. f.-a). FAQ: How to connect the SpeedFace-V5L device to ZKBio Time 9.0 software? https://www.zkteco.com/en/faq
• ZKTeco. (2026a). SpeedFace-V5L Series. https://www.zkteco.com/en/SpeedFaceSeries/SpeedFace-V5L-Series
• ZKTeco. (2026b). ZKBio Time 9.0 Datasheet [Centro de descargas]. https://www.zkteco.com/en/data_sheet
• ZKTeco. (2026c). ZKTeco Time & Attendance Management Solution for the Health Department in Pakistan. https://zkteco.com/en/case/ZKTeco_Time_Attendance_Management_Solution_for_the_Health_Department_in_Pakistan