Migrar de sistemas
legacy sin downtime.

Una IPS no puede apagarse. No hay ventana de mantenimiento un sábado en la noche que sirva cuando urgencias sigue recibiendo pacientes y la hospitalización no se detiene. Esa es la restricción que hace que migrar un sistema hospitalario se parezca poco a migrar cualquier otro software.

La buena noticia es que el problema está bien estudiado. La mala es que la mayoría de las migraciones fallan por razones que no tienen nada que ver con la tecnología.

Por qué fallan las migraciones

Casi nunca es un problema de datos. Es un problema de secuencia: se intenta mover todo al mismo tiempo.

El patrón típico es la migración big bang: un fin de semana largo, todo el mundo trabajando, y el lunes se arranca con el sistema nuevo. Funciona en instituciones pequeñas con procesos simples. En una IPS de varias sedes, lo que ocurre es que aparecen quince problemas simultáneos el lunes a las 7 de la mañana, nadie sabe cuál causó cuál, y no hay forma de aislar la falla porque todo cambió a la vez.

La alternativa es aburrida y funciona: migrar por fases, en un orden que respete las dependencias reales de la operación.

El orden que sí funciona

Fase 1. Los cimientos, sin usuarios.

Antes de que nadie toque el sistema nuevo, se parametriza lo que no cambia a diario: el tarifario, los contratos con las EPS, el plan de cuentas, las bodegas, los centros de costo, la estructura de servicios y la nómina de usuarios con sus perfiles.

Esta fase no tiene glamour y es donde se gana o se pierde el proyecto. Un tarifario mal cargado no se nota el primer día; se nota el día 45 cuando la facturación no cuadra y ya hay seis semanas de operación encima.

Fase 2. Un servicio piloto, en paralelo.

Elige un servicio acotado y de bajo riesgo: consulta externa de una especialidad, o una sede pequeña. Durante dos o tres semanas ese servicio opera en el sistema nuevo mientras el resto sigue en el anterior.

Sí, hay doble digitación en la frontera. Es un costo real y acotado, y es mucho más barato que descubrir un problema de configuración con toda la institución adentro.

Fase 3. El ciclo asistencial.

Admisiones, agenda, historia clínica, hospitalización. Aquí es donde el sistema toca a los médicos, y donde la resistencia al cambio es más alta y más legítima: un médico que tarda tres minutos más por paciente ve veinte pacientes menos a la semana.

Fase 4. Facturación y cartera.

Se migra al final por una razón concreta: necesitas que el ciclo asistencial esté generando datos limpios antes de facturarlos. Si facturas sobre un registro clínico que todavía se está estabilizando, las glosas del primer trimestre te van a doler.

Fase 5. Administrativo.

Inventario, compras, contabilidad, turnos. Importante, pero puede convivir con el sistema anterior más tiempo sin afectar la atención.

Qué datos mover, y cuáles no

La tentación es migrarlo todo. Rara vez es la decisión correcta.

Migra en caliente lo que la operación necesita mañana: pacientes activos, hospitalizados en curso, agendas futuras, cartera abierta, inventario actual, contratos vigentes.

Migra en frío lo que se consulta pero no se opera: historias clínicas cerradas, facturación radicada de años anteriores, movimientos de inventario históricos. Estos pueden entrar después del arranque, sin presión, e incluso quedar en un repositorio de consulta.

No migres lo que nunca vas a volver a mirar. Cada tabla que arrastras es una tabla que hay que mapear, validar y mantener. Una migración es la única oportunidad realista de dejar atrás quince años de basura acumulada. Aprovéchala.

Un matiz importante: la historia clínica tiene requisitos legales de conservación y disponibilidad. “No migrar” nunca significa “borrar”: significa decidir conscientemente si vive en el sistema nuevo o en un archivo consultable, y dejar esa decisión documentada.

La reconciliación es innegociable

Después de cada fase, antes de avanzar a la siguiente, hay que probar que los datos llegaron completos. No con una revisión visual: con conteos.

Cuántos pacientes había en origen y cuántos hay en destino. Cuánto suma la cartera en cada lado. Cuántas unidades tiene el inventario. Si los números no cuadran al 100 %, no se avanza, y la diferencia se explica una por una, no se promedia.

Este paso se salta con frecuencia porque es tedioso y porque el cronograma va apretado. Es exactamente el paso que separa una migración de un desastre silencioso que se descubre tres meses después.

El factor que nadie presupuesta

El tiempo de tu propio equipo.

Durante una migración, tu líder de facturación, tu coordinador de admisiones y tu jefe de sistemas van a dedicar entre el 20 % y el 40 % de su jornada al proyecto, encima de su trabajo normal. Si eso no está planeado, va a salir de algún lado: casi siempre de la calidad de la parametrización o de las horas de descanso de tu gente.

Planéalo explícitamente. Reasigna carga, contrata refuerzo temporal, o alarga el cronograma. Las tres son opciones razonables; fingir que el tiempo aparece solo no lo es.

Un cronograma realista

Para una IPS de tamaño medio con varias sedes, entre cuatro y doce semanas es un rango razonable, dependiendo de cuántos módulos se activen y de qué tan limpios estén los datos de origen.

Desconfía de cualquiera que te prometa dos semanas. No porque sea técnicamente imposible mover los datos en dos semanas, sino porque la migración no es el cuello de botella: lo es la capacidad de tu equipo para absorber el cambio sin dejar de atender pacientes.