Ningún centro empieza de cero. Cuando llega el momento de cambiar de sistema, hay años de expedientes en una base de datos que se diseñó con otros criterios —o sin criterios— y la pregunta inevitable es qué hacer con ellos.
La respuesta corta: migrar lo que se pueda probar y no fabricar lo que falte. La larga ocupa el resto de este artículo.
El error de origen: rellenar huecos
Los sistemas antiguos de mesa de partes rara vez registraban lo que la norma ahora exige. Es común encontrar una tabla con el nombre de quien presentó, un archivo adjunto y una fecha —a veces declarada por el propio remitente— y nada más. Ni demandante, ni demandado, ni tipo de proceso, ni resumen.
La tentación es completar esos campos «con lo que se deduce del documento». Es un error por dos razones.
La primera es de fondo: un dato deducido en 2026 sobre un documento de 2022 no es un dato histórico, es una interpretación. Si mañana alguien la discute, el centro tendrá que explicar por qué su sistema afirma algo que nadie registró en su momento.
La segunda es operativa: si esos registros entran al flujo normal, aparecerán en la bandeja de trabajo y alguien terminará calificándolos otra vez, años después, por error.
La solución: dos espacios separados
Lo que funciona es tratar el pasado como archivo, no como trabajo pendiente.
Un espacio de presentaciones históricas, de solo lectura, sin estados de flujo ni operaciones de escritura, que conserve exactamente lo que el sistema anterior sí registraba: quién presentó, cuándo, qué archivo, con su huella digital. Ni un campo más.
Y el flujo vivo, con la estructura completa que la norma exige, para lo que entra desde la migración en adelante.
La ventaja de la separación no es estética. Es que resulta imposible que un registro histórico se confunda con una solicitud pendiente, porque no viven en la misma tabla ni aparecen en la misma bandeja. Cuando un archivo histórico ya se cargó a un expediente vivo —mismo hash—, queda marcado para que nadie lo vuelva a subir.
Empareje por clave única, nunca por texto
Este es el consejo técnico que más disgustos evita.
Al cruzar dos sistemas hay que decidir qué registro de allá corresponde a cuál de acá. La tentación es emparejar por el campo legible: el número de expediente, el nombre de la empresa, la sumilla.
No lo haga. Los textos tienen variantes: «Constructora Altamar S.A.C.», «CONSTRUCTORA ALTAMAR SAC», «Altamar S.A.C.». Los números tienen ceros a la izquierda que unos sistemas guardan y otros no. Un emparejamiento por texto produce falsos positivos silenciosos: dos expedientes distintos que se fusionan y nadie se entera hasta mucho después.
Empareje siempre por el identificador único del sistema de origen, guárdelo en el sistema nuevo como referencia externa y ponga una restricción de unicidad sobre él. Así, además, la migración se puede volver a ejecutar sin duplicar: si el registro ya existe, se salta.
Las fechas y su zona horaria
Un clásico que arruina migraciones aparentemente correctas.
Los sistemas antiguos suelen guardar fechas sin zona horaria. Al importarlas a un sistema que sí la maneja, se interpretan como UTC y todo se desplaza cinco horas. El síntoma es sutil: los documentos presentados después de las 19:00 aparecen al día siguiente. Y un día de diferencia, en materia de plazos, no es un detalle cosmético.
Decida explícitamente la zona horaria de origen, conviértala de forma explícita y verifique con casos límite: la presentación más tardía del día y la más temprana.
Auditar el resultado
Una migración no termina cuando el proceso acaba sin errores. Termina cuando alguien verifica que los dos lados dicen lo mismo.
El control mínimo:
- Recuento por período. Cuántos registros hay en origen y cuántos en destino, mes a mes. Los totales globales esconden compensaciones.
- Contraste de la huella digital de los archivos. No basta con que el archivo esté: debe ser el mismo. El hash lo dice sin ambigüedad.
- Muestreo manual. Veinte o treinta registros elegidos al azar, revisados a ojo contra el sistema anterior.
- Informe fechado. Con el resultado, las discrepancias encontradas y su tratamiento. Ese informe es evidencia de diligencia si alguien pregunta después.
Si el resultado es cero discrepancias, dígalo por escrito y guárdelo. Si hay discrepancias, documéntelas y explique qué se hizo con cada una. Lo que no vale es no haber mirado.
Los anexos que viven en la nube de otro
Un caso frecuente y espinoso: presentaciones antiguas donde el remitente dejó un enlace a su propio Drive o OneDrive con los anexos, porque el sistema no aceptaba archivos grandes.
Ese enlace no es evidencia bajo control del centro. Puede caducar, puede cambiar de contenido, puede desaparecer. Conviene conservarlo como dato —dice lo que el remitente aportó— pero registrándolo por lo que es, y sin tratarlo como un documento del expediente.
Para lo que entre a partir de ahora, la regla debería ser sencilla y sin excepciones: cero enlaces externos a documentos. Todo archivo dentro del sistema.
Cuánto tarda
Depende del estado del origen, pero el reparto de esfuerzo suele sorprender: el 20 % es escribir la migración y el 80 % es entender los datos de origen y auditar el resultado.
Si un proveedor le ofrece migrar diez años de expedientes en una semana sin haber mirado antes su base de datos, no está midiendo el trabajo: está midiendo el optimismo.
Contenido informativo. Las decisiones sobre qué información histórica conservar y cómo tratarla corresponden a cada centro y a su asesoría legal.