Cómo migrar de software legacy a la nube en tu clínica sin perder datos ni parar la actividad

1. Qué es un software legacy sanitario y cuándo dejó de ser suficiente

En tecnología, software legacy es todo sistema informático que sigue siendo utilizado a pesar de haber sido diseñado con una arquitectura, estándares de seguridad o modelo de negocio que ya no responden a las necesidades actuales. En el ámbito sanitario, el software legacy suele presentar alguna de estas características:

1.1. Las características de un sistema legacy sanitario

• Instalado localmente en un ordenador o servidor físico de la clínica (on-premise), sin acceso remoto nativo.
• Base de datos en formatos propietarios cerrados, difíciles de exportar o integrar con otros sistemas.
• Sin actualizaciones regulares de seguridad ni adaptaciones normativas automáticas.
• Diseñado antes del RGPD (2018) y del estándar DICOM moderno, por lo que el cumplimiento normativo requiere trabajo manual adicional.
• Sin integración nativa con equipos de diagnóstico, portales de seguros o plataformas de reserva online.

1.2. El punto de quiebre: RGPD, VeriFactu y trabajo remoto

El software legacy no es necesariamente viejo en años. Hay plataformas lanzadas hace 5 años que ya son legacy por su arquitectura. Lo que define el legacy no es la fecha de lanzamiento sino la incapacidad estructural de evolucionar al ritmo que exige el entorno normativo y tecnológico actual.

En el caso de las clínicas sanitarias, el punto de quiebre suele ser la combinación de tres factores: la entrada en vigor del RGPD (que exige medidas técnicas que muchos legacy no pueden implementar de forma nativa), la obligatoriedad de VeriFactu para la facturación (que el software legacy tampoco puede asumir sin una reescritura profunda) y la pandemia de 2020, que evidenció la imposibilidad de trabajar en remoto con sistemas instalados en un único equipo físico.

2. Las 7 señales de que tu software actual ya no funciona

Antes de plantear una migración, conviene hacer un diagnóstico honesto. Estas son las señales más frecuentes de que el software actual está limitando a la clínica:

2.1. Señales de infraestructura y soporte

1. No puedes acceder a la agenda o a los expedientes desde fuera de la clínica. En 2026, cualquier especialista necesita poder consultar un historial desde casa, desde el hospital de referencia o desde una segunda sede.
2. La copia de seguridad es manual o depende de un disco externo. Si alguien tiene que acordarse de conectar el disco USB cada noche, tienes un riesgo de pérdida de datos activo.
3. El proveedor ya no da soporte o tarda semanas en resolver incidencias. Un software sin soporte activo es un software que no evoluciona y que en caso de fallo crítico puede dejarte sin sistema durante días.

2.2. Señales de cumplimiento y facturación

1. No puedes firmar consentimientos digitalmente. Seguir imprimiendo, firmando en papel y escaneando es ineficiente, contamina el expediente y es más difícil de demostrar ante la AEPD.
2. No puedes generar el Registro de Actividades de Tratamiento automáticamente. Si el DPO tiene que construir el RAT a mano revisando el software, hay una brecha de compliance RGPD activa.
3. La facturación está desconectada del acto clínico. Si el médico cierra la consulta y alguien tiene que volver a entrar los datos manualmente en el programa de facturación, es cuestión de tiempo que haya descuadres.
4. El software no cumplirá VeriFactu cuando sea obligatorio. Si el proveedor no tiene un plan claro y documentado para el cumplimiento de VeriFactu, tendrás que cambiar de software de todas formas. Mejor hacerlo ya con tiempo para elegir bien.

Si tu clínica presenta 3 o más de estas señales, el coste de seguir con el sistema actual (en tiempo, riesgo legal y pérdida de productividad) ya supera el coste de migrar. El análisis comparativo de arquitecturas está en software médico en la nube vs on-premise: ventajas, riesgos y costes reales.

3. Los 5 riesgos reales del software legacy en 2026

El principal argumento que escuchamos para no migrar es «si funciona, no lo toques». El problema es que en el entorno normativo actual, un software legacy que «funciona» operativamente puede estar generando riesgos legales y financieros significativos en segundo plano:

3.1. Riesgo de seguridad y de pérdida de datos

El software legacy instalado localmente raramente recibe parches de seguridad con la frecuencia necesaria. Los datos de salud de tus pacientes están en un equipo físico en tu clínica, probablemente sin cifrado en reposo, accesible desde la red local sin MFA y con copias de seguridad manuales poco fiables. Una infección por ransomware puede cifrar todos los expedientes en minutos. El análisis de las amenazas más frecuentes está en ciberseguridad en clínicas sanitarias: amenazas y prevención.

A eso se suma el riesgo físico: si la copia de seguridad es manual y nadie la ha verificado en meses, existe una probabilidad real de perder años de expedientes clínicos en un único fallo del disco. Un proveedor cloud que permite descargar una copia de tus datos en cualquier momento reduce ese riesgo sin depender de que alguien se acuerde de conectar un disco externo.

3.2. Riesgo normativo: RGPD y VeriFactu

Si tu software legacy no genera logs de acceso, no tiene control de accesos granular por roles y no permite la firma electrónica de consentimientos, está incumpliendo los artículos 25 y 32 del RGPD de forma estructural, tal y como se detalla en RGPD en clínicas privadas: guía de cumplimiento. El coste de una sanción puede superar con creces el coste de años de suscripción a un ERP cloud moderno. A esto se añade VeriFactu, obligatorio para clínicas privadas según el calendario de la AEAT: un software legacy sin encadenamiento hash criptográfico de facturas no puede cumplirlo sin una reescritura profunda que la mayoría de proveedores de software antiguo no van a acometer.

3.3. Riesgo de vendor lock-in

Cuanto más tiempo llevas con un software legacy, más profunda es la dependencia: los datos están en un formato propietario que solo ese software puede leer, el personal conoce únicamente ese sistema y cualquier intento de exportar los datos requiere la cooperación del proveedor. Cuando el proveedor desaparece o sube los precios de forma inaceptable, la capacidad de negociación es mínima.

4. Las 5 fases de una migración exitosa

Una migración bien planificada no exige parar la actividad de la clínica ni un solo día.

Una migración bien planificada no requiere parar la actividad de la clínica ni un solo día. El proceso se diseña para que el equipo trabaje normalmente durante todo el proceso y el arranque en el nuevo sistema sea transparente.

4.1. Antes de migrar: auditoría, planificación y extracción de datos

Fase 1 — Auditoría y planificación (semana 1-2)

El proceso comienza con un análisis exhaustivo de la situación actual antes de tocar nada:

• Inventario completo de los datos existentes: número de expedientes, volumen de imágenes PACS, histórico de facturación y citas.
• Análisis del formato de almacenamiento del software actual: ¿base de datos SQL estándar o formato propietario? ¿Qué opciones de exportación ofrece el proveedor?
• Identificación de los datos críticos vs los datos prescindibles en la migración.
• Definición del calendario de migración que minimice el impacto en la actividad asistencial.
• Configuración del nuevo sistema: plantillas de HCE, tarifas, usuarios, integraciones con equipos diagnósticos.

Fase 2 — Extracción y preparación de datos (semana 2-3)

Es la fase más técnica y la que más depende de la calidad del software de origen:

• Exportación completa de los datos del sistema legacy en el formato que el proveedor permita (SQL, CSV, XML, formatos propietarios).
• Limpieza y normalización de los datos: corrección de caracteres especiales, duplicados, registros incompletos y datos en formatos no estándar.
• Mapeo de campos: correspondencia entre los campos del sistema de origen y los del sistema de destino. Este proceso es crítico para que los datos lleguen al lugar correcto.
• Carga en entorno de pruebas y primera verificación de integridad.

4.2. El fin de semana de la migración

Fase 3 — Migración en producción (fin de semana)

La carga definitiva de los datos en el sistema de producción se ejecuta siempre en horario no asistencial para minimizar el riesgo operativo:

• Bloqueo del sistema legacy para evitar modificaciones durante la migración (idealmente un viernes por la tarde).
• Carga de datos en el nuevo sistema cloud con verificación en tiempo real.
• Verificación de integridad post-carga: se comprueba que el número de expedientes, citas y facturas migrados coincide con el sistema de origen.
• Resolución de incidencias antes del lunes.

4.3. Después de migrar: formación, cierre y optimización

Fase 4 — Formación y arranque (semana 4)

• Formación del equipo con los datos reales ya cargados: el personal aprende a usar el nuevo sistema con sus propios pacientes, no con datos de demostración.
• Sesiones diferenciadas por perfil: recepción (3-4 horas), médicos (2-3 horas), dirección (1-2 horas).
• Periodo de convivencia de 5 días hábiles: el sistema legacy sigue disponible en solo lectura por si hay que consultar algo, pero toda la actividad nueva se registra en el nuevo sistema.
• Soporte intensivo en tiempo real durante el primer día operativo.

Fase 5 — Cierre y optimización (semanas 5-8)

• Cierre definitivo del sistema legacy. Solicitud al proveedor anterior de la eliminación de los datos según el RGPD.
• Configuración de automatizaciones: recordatorios, plantillas de emails, reglas de facturación.
• Revisión de los primeros KPIs del nuevo sistema.
• Ajustes basados en el feedback del equipo durante las primeras semanas.

El proceso de migración específico desde los softwares más habituales del mercado español está documentado en cómo migrar tus historiales clínicos a un nuevo software sin pérdida de datos. Los errores técnicos más comunes en la automatización de historiales están en errores en la automatización de historiales clínicos y cómo evitarlos.

5. Qué datos migran y cómo se estructuran

Una de las preguntas más frecuentes al plantear una migración es qué datos van a migrar y en qué formato. La respuesta depende del software de origen, pero estos son los bloques de datos habituales en una migración sanitaria completa:

5.1. Los bloques de datos, uno a uno

5.2. Lo único que no migra: la configuración

El dato más importante de esta tabla: las configuraciones del sistema no migran. Las tarifas, las plantillas de HCE, los usuarios y los permisos se crean de nuevo en el nuevo sistema durante la fase de configuración. Esto no es un problema sino una oportunidad para limpiar configuraciones obsoletas y partir de una arquitectura optimizada.

6. Cómo verificar la integridad de los datos migrados

La verificación de integridad es la diferencia entre una migración exitosa y una que da problemas después.

La verificación de integridad es el conjunto de comprobaciones que garantizan que los datos han migrado correctamente. Es la diferencia entre una migración exitosa y una que genera problemas meses después. Estos son los puntos de control obligatorios:

6.1. Verificación cuantitativa

• ☐ Número de pacientes: el sistema de destino tiene exactamente el mismo número de fichas de paciente que el de origen.
• ☐ Número de citas históricas: el recuento de citas por mes del último año cuadra entre origen y destino.
• ☐ Volumen de facturación: la suma de facturación por año de los últimos 3 años coincide entre origen y destino.
• ☐ Saldos de bonos activos: cada paciente con bono activo tiene el saldo correcto en el nuevo sistema.
• ☐ Número de documentos adjuntos: el recuento de PDFs e imágenes migradas coincide con el inventario del origen.

6.2. Verificación cualitativa (muestreo)

• ☐ Abrir manualmente 20-30 expedientes aleatorios y verificar que el historial clínico, las citas y las facturas de cada paciente son correctas y completas.
• ☐ Verificar al menos 5 pacientes con bonos activos: que el saldo y el historial de sesiones son correctos.
• ☐ Verificar que las imágenes PACS migradas abren correctamente en el visor del nuevo sistema.
• ☐ Comprobar que los expedientes de pacientes con datos especialmente sensibles (menores, tratamientos de salud mental) han migrado correctamente y con los permisos adecuados.

6.3. Verificación de acceso y permisos

• ☐ Cada usuario del nuevo sistema solo puede ver los expedientes que le corresponden según su rol.
• ☐ El personal de recepción no tiene acceso a la HCE completa.
• ☐ Los logs de acceso están activos y registrando correctamente desde el primer día.

Regla de oro: no des por cerrada la migración hasta que los puntos 6.1 y 6.2 estén completados al 100 % y firmados por el responsable de la migración y por el director de la clínica. Este documento es tu prueba ante cualquier reclamación posterior.

7. Cuánto cuesta realmente migrar: desglose completo

El coste de una migración tiene dos componentes: el coste directo (lo que pagas al nuevo proveedor y al actual) y el coste indirecto (el tiempo de tu equipo durante el proceso). Ambos deben estar en el presupuesto antes de tomar la decisión, junto con el modelo de precio del nuevo proveedor, detallado en la página de precios y planes de obeliOmed.

7.1. Coste directo

7.2. Coste indirecto (tiempo de tu equipo)

El coste más subestimado es el tiempo que el equipo de la clínica dedica al proceso de migración. Con una buena planificación, los impactos son mínimos:

• Dirección: 4-8 horas en total (briefing inicial, revisión de configuración, aprobación de verificación de integridad).
• Administrativos: 6-12 horas en total (formación + ajuste primeras semanas).
• Médicos: 3-6 horas en total (formación específica de HCE).

7.3. El coste de NO migrar

El análisis coste-beneficio de la migración solo está completo si también se cuantifica el coste de quedarse con el sistema actual:

• Horas administrativas adicionales por procesos manuales: 3-8 horas semanales × 18 €/hora = 2.800-7.400 €/año.
• Pérdidas por absentismo no automatizado: 0,5-1 cita diaria × 60 € × 220 días = 6.600-13.200 €/año.
• Riesgo sancionador RGPD: entre 25.000 y 300.000 euros en caso de inspección con hallazgos técnicos.
• Riesgo de pérdida de datos por fallo del servidor local: coste de recuperación entre 5.000 y 50.000 euros más el daño reputacional.

8. Los errores que arruinan una migración

Estos son los errores más frecuentes en migraciones de software clínico que hemos documentado. Cualquiera de ellos puede convertir una migración de 3 semanas en un proyecto de 3 meses o generar pérdida de datos:

8.1. Errores en la extracción y preparación de datos

1. No solicitar la exportación completa al proveedor anterior antes de avisar de la baja. Algunos proveedores restringen el acceso a los datos cuando saben que el cliente se va. Exporta primero, avisa después.
2. Asumir que todos los datos están en la base de datos principal. En muchos softwares legacy, parte de los datos (imágenes, PDFs adjuntos) están en carpetas del servidor local, no en la base de datos. Si solo exportas la base de datos, pierdes esos archivos.
3. No limpiar los datos antes de migrar. Registros duplicados, pacientes con datos incompletos o histórico de citas con errores en el sistema origen generan el mismo caos en el sistema destino. La limpieza previa es obligatoria.
4. Migrar en horario de consulta. Aunque el proceso sea técnicamente viable, cualquier incidencia durante la migración puede afectar a la actividad del día. La migración definitiva siempre en fin de semana o festivo.

8.2. Errores de proceso y cierre

1. No hacer la verificación de integridad antes del arranque. Activar el nuevo sistema en producción sin haber verificado que todos los datos han migrado correctamente es el error que genera más problemas post-migración.
2. Formar al equipo con datos de demostración en lugar de datos reales. La formación con datos reales de la clínica acelera drásticamente la curva de aprendizaje. Con datos de demostración, la curva real empieza el día del arranque.
3. No documentar el proceso de migración. El informe de migración (con el inventario de datos de origen, los resultados de la verificación de integridad y las incidencias resueltas) es un documento que deberás conservar mínimo 5 años para cualquier auditoría.
4. No planificar la eliminación de datos del sistema antiguo. Una vez confirmada la migración exitosa, los datos deben eliminarse del sistema legacy según el RGPD. Mantener los datos del paciente en dos sistemas activos simultáneamente durante más del período de transición es una no conformidad del RGPD.

9. Qué aporta obeliOmed en la migración y cómo empezar

9.1. El mismo equipo que migra, el que da soporte después

La auditoría, la depuración de datos y la carga en el entorno de prueba están incluidas en la implantación para un volumen estándar de historiales. Un origen especialmente complejo —varios formatos mezclados, datos muy corruptos— puede requerir una valoración aparte, siempre presupuestada antes de empezar, nunca a mitad de proceso.

9.2. Precio y cómo empezar

Los planes empiezan desde 29 €/⁠mes, con cada módulo adicional facturado aparte. El desglose completo está en la página de precios y planes.