VB6 en 2026: cómo salir sin reescribir todo

En 2026 todavía hay sistemas en Visual Basic 6 procesando pagos, facturas, inventarios y nóminas. No es una excepción rara: es una realidad en muchas empresas que construyeron su operación entre 1998 y 2005 y nunca tuvieron un motivo suficientemente urgente para reemplazarla.

El problema no es que VB6 sea “viejo”. El problema es que cada cambio depende de menos personas, más miedo y más trabajo manual. Y cuando el último desarrollador que entiende el sistema se jubila, la empresa descubre que tiene un activo que no puede mantener.

Por qué el VB6 sigue vivo

• Funciona. Hace exactamente lo que la empresa necesita, aunque nadie sepa explicarlo.
• Reemplazarlo compite con urgencias del negocio.
• Las reglas están en el código, en la base de datos y en la cabeza de dos o tres personas.
• Migrar suena a “reescribir todo”, y eso da miedo.

La buena noticia: no tienes que elegir entre quedarte para siempre y reescribir todo en un año.

Cuatro opciones reales

1. Reescritura total

Solo tiene sentido si el sistema es pequeño, el dominio está bien entendido y puedes permitirte un periodo de convivencia. En sistemas críticos, rara vez es la mejor primera opción.

2. Encapsular y exponer

Se conserva el núcleo en VB6 y se expone su funcionalidad a través de una capa nueva (API, servicio .NET o cola de mensajes). La interfaz y los consumidores pueden modernizarse sin tocar la lógica vieja.

3. Reemplazo por módulos

Se elige un módulo con dolor de negocio, se reescribe en .NET y se conecta al resto. El sistema viejo sigue operando para lo demás. Es la versión de escritorio del patrón strangler fig.

4. Contener y planificar la salida

Si no hay presupuesto para migrar, al menos se reduce el riesgo: documentar, congelar cambios, aislar dependencias, respaldar y definir un plan. No es modernizar, pero evita el colapso.

Cómo empezar sin romper nada

Inventario de formularios, clases y dependencias

Necesitas saber qué pantallas existen, qué hacen, qué tablas tocan y qué componentes COM usan. Un inventario simple en una hoja de cálculo es mejor que un diagrama perfecto que nadie actualiza.

Identificar el núcleo

No todas las pantallas son igual de importantes. Separa:

• Núcleo: cálculo, contabilidad, pagos, reglas del negocio.
• Bordes: reportes, consultas, mantenimiento.
• Interfaz: formularios y flujos de usuario.

El núcleo suele ser más pequeño de lo que parece. Ahí está el valor.

Aislar la base de datos

Los accesos directos a tablas y stored procedures son el mayor acoplamiento. Crea una capa de acceso a datos o una API que encapsule las operaciones críticas. Así el sistema nuevo no depende del esquema viejo.

Reemplazar de a un flujo

Empieza por un flujo medible: por ejemplo, “consultar saldo” o “registrar un pago”. Haz que el sistema nuevo lo resuelva y que el viejo siga disponible como respaldo. Cuando el nuevo sea estable, apaga el viejo para ese flujo.

Correr en paralelo

Durante un tiempo, ambos sistemas pueden procesar y comparar resultados. La conciliación te da evidencia para apagar el legacy sin fe.

Riesgos que no debes ignorar

• Componentes COM de terceros que no tienen reemplazo directo.
• Consultas SQL embebidas en formularios.
• Reglas implícitas que solo aparecen en casos borde.
• Reportes que dependen de la base de datos y no del código.
• Usuarios que han desarrollado atajos y costumbres alrededor de la interfaz.

Un plan realista

1. Semana 1–2: inventario y mapa de dependencias.
2. Semana 3–4: priorización por riesgo y valor; definición del primer flujo.
3. Mes 2–3: capa de encapsulamiento y primer módulo en .NET.
4. Mes 3–6: migración por flujos, con conciliación y rollback.
5. Continuo: documentación, transferencia y apagado gradual.

No es rápido. Pero es más barato que un big bang fallido y más seguro que no hacer nada.

Checklist

• ☐ Inventario de formularios, clases y componentes COM.
• ☐ Mapa de tablas y stored procedures críticos.
• ☐ Identificación de reglas de negocio no documentadas.
• ☐ Capa de encapsulamiento o API.
• ☐ Primer flujo migrado con conciliación.
• ☐ Plan de rollback por módulo.
• ☐ Documentación y transferencia al equipo.
• ☐ Criterios para apagar cada parte del legacy.

Si tienes un sistema en VB6 y no sabes si conviene encapsular, migrar o reemplazar, puedo ayudarte a evaluarlo con una auditoría técnica.