FlowWest: Modernizando 30 Años de dBase III hacia Infraestructura Cloud
Me uní a FlowWest en agosto de 2020 como la primera contratación de ingeniería. FlowWest es una firma de consultoría en agua, ecosistemas, ciencia y tecnología que trabaja con agencias del sector público y socios tribales en programas ambientales que gestionan $20-40M anuales. Tenían profunda experiencia de dominio en hidrología, pesca y política hídrica. Lo que no tenían era infraestructura de datos moderna.
La columna vertebral de sus operaciones de datos era un sistema dBase III construido a principios de los 90, más de 30 años de datos acumulados, flujos de entrada y conocimiento institucional codificado en una tecnología que precedía la web. Mi trabajo era modernizar ese sistema sin perder lo que lo hacía funcionar.
Tech Stack
| Capa | Tecnología |
|---|---|
| Base de datos | PostgreSQL (migrado desde dBase III) |
| Plataforma cloud | Google Cloud Platform (GCP) |
| Pipelines ETL | Python |
| Validación de datos | Motor de reglas personalizado (guiado por expertos de dominio) |
| Acceso | Cloud-native multi-usuario (reemplazó bloqueos de archivos) |
El problema
dBase III no era solo una base de datos. Era un flujo de trabajo. Biólogos, hidrólogos y técnicos de campo habían estado ingresando datos en este sistema durante décadas. Cada workaround, cada convención de nombres, cada paso manual tenía una razón, incluso si esa razón se había perdido en la memoria institucional.
Los problemas concretos:
- La entrada manual de datos era el método de input principal. Datos de campo de estaciones de monitoreo, conteos de peces y mediciones de calidad de agua se transcribían a mano en formularios dBase. Las tasas de error eran altas y las correcciones lentas.
- El tiempo de procesamiento para reportes agregados (los entregables que las agencias estatales y socios tribales realmente necesitaban) tomaba semanas. El sistema no podía manejar el volumen de joins y agregaciones requeridas para reportes regulatorios a la escala de programas que gestionaban $20-40M.
- Sin colaboración. Los archivos dBase vivían en máquinas locales y carpetas de red compartidas. No había acceso concurrente, ni historial de versiones, ni pista de auditoría. Si alguien sobrescribía un registro, se perdía.
- El cumplimiento regulatorio requería precisión y trazabilidad de datos que el sistema existente no podía garantizar.
Lo que construí
Migración a PostgreSQL en GCP. Migré los datos de dBase III a una base de datos PostgreSQL alojada en Google Cloud Platform. Esto no fue un lift-and-shift. El esquema de dBase tenía décadas de deuda acumulada: tablas desnormalizadas, nombres inconsistentes, relaciones implícitas que solo tenían sentido si habías estado usando el sistema desde 1995. Normalicé el esquema mientras preservaba compatibilidad con queries de reportes existentes.
Sistemas ETL y de flujos de trabajo cross-platform. Construí pipelines ETL en Python que podían ingestar datos de múltiples fuentes (dispositivos de campo, hojas de cálculo y exportaciones del legacy dBase), normalizarlos, validarlos y cargarlos en PostgreSQL. La capa de flujos de trabajo automatizó los pasos de agregación y generación de reportes que antes eran manuales.
Capa de validación de datos. Cada registro que entraba al nuevo sistema pasaba por reglas de validación construidas a partir del conocimiento de expertos de dominio. Verificaciones de rango en lecturas de temperatura del agua. Verificaciones de consistencia entre mediciones relacionadas. Flagging, no rechazo: el sistema mostraba anomalías para revisión humana en lugar de descartar datos silenciosamente.
Acceso cloud-native. Migrar a GCP significó que el equipo podía acceder a los datos desde cualquier lugar. Los técnicos de campo podían enviar datos desde estaciones de monitoreo. Los analistas podían ejecutar queries sin esperar bloqueos de archivos. Las agencias estatales podían recibir reportes más rápido.
Resultados
| Métrica | Antes | Después |
|--------|--------|-------|
| Esfuerzo de entrada manual de datos | Baseline | -80% |
| Precisión de datos | Baseline | +60% |
| Tiempo de procesamiento de reportes | Semanas | Horas |
| Acceso concurrente | Ninguno (bloqueos de archivos) | Multi-usuario completo |
Estos números importaban porque los programas que servían no eran opcionales. Monitoreo de poblaciones de peces, reportes de calidad del agua, cumplimiento regulatorio: estos tenían plazos legales y consecuencias reales para los ecosistemas y comunidades que dependían de ellos. Procesamiento más rápido y mayor precisión significaron mejores decisiones sobre asignación de agua, restauración de hábitat y protección de especies en peligro.
Aprendizajes
Los sistemas legacy codifican conocimiento institucional. La tentación con un sistema de 30 años es tirarlo y empezar de cero. Eso habría sido un error. Cada particularidad en el esquema de dBase estaba ahí porque un experto de dominio tomó una decisión sobre cómo representar sus datos. La migración tuvo éxito porque pasé semanas entrevistando a hidrólogos y biólogos para entender por qué los datos estaban estructurados como estaban antes de cambiar nada.
Ser la primera contratación de ingeniería significa construir confianza primero. El equipo había operado sin un ingeniero dedicado durante décadas. Eran escépticos (razonablemente) de que un ingeniero de software de Nueva York entendiera su trabajo. Gané confianza aprendiendo su vocabulario de dominio, sentándome en sesiones de recolección de datos de campo, y entregando mejoras pequeñas y visibles antes de proponer la migración grande. La arquitectura técnica fue la parte más fácil.
La validación de datos es una feature de producto, no una tarea de limpieza. La capa de validación se planeó inicialmente como limpieza post-migración. Abogué por hacerla una parte permanente del pipeline de ingesta. Cuando trabajas con datos ambientales que informan decisiones regulatorias, "el número se veía raro pero no lo detectamos" no es un resultado aceptable.
ETL para dominios regulados es diferente. No puedes transformar datos silenciosamente. Cada transformación necesita ser auditable: qué entró, qué salió, qué regla se aplicó y quién aprobó la excepción. Construí el pipeline con trazabilidad completa de linaje desde el día uno. Esto no era sobre-ingeniería; era un requerimiento de las agencias que financiaban estos programas. La misma disciplina de pista de auditoría se traslada a cada sistema de IA que construyo, desde automatización de intake legal donde el privilegio abogado-cliente exige trazabilidad, hasta el aislamiento de datos multi-tenant de Arepa.AI.
Trabaja Conmigo en Algo Similar
Si cargas con infraestructura de datos legacy que se ha convertido en un pasivo (ya sea un sistema de 30 años como dBase III o una década de deuda técnica acumulada en un stack moderno) el enfoque de migración aquí escala. Preservación de conocimiento de dominio, migración por fases, y validación de datos por diseño son las mismas disciplinas que aplico a pipelines de datos de IA hoy.
Explorar Servicios de Consultoría de IA o enviar una consulta - respondo dentro de un día hábil.