El miedo real a la hora de cambiar de sistema de RRHH no es aprender una interfaz nueva. Es perder algo por el camino: el historial de quién ha usado qué portátil, el motivo por el que alguien pidió una excedencia hace dos años, o el rastro de un ajuste de vacaciones que nadie recuerda pero que un día alguien va a necesitar explicar. Una migración mal planteada no borra datos de golpe — los deja huérfanos, sin contexto, hasta que ya no sirven para nada.
La buena noticia es que la mayoría de esos riesgos se evitan con orden: decidiendo qué se migra primero, qué se convierte en un registro nuevo con nota del histórico anterior, y qué simplemente no merece la pena arrastrar.
Qué migrar primero: los datos maestros
Antes que nada, la estructura básica: empleados, departamentos y puestos. Es el motivo por el que una plantilla de importación de datos maestros en Excel importa tanto al principio — permite dar de alta a toda la plantilla de golpe, con su departamento y su puesto ya asignados, en lugar de crear cada ficha a mano una por una. Sin esta base bien cargada, todo lo que viene después (ausencias, equipamiento, evaluaciones) no tiene dónde engancharse.
Equipamiento IT: no se borra, se da de baja
Un error habitual al migrar es tratar el inventario de equipamiento como una lista que se puede limpiar sin más. Pero un portátil con historial — quién lo tuvo antes, cuándo se le hizo mantenimiento — no debería poder eliminarse sin dejar rastro. La forma correcta de gestionarlo, tanto en el sistema nuevo como en cualquier migración, es dar de baja la unidad conservando su número de serie y su historial, no borrarla como si nunca hubiera existido. Si el sistema antiguo permite borrar sin más, ese es justo el dato que hay que rescatar antes de apagarlo.
Ausencias e histórico: qué merece la pena arrastrar
No todo el histórico necesita migrarse con el mismo detalle. Los saldos de vacaciones actuales y los tipos de ausencia sí son críticos desde el primer día — alguien va a pedir un permiso la primera semana. El detalle de cada ausencia de hace tres años, en cambio, puede quedarse como un resumen o un documento aparte: lo importante es que el saldo de partida sea correcto, no reconstruir cada fila de un histórico que nadie va a auditar.
Permisos: no migres el caos, redefínelo
Migrar no es solo mover datos: es también la ocasión de arreglar lo que nunca estuvo bien configurado. Si en el sistema antiguo los permisos eran un genérico admin/editor/viewer que obligaba a dar acceso de más para resolver un caso concreto, no tiene sentido copiar esa misma estructura en el sistema nuevo. Aprovecha la migración para definir permisos granulares por módulo, con su nivel (lectura, escritura, admin) y su ámbito (propio, equipo, global) — es más trabajo el primer día, pero evita arrastrar el mismo problema durante otros cinco años.
La regla práctica es simple: migra primero lo que otros datos necesitan para existir (personas, departamentos, puestos), protege lo que no se puede reconstruir si se pierde (equipamiento con número de serie, motivos de ajustes de saldo) y resume lo demás. Un sistema nuevo que empieza con datos limpios y trazables vale más que uno que arrastra diez años de detalle mal enganchado.