Diego Molinari

← Todos los casos

De COBOL a una Web API, sin apagar nada

El problema

El sistema de gestión no es una herramienta más: es por donde pasa la operación de la empresa — distribución, impresión, contabilidad, suscripciones. Y había nacido en COBOL.

El objetivo no era hacer un sistema mejor. Era que la transición fuera gradual y llevadera para quienes lo usan todos los días: sin un día en que todo cambia de golpe, y sin que nadie tenga que reaprender su trabajo de un viernes a un lunes.

Las tres plataformas

El mismo sistema, tres tecnologías

  1. Origen COBOL El sistema por el que pasaba la operación de la empresa.
  2. 2024 VB .NET Escritorio. Reconstruido desde las pantallas del legacy y el relevamiento con los usuarios.
  3. 2025 Web API en ASP.NET Core con frontend React. Se le siguen agregando módulos.
Cada etapa se validó corriendo el sistema nuevo en paralelo con el anterior.

COBOL → VB .NET (2024). El sistema de escritorio que reemplazó al legacy.

VB .NET → web (2025). De aplicación de escritorio a una API en ASP.NET Core con frontend React. Es la versión que corre hoy, y a la que se le siguen agregando módulos.

Sobre esa API se sigue construyendo: el módulo de control de stock a medida es la etapa actual del mismo sistema, y se desarrolla sobre el entorno de staging que corre en paralelo a producción.

Vista ilustrativa · la misma pantalla, dos usuarios

sistema de gestión

Perfil Administración7

InicioDistribuciónSuscripcionesContablesImpresiónStockReportesRadiosUsuariosAuditoría
  • Devoluciones anómalas4
  • Anomalías del sistema2
  • Falta de datos1

Perfil Depósito7

InicioDistribuciónSuscripcionesContablesImpresiónStockReportesRadiosUsuariosAuditoría
Reconstrucción ilustrativa, no una captura. Arriba y abajo es el mismo sistema, abierto por dos personas distintas. Las solapas no se ocultan por diseño de pantalla: cada módulo declara qué permiso exige y la barra se arma con lo que ese usuario tiene. Lo tachado es lo que la segunda persona no ve. El contador de la campana agrupa lo que el sistema detecta sobre sí mismo: devoluciones fuera de rango, comportamientos anómalos, datos que faltan.

Las decisiones que costaron

Reconstruir desde las pantallas y los usuarios, no desde el código. No traduje el COBOL línea por línea: relevé el sistema mirando las pantallas del legacy y trabajando con la gente que lo usaba todos los días.

Es un método más incómodo que leer el fuente, y por una razón concreta: los usuarios te cuentan lo que hacen, no lo que el sistema hace. El caso raro aparece sólo si alguien se acuerda de mencionarlo. No hay una fuente de verdad contra la cual comparar — hay personas, y cada una conoce su pedazo.

Correr los dos sistemas en paralelo, con fecha. Justamente porque las reglas venían de la memoria de la gente y no del código, hacía falta una forma de detectar lo que faltaba antes de que doliera.

El nuevo se prueba con los usuarios, y después se fija una fecha a partir de la cual el trabajo se hace en los dos sistemas a la vez para poder comparar los resultados. Lo que no coincide es una regla que no había aparecido en el relevamiento. Cuesta el doble de trabajo durante ese período, y es la única manera de encontrar lo que nadie recordaba.

Resultado

El sistema pasó por tres plataformas y nunca dejó de operar. Hoy es una Web API en producción que sigue creciendo, y la lógica de negocio que llegó en COBOL es la misma que responde ahora.