Casos de Éxito en Retoma de Software Empresarial en Latinoamérica

La teoría sobre Retoma de Software: Cómo Rescatar Sistemas Abandonados por su Proveedor Original">retoma de software es útil para entender el concepto. Los casos reales muestran cómo se aplica en contextos distintos, qué obstáculos aparecen y qué resultados son razonables esperar. En este artículo presentamos tres casos reales (con nombres, sectores específicos y cifras ajustadas para proteger confidencialidad) de empresas latinoamericanas que rescataron sistemas críticos.

Cada caso muestra un perfil distinto: sector financiero, logística y manufactura. Lo que tienen en común es que en ningún caso se tomó la ruta fácil de "reescribir todo desde cero".

Caso 1: Aseguradora mediana — Core de pólizas en Visual Basic 6

Situación inicial

Una aseguradora mediana, con operación en tres países latinoamericanos y 400.000 pólizas activas, dependía de un sistema construido en Visual Basic 6 a comienzos de los años 2000. El proveedor original había cerrado operaciones en 2019. Desde entonces, el sistema funcionaba gracias a un contratista que había trabajado en el proyecto original, pero que ya tenía 68 años y había anunciado su retiro definitivo.

Problemas específicos:

• Nuevos canales digitales (app móvil, broker web) no podían integrarse con el core.
• La regulación había cambiado y requerían reportes que el sistema no generaba.
• El costo de operación crecía cada año por horas de remediación manual.
• No había documentación técnica ni funcional sistemática.

Decisión

La primera propuesta recibida fue reescribir el sistema completo en una plataforma moderna. El plazo estimado era de 24 meses, el presupuesto de USD 850.000 y el riesgo alto (perder lógica regulatoria acumulada en 20 años).

La alternativa que se adoptó: encapsular el motor VB6 como servicio detrás de una API REST moderna, construir los nuevos canales sobre la API y reemplazar módulos específicos progresivamente.

Ejecución

El trabajo se estructuró en fases:

1. Auditoría y diagnóstico (4 semanas): entendimiento completo del modelo de datos, identificación de interfaces críticas, priorización de módulos.
2. Capa de encapsulación (8 semanas): construcción de una API REST en .NET Core que expusiera las funciones del motor VB6. Se logró con una combinación de librerías de interoperabilidad y un middleware intermedio.
3. Primer canal digital (12 semanas): portal web para brokers, consumiendo la nueva API. Resultado visible al negocio desde el mes 6.
4. Módulos progresivos (18 meses adicionales): reportería regulatoria, conciliación con sistemas contables, dashboards operativos.

Resultados

• Tiempo total: 14 meses vs 24 proyectados en la reescritura.
• Costo total: USD 385.000, menos de la mitad de la alternativa.
• El motor VB6 sigue corriendo sin cambios, protegiendo la lógica regulatoria.
• 3 nuevos canales digitales lanzados sobre la API.
• Reporte regulatorio que antes tomaba 3 días manuales, ahora se genera en 15 minutos automáticamente.

Lección

No todo sistema viejo debe morir. A veces, la lógica de negocio acumulada es el mayor activo de la empresa y preservarla (envolviéndola) es más inteligente que reemplazarla.

Caso 2: Empresa de logística — Sistema de rastreo en Delphi 7

Situación inicial

Una empresa de transporte de carga con flota de 120 vehículos operaba con un sistema de rastreo y gestión de rutas escrito en Delphi 7 hacia el año 2005. El desarrollador original se había retirado y no había documentación. El sistema solo corría en estaciones de trabajo Windows en la oficina central, lo que obligaba a los operadores a estar físicamente allí para consultar información.

Durante la pandemia, esta limitación se volvió crítica: la operación remota era imposible. Adicionalmente, el sistema tenía 2-3 caídas por semana que nadie sabía resolver a profundidad (solo reiniciaban).

Decisión

La empresa consideró contratar un producto SaaS de rastreo de flotas. El problema: ninguno se adaptaba a los flujos específicos de su operación (relación con shippers, liquidación de comisiones a operadores, integración con su ERP propietario).

Se optó por una retoma + modernización progresiva: entender el sistema actual, estabilizarlo, construir una capa web accesible desde cualquier lugar y migrar módulo a módulo.

Ejecución

1. Ingeniería inversa del modelo de datos (3 semanas): mapeo completo de las tablas, sus relaciones y lógica implícita.
2. Identificación de la causa de las caídas (2 semanas): una consulta mal optimizada era responsable del 85% de los incidentes. Fix inmediato.
3. API REST + frontend Vue.js (10 semanas): acceso remoto al sistema, consultas principales accesibles desde cualquier dispositivo.
4. Migración progresiva de módulos (8 meses): cada trimestre se reemplazaba un módulo del sistema Delphi por uno nuevo.

Resultados

• Caídas del sistema: de 2-3 por semana a 0 en los últimos 6 meses.
• Acceso remoto habilitado para 22 operadores y 4 administradores.
• Reducción del 60% en tiempo de consulta de rastreo.
• Integración con el ERP automatizada (antes manual por archivos Excel).
• Costo total a 14 meses: USD 180.000, vs USD 450.000 estimados de una reescritura completa.

Lección

La primera acción de estabilización (arreglar la consulta que causaba caídas) entregó valor en 2 semanas. Eso le dio al proyecto credibilidad y apoyo directivo para las fases posteriores. Es clave buscar victorias tempranas visibles.

Caso 3: Manufactura — ERP propietario en FoxPro

Situación inicial

Una empresa manufacturera con tres plantas en Colombia y Ecuador operaba con un ERP desarrollado internamente en FoxPro en 1998. La empresa había tenido tres intentos fallidos de reemplazarlo:

• 2012: intento de implementar SAP Business One. Se canceló al año por adaptación insuficiente a procesos locales.
• 2016: desarrollo a medida en Java. Se canceló a los 18 meses, 40% completo.
• 2020: intento de adoptar Odoo. Se detuvo tras 6 meses por falta de conectores a sistemas legacy de producción.

El ERP original seguía operando, pero con problemas crecientes: nadie entendía ya todos los módulos, los usuarios avanzados eran los verdaderos poseedores del conocimiento, y las actualizaciones eran imposibles.

Decisión

Después de tres reemplazos fallidos, la empresa decidió cambiar de estrategia. En lugar de reemplazar, modernizar progresivamente. Mantener el núcleo que funcionaba (órdenes de producción, inventarios físicos), envolverlo con interfaces modernas y migrar los módulos más problemáticos (reportería, interfaz de usuario) a una plataforma nueva.

Ejecución

1. Diagnóstico profundo (6 semanas): sesiones con usuarios clave para entender qué módulos funcionaban bien y cuáles no.
2. Capa de servicios (14 semanas): API REST en Python/FastAPI sobre las bases de datos FoxPro.
3. Nueva interfaz web (6 meses): frontend moderno que reemplaza las pantallas FoxPro para los usuarios de todas las plantas.
4. Módulos progresivos (16 meses): reportería BI, integración con sistema contable, módulo de mantenimiento industrial.
5. Desactivación gradual: el FoxPro queda como motor transaccional, invisible para el usuario final.

Resultados

• Tiempo total: 24 meses.
• Costo total: USD 420.000 (vs cerca de USD 1.200.000 combinados en los tres intentos fallidos anteriores).
• Cero interrupción operacional durante el proceso.
• Usuarios reportan la interfaz nueva como "la mejor mejora en 20 años".
• Tiempo de generación de reportes gerenciales: de horas a minutos.
• Planta nueva (Ecuador) onboardeada al sistema en 3 semanas vs 4 meses del proceso anterior.

Lección

Un sistema viejo no siempre es el problema. A veces el problema es intentar reemplazarlo sin entender por qué sobrevivió tantos años. La retoma + modernización progresiva preserva lo que funciona y lo reviste con lo nuevo.

Patrones comunes entre los tres casos

1. Auditoría previa: cada proyecto empezó con un diagnóstico técnico y funcional de 3-6 semanas. Sin esto, ninguno habría funcionado.
2. Victorias tempranas: todos entregaron valor visible en los primeros 2-3 meses. Esto construye confianza para las fases largas.
3. Arquitectura intermedia: API REST como puente entre viejo y nuevo. Permite coexistencia y migración controlada.
4. Equipo mixto: especialistas en retoma de software + usuarios clave internos que preservan el conocimiento de negocio.
5. Presupuesto controlado: en los tres casos el gasto fue menor al 50% del estimado para una reescritura completa.

Conclusión

La retoma de software no es teoría: es una práctica con decenas de casos exitosos en Latinoamérica. Los tres casos mostrados comparten un enfoque común: respeto por el sistema existente, diagnóstico disciplinado, modernización progresiva y entregas tempranas.

Si tu empresa tiene un sistema crítico en estado similar a los descritos —proveedor original ausente, tecnología vieja, conocimiento concentrado en pocas personas—, la primera conversación no debería ser "cuánto costaría reescribirlo" sino "cómo rescatarlo". En IT Efectivos llevamos más de 13 años haciendo este tipo de proyectos. Escríbenos para una reunión inicial sin compromiso.