FUNCUAN, del papel y un sistema legado a una plataforma clínica completa en 7 semanas

¿Cuál era el problema?

FUNCUAN maneja cinco operaciones en una: jornadas masivas de esterilización en barrios (cientos de animales por día), un centro clínico con hospitalización, patrullas que rescatan animales en campo, un call center que recibe ~30 llamadas diarias, y un programa de adopciones. Todo eso bajo un contrato público que exige 14 formatos oficiales según el tipo de atención, diligenciados, firmados y archivados.

La operación vivía repartida entre dos mundos que no se hablaban: un sistema legado en .NET con años de historia acumulada, y papel. Los formatos oficiales se llenaban a mano y se archivaban en carpetas físicas. Las patrullas en campo no tenían conectividad garantizada, así que sus registros llegaban horas o días después, transcritos a mano. Los reportes para la Alcaldía se armaban manualmente cada período, cruzando fuentes que no coincidían. Y años de historia clínica, fotos, radiografías y consentimientos vivían en un sistema que ya nadie podía mantener.

¿Qué consideramos antes de construir?

Evaluamos primero los sistemas comerciales para clínicas veterinarias. Ninguno encajaba: están diseñados para consultorios privados con citas individuales, no para una operación pública con jornadas masivas de esterilización, patrullas de campo sin señal, 7 roles de usuario distintos y formatos oficiales específicos exigidos por un contrato municipal. Forzar la operación de FUNCUAN dentro de un SaaS genérico habría significado seguir llevando la mitad del trabajo en papel.

Una segunda restricción definió el proyecto: la fundación no podía perder su historia. Más de 100.000 animales registrados, decenas de miles de esterilizaciones documentadas, radiografías, consentimientos firmados. Cualquier sistema nuevo tenía que nacer con todos esos datos adentro, no empezar de cero. Eso convirtió la migración de datos en un proyecto tan importante como el software mismo.

La primera semana no escribimos código: la pasamos en la operación, acompañando al equipo en su día a día y recolectando los 14 formatos oficiales que el sistema tenía que producir. El software se diseñó a partir de los documentos que la fundación está obligada a entregar, no al revés.

¿Cómo diseñamos la solución?

Una sola plataforma web con módulos que cubren la operación completa:

• Historia clínica tablet-first, consultas, emergencias, controles y atenciones de jornada se registran en tablets directamente en el punto de atención, con autenticación por PIN para el personal clínico y captura de firmas en pantalla (tutor y personal).
• Jornadas masivas de esterilización, registro en lote optimizado para el ritmo real de una jornada: cientos de animales en un día, sin navegar perfil por perfil.
• Hospitalización, áreas, jaulas, transferencias, hoja de evolución y una grilla visual de medicación AM/PM para el personal auxiliar.
• Patrullas de campo 100% offline, una PWA que funciona sin señal: captura fotos (protocolo de 3 fotos por incidente), GPS y datos del rescate, y sincroniza automáticamente cuando vuelve la conectividad, sin duplicar registros.
• Call center, registro y categorización de llamadas, asignación a patrullas y seguimiento.
• Adopciones y triaje, flujo de solicitudes de adopción y clasificación de urgencias a la llegada.
• 14 formatos oficiales en PDF, cada documento que antes se llenaba a mano ahora se genera automáticamente con los datos del sistema y las firmas digitales estampadas, en el formato exacto que exige el contrato.
• Reportes para la Alcaldía, los informes periódicos (esterilizaciones, emergencias, adopciones, censo por barrio) salen en Excel y PDF con un clic, desde los mismos datos de la operación.
• Auditoría universal, cada cambio en el sistema queda registrado automáticamente: quién hizo qué, cuándo y desde dónde. Indispensable en una operación con recursos públicos.

Todo con 7 roles de usuario (administración, coordinación, recepción, veterinarios, auxiliares, patrullas e inventario), cada uno viendo exactamente lo que su función necesita.

¿Cómo migramos los 500.000 archivos que no se podían perder?

El sistema anterior guardaba años de operación. Construimos un ETL idempotente que procesó el volcado completo de la base de datos legada en streaming (sin materializar tablas de blobs de varios GB) y pobló el sistema nuevo con:

• 101.834 animales con su historia y foto de perfil (84.160 fotos)
• 81.040 tutores (responsables de los animales)
• 119.038 historias clínicas, consultas, emergencias, controles y atenciones de jornada
• 68.895 procedimientos, de ellos 68.316 esterilizaciones documentadas
• 504.790 archivos adjuntos, fotos clínicas, radiografías, resultados de exámenes y consentimientos firmados, deduplicados por hash de contenido

La migración nos dejó la lección más valiosa del proyecto: en el primer pase trabajamos sobre una copia parcial de la base legada, y tres tablas críticas, entre ellas las emergencias y las jornadas históricas, aparecían vacías. En lugar de asumir que estaban vacías en el origen, reconciliamos el volcado crudo completo tabla por tabla, contando filas contra el sistema nuevo, y las recuperamos todas. Ese paso, verificar la completitud contra la fuente original y no contra una copia intermedia, es hoy parte obligatoria de nuestro playbook de migraciones.

¿Qué stack técnico usamos y por qué?

• Next.js 14 App Router + Prisma + PostgreSQL 16, el mismo patrón probado de nuestros otros ERPs: Server Components y Server Actions, tipado end-to-end del schema a la UI, y una base transaccional sobrada para cientos de miles de registros con búsqueda instantánea (índices trigram para buscar por microchip, nombre o tutor).
• PWA offline-first, service worker + IndexedDB para que las patrullas operen sin señal: cola de sincronización con claves de idempotencia (un rescate nunca se duplica aunque el teléfono reintente), compresión de fotos en el dispositivo y reintentos con backoff.
• Gotenberg (HTML→PDF) como sidecar, los 14 formatos oficiales se renderizan como HTML fiel al formato del contrato y se convierten a PDF en un contenedor dedicado, con firmas digitales estampadas vía pdf-lib.
• Autenticación dual, NextAuth con roles para escritorio, y sesiones por PIN para las tablets compartidas del área clínica, pensadas para el ritmo de una consulta real.
• Docker + Coolify sobre VPS propio (Hetzner), la fundación no depende de un SaaS: la aplicación, la base de datos y el generador de PDFs corren en infraestructura controlada, con deploy automático desde GitHub.
• Respaldos 3-2-1 con restauración probada, base de datos y archivos se respaldan automáticamente hacia dos proveedores distintos en ubicaciones distintas, y el procedimiento de recuperación ante desastres está documentado y probado de punta a punta, no es un backup que nunca se ha intentado restaurar.

¿Qué resultados entregamos?

El sistema completo estaba en producción 7 semanas después del kickoff (19 de mayo de 2026), migración completa incluida. Resultados concretos:

• Sistema en producción y en uso real por el equipo completo de la fundación: recepción, veterinarios, auxiliares, patrullas, call center y coordinación
• Cero papel en los formatos oficiales, los 14 documentos del contrato se generan con datos reales y firmas digitales
• Toda la historia preservada, más de 100.000 animales consultables al instante con su historia clínica, fotos y documentos de años anteriores
• Operación de campo sin conectividad, las patrullas registran rescates con foto y GPS, y el sistema sincroniza solo
• Reportes a la Alcaldía en minutos, lo que antes era un ejercicio manual de cruzar fuentes ahora sale del sistema con un clic
• Trazabilidad total, auditoría automática de cada cambio, en una operación financiada con recursos públicos

¿Qué aprendimos?

Tres lecciones que aplicamos a todo proyecto con datos legados u operación de campo desde entonces:

1. La migración se reconcilia contra la fuente cruda, no contra una copia. Una tabla que aparece vacía en una copia intermedia no está necesariamente vacía en el origen. La única forma de garantizar que no se perdió nada es enumerar cada tabla del volcado original con su conteo real de filas y explicar cada diferencia contra el sistema nuevo. Y antes de todo eso: pedirle al cliente que describa su sistema viejo. Tres párrafos suyos exponen puntos ciegos que ninguna arqueología de código revela.

2. Offline-first es un requisito de diseño, no una mejora posterior. Si una parte del equipo trabaja donde no hay señal, el modo offline no puede ser un parche: define la arquitectura de sincronización, las claves de idempotencia y el manejo de conflictos desde el día uno. Agregarlo después equivale a reescribir.

3. Los documentos obligatorios definen el sistema. Pasar la primera semana recolectando los 14 formatos que la fundación debe entregar, antes de escribir una línea de código, hizo que el modelo de datos naciera correcto. Cuando el entregable legal es un documento, el software se diseña desde el documento hacia atrás.