Migración de gestor de expedientes en ayuntamientos: cómo cambiar sin perder datos
Una migración de gestor de expedientes en un ayuntamiento es uno de los proyectos tecnológicos con más impacto sobre la operativa municipal. El sistema de expedientes concentra documentos, metadatos, firmas, índices, permisos, históricos y relaciones con registro, sede, notificaciones y archivo. Cambiar de plataforma sin una metodología clara puede generar pérdidas de información, expedientes incompletos, firmas imposibles de validar o dependencias técnicas que aparecen cuando el sistema antiguo ya está fuera de servicio.
La migración debe plantearse como un proyecto de datos, interoperabilidad y continuidad, no como una simple copia de archivos. Antes de contratar una nueva plataforma conviene conocer qué existe realmente, qué debe conservarse y cómo se demostrará que la información ha llegado correctamente al destino. La guía sobre expediente electrónico municipal ayuda a entender los componentes que deben preservarse durante el cambio.
En proyectos de digitalización de la Administración Pública, una migración bien preparada puede convertirse además en una oportunidad para normalizar procedimientos, eliminar duplicidades y reducir dependencia del proveedor anterior.
Cuándo tiene sentido cambiar de gestor
El cambio suele plantearse cuando termina un contrato, el producto deja de evolucionar, existen problemas de rendimiento, el soporte es insuficiente, faltan integraciones o la entidad quiere consolidar varias herramientas. También puede aparecer tras una reorganización, una adhesión a servicios compartidos o una estrategia de modernización más amplia.
No todos los problemas justifican una migración. Antes conviene realizar una auditoría tecnológica que diferencie limitaciones del producto, problemas de configuración, carencias de formación y necesidades realmente nuevas.
Esta evaluación evita iniciar una sustitución costosa cuando el problema podría resolverse mediante integración, rediseño de procesos o soporte especializado.
Inventario previo de procedimientos y expedientes
El primer paso es saber qué debe migrarse. La entidad debería inventariar procedimientos, número de expedientes, volumen documental, años afectados, estados, unidades gestoras y tipologías especiales.
También conviene identificar expedientes cerrados, abiertos, suspendidos, archivados y aquellos que tienen documentos o firmas con características particulares. La migración no tiene por qué tratar todos los casos exactamente igual.
Este inventario ayuda a estimar esfuerzo y presupuesto, y aporta una base objetiva para un futuro pliego técnico de digitalización.
Depuración y calidad del dato antes de migrar
Antes de extraer información conviene medir la calidad del origen. Expedientes duplicados, campos vacíos, catálogos inconsistentes, documentos huérfanos o referencias a unidades que ya no existen pueden trasladarse al sistema nuevo si no se detectan previamente. La migración no debería convertirse en una réplica exacta de problemas acumulados durante años.
Es útil clasificar incidencias por tipo y decidir qué puede corregirse automáticamente, qué requiere revisión humana y qué debe conservarse tal como está por motivos de trazabilidad. Las reglas de limpieza tienen que quedar documentadas para que el ayuntamiento pueda explicar qué transformaciones se aplicaron y repetir el proceso si fuera necesario.
Esta fase mejora la calidad del resultado y reduce el número de excepciones durante las cargas masivas.
Qué datos deben conservarse
Un expediente no se reduce a sus documentos. Deben preservarse identificadores, metadatos, estados, fechas, órganos, interesados, relaciones, referencias registrales, permisos, firmas, índices y otra información necesaria para reconstruir la tramitación.
La entidad debe decidir qué campos son obligatorios en el destino y cómo se transformarán los valores del sistema antiguo. Los catálogos pueden utilizar nombres diferentes o estructuras incompatibles.
La transformación debe documentarse mediante una matriz origen-destino para que cada campo tenga una regla conocida y verificable.
Documentos y formatos
Los documentos pueden encontrarse en PDF, formatos ofimáticos, imágenes, XML u otros tipos. Antes de migrar conviene revisar si existen ficheros corruptos, documentos sin extensión, duplicados o archivos enlazados desde sistemas externos.
La estrategia debe garantizar que cada documento mantiene su relación con el expediente y sus metadatos. Las copias electrónicas auténticas y otros documentos con evidencias específicas requieren especial cuidado.
No es recomendable convertir indiscriminadamente todos los archivos a un formato nuevo si esa transformación elimina información o evidencias necesarias.
Firmas electrónicas
Las firmas deben poder seguir verificándose después de la migración. El sistema de destino necesita conservar datos y evidencias suficientes para interpretar la firma, su certificado y su relación con el documento.
La guía sobre firma electrónica en ayuntamientos explica por qué no basta con conservar la representación visual de una rúbrica.
Durante el piloto conviene seleccionar documentos con distintos formatos de firma y verificar su comportamiento en el nuevo gestor.
Índice electrónico y ENI
Cuando existen expedientes estructurados conforme al Esquema Nacional de Interoperabilidad, la migración debe conservar o regenerar adecuadamente índices, identificadores y metadatos. La interoperabilidad entre Administraciones Públicas debe considerarse desde el diseño.
La exportación ENI puede ser además una pieza importante de la estrategia de reversibilidad. Si el gestor permite sacar expedientes en estructuras interoperables, la entidad dispone de más garantías ante futuros cambios.
El pliego debería especificar qué formatos de exportación se exigirán al sistema de destino.
Integraciones con registro y sede
El nuevo gestor no funciona aislado. Debe conectarse con registro, sede electrónica, firma, notificaciones, archivo, sistemas económicos y aplicaciones sectoriales.
La sede electrónica del ayuntamiento debe seguir creando o alimentando expedientes sin introducir pasos manuales nuevos. También deben revisarse identificadores como DIR3 y catálogos como SIA cuando formen parte de las integraciones.
Una migración es un buen momento para sustituir intercambios manuales por APIs documentadas siempre que sea viable.
Diseñar una migración piloto
Nunca debería comenzar la migración masiva sin una prueba representativa. El piloto debe incluir expedientes sencillos, complejos, antiguos, recientes, abiertos, cerrados y con diferentes tipos de documentos y firmas.
El objetivo es validar reglas de transformación, tiempos, rendimiento y calidad de datos. Las incidencias detectadas deben documentarse y resolverse antes de aumentar el volumen.
La muestra debe ser suficientemente diversa para evitar que el piloto resulte perfecto simplemente porque se eligieron los casos más fáciles.
Planificar la migración por oleadas
Cuando el volumen es elevado, resulta más seguro dividir el proyecto en oleadas por años, unidades o tipos de procedimiento. Cada bloque puede tener una ventana de extracción, carga, validación y cierre. Este enfoque permite aprender de los primeros lotes y reducir el impacto de una incidencia inesperada.
El cronograma debe reflejar dependencias con usuarios, proveedores y servicios externos. También debe indicar qué ocurre si una oleada no supera las pruebas y cómo se evita que el retraso arrastre al resto del proyecto.
La planificación por fases facilita además asociar hitos de aceptación y pagos a resultados verificables.
Reconciliación entre origen y destino
Después de cada migración debe existir un proceso de reconciliación. No basta con comprobar que “hay documentos”. Deben compararse número de expedientes, documentos, estados, metadatos críticos, firmas y relaciones.
Conviene establecer indicadores de completitud y tolerancias. Si un expediente no puede migrarse automáticamente, debe quedar identificado y tener un procedimiento de tratamiento manual controlado.
Los informes de reconciliación deberían conservarse como evidencia de aceptación.
Criterios de aceptación de la migración
El contrato debería definir qué condiciones permiten aceptar cada lote. Pueden incluir porcentaje de registros migrados, correspondencia de documentos, validación de firmas, ausencia de errores críticos, tiempos máximos de consulta y resolución de incidencias abiertas.
Las métricas deben diferenciar defectos que impiden usar el sistema de pequeñas inconsistencias que pueden corregirse después. También conviene fijar una muestra manual de expedientes que sea revisada por personal municipal antes de cerrar cada fase.
Sin criterios de aceptación claros, proveedor y ayuntamiento pueden tener interpretaciones distintas sobre cuándo la migración está realmente terminada.
Coexistencia temporal
En proyectos de cierto tamaño puede ser necesario mantener ambos sistemas durante un periodo. Esta coexistencia debe estar diseñada para evitar que el mismo expediente se modifique simultáneamente en dos plataformas.
Una estrategia habitual es fijar una fecha de corte y dejar el sistema antiguo en consulta para determinados expedientes mientras los nuevos se tramitan en la plataforma nueva.
El plan debe indicar qué usuarios acceden a cada sistema, qué operaciones están permitidas y cuándo se retira definitivamente el entorno anterior.
Pruebas funcionales
La migración debe probarse desde la perspectiva del usuario. Buscar expedientes, abrir documentos, validar firmas, tramitar, firmar, notificar, exportar y consultar históricos son escenarios esenciales.
También deben comprobarse permisos y perfiles. Una migración técnicamente completa puede generar un problema grave si usuarios sin autorización acceden a información que antes estaba restringida.
Los casos de prueba deberían formar parte de los criterios de aceptación del contrato.
Rendimiento y volumen
El nuevo sistema debe soportar el volumen real de la entidad. Conviene medir tiempos de búsqueda, apertura de expedientes, generación de listados y operaciones masivas.
La carga de documentos históricos puede afectar índices o almacenamiento. El proveedor debe explicar cómo dimensiona la plataforma y qué límites existen.
El rendimiento debería medirse con datos representativos antes de la puesta en producción.
Seguridad y ENS
Durante la migración se manipulan grandes cantidades de información, por lo que seguridad y trazabilidad son críticas. Debe definirse dónde se almacenan exportaciones temporales, quién accede, cómo se cifran y cuándo se eliminan.
La guía del ENS para ayuntamientos sirve para revisar accesos, registros, continuidad y responsabilidades de proveedores.
Los ficheros intermedios no deben quedar olvidados en equipos o espacios sin control después del proyecto.
Plan de contingencia
La puesta en producción debe contemplar qué ocurre si aparece una incidencia crítica. Conviene disponer de copia, procedimiento de reversión y responsables de decisión.
El cambio puede programarse en fases para reducir el impacto. La entidad debe saber cuánto tiempo puede operar sin determinadas funciones y qué procesos no pueden detenerse.
Un plan de contingencia realista reduce presión y evita improvisaciones durante el cambio.
Formación y acompañamiento
El nuevo gestor suele modificar pantallas, estados y circuitos. La formación debe organizarse por roles: tramitadores, responsables, firma, administración y soporte.
También es útil disponer de un periodo de acompañamiento intensivo tras la puesta en producción. Las primeras incidencias revelan configuraciones o hábitos que no aparecen en pruebas.
La asistencia técnica de transformación digital puede ayudar a coordinar proveedor, usuarios y resolución de incidencias durante esta fase.
Retirada segura del sistema anterior
El apagado del gestor antiguo debe ser una fase planificada. Antes conviene confirmar que no quedan integraciones activas, expedientes pendientes, usuarios que dependan del sistema ni datos sin validar. También debe decidirse qué información se conserva en archivo, qué copias quedan bajo custodia y qué credenciales se revocan.
Si el antiguo proveedor alojaba datos o copias, el contrato de salida debe incluir devolución y eliminación conforme a las obligaciones aplicables. La entidad debería recibir una evidencia de cierre y conservar la documentación necesaria para futuras comprobaciones.
Retirar correctamente el sistema evita seguir pagando servicios innecesarios y reduce superficie tecnológica y riesgo.
Reversibilidad y salida futura
La migración debe evitar repetir el problema dentro de unos años. El nuevo contrato debería exigir capacidad de exportar datos, expedientes, documentos y metadatos en formatos definidos y sin costes desproporcionados.
También conviene recibir documentación de APIs, configuraciones, integraciones y modelo de datos. La entidad debe conservar control sobre sus activos y credenciales.
La estrategia de salida se diseña al contratar, no cuando vence el contrato.
Cómo preparar la contratación
El expediente debería definir alcance, volúmenes, fuentes, reglas, integraciones, pruebas, hitos, aceptación, soporte y responsabilidades. La redacción de pliegos técnicos es especialmente importante en migraciones porque muchas desviaciones aparecen por conceptos no definidos.
También conviene preparar una memoria justificativa del proyecto que explique necesidad, objetivos y resultados esperados.
Los criterios técnicos deben valorar metodología de migración, capacidad de integración, pruebas, seguridad, documentación y estrategia de continuidad, siempre dentro del marco aplicable.
Qué puede aportar BlackHold Consulting
BlackHold Consulting trabaja en ámbitos que encajan con proyectos de migración e integración: digitalización e integración de procesos, automatización de procesos, automatización de tareas administrativas y consultoría tecnológica.
También dispone de capacidades en automatización de gestión documental, integración de procesos complejos, agentes e integraciones con IA y servicios de automatización. En el sector público, cualquier participación debe articularse mediante el procedimiento de contratación correspondiente.
Checklist antes de migrar
Inventario
Procedimientos, expedientes, documentos, firmas y volúmenes conocidos.
Modelo de datos
Reglas origen-destino documentadas y validadas.
Piloto
Muestra representativa con casos simples y complejos.
Reconciliación
Comparación objetiva de datos y documentos migrados.
Integraciones
Registro, sede, firma, notificaciones, archivo y sistemas sectoriales probados.
Seguridad
Control sobre exportaciones, temporales, accesos y trazabilidad.
Continuidad
Fecha de corte, coexistencia y contingencia definidas.
Reversibilidad
Capacidad de exportar nuevamente el sistema en el futuro.
Preguntas frecuentes
¿Cuánto dura una migración de gestor de expedientes?
Depende del volumen, calidad de datos, integraciones y complejidad de los expedientes. Debe estimarse tras un inventario y una prueba piloto.
¿Se pueden migrar expedientes abiertos?
Sí, pero requieren reglas específicas para conservar estado, responsables, documentos pendientes y continuidad del trámite.
¿Es suficiente exportar los PDFs?
No. Deben preservarse metadatos, firmas, índices, estados y relaciones necesarias para interpretar el expediente.
¿Conviene mantener el sistema antiguo?
Puede ser útil durante una fase de coexistencia controlada, especialmente para consulta y validación, pero debe existir una fecha y estrategia de retirada.
¿Cómo se comprueba que no se han perdido datos?
Mediante reconciliación entre origen y destino, pruebas funcionales, muestras y métricas de completitud.
¿Qué debe exigir el ayuntamiento al nuevo proveedor?
Metodología, pruebas, documentación, APIs, seguridad, soporte, exportación y reversibilidad, además de los requisitos funcionales del gestor.
Conclusión
La migración de un gestor de expedientes municipal debe tratarse como una transformación controlada de datos, documentos y procesos. El éxito depende de inventariar, probar, reconciliar y documentar antes de apagar la plataforma anterior.
Un buen proyecto no solo mueve expedientes: mejora integraciones, reduce dependencias y deja al ayuntamiento preparado para evolucionar sin quedar atado a un único proveedor. Por eso la contratación debe definir desde el principio pruebas, criterios de aceptación y estrategia de salida.
Cuando existen múltiples sistemas, grandes volúmenes o integraciones complejas, contar con apoyo especializado en migración, desarrollo e interoperabilidad puede reducir riesgo y acelerar la transición hacia un entorno documental más sostenible.
Fotografía: Kampus Production / Pexels.
