Contattateci

Migración de
 Visual Basic 6 a .NET
en Madrid y España

Convertimos tu aplicación VB6 en una solución .NET moderna, escalable y mantenible — sin perder ni una línea de lógica de negocio

Impulsa 3 - Scrum Master Certification
badge-stars-white-darkkkk
Innovazione tecnologica e digitalizzazione

¿Tu empresa depende de una aplicación crítica desarrollada en Visual Basic 6 hace 15, 20 o 25 años? No estás solo. Miles de empresas en España siguen ejecutando software empresarial sobre VB6 — un lenguaje que Microsoft dejó de soportar oficialmente en 2008. En Impulsa3 llevamos más de dos décadas modernizando aplicaciones legacy, y nuestro equipo incluye desarrolladores que trabajaron con el IDE original de Visual Basic 6.0. Eso significa que entendemos tu código por dentro: las particularidades de las declaraciones As Any, los controles ActiveX, las dependencias COM, las llamadas a la API de Windows y los bucles de eventos heredados. Migramos a .NET (Framework, Core, .NET 8 o .NET 9 según tu caso) preservando toda la lógica de negocio y modernizando lo que realmente conviene modernizar.

Solicita tu análisis gratuito de migración VB6

Por qué migrar de VB6 a .NET ahora

El soporte oficial terminó hace casi dos décadas

Microsoft puso fin al soporte estándar de Visual Basic 6 el 8 de abril de 2008. Desde entonces, no hay parches de seguridad, no hay actualizaciones del IDE, no hay compatibilidad oficial con las nuevas versiones de Windows. El runtime sigue empaquetado en Windows 10 y 11 por compromiso histórico de Microsoft, pero esa es la única concesión: el IDE de VB6 ya no se instala de forma soportada en Windows moderno, y cada nueva versión del sistema operativo introduce más fricciones.

Necesito una migración

Los riesgos de seguir con VB6 hoy

A continuación los siete riesgos concretos que vemos cada semana en clientes que llegan a Impulsa3:

  1. Riesgos de seguridad y cumplimiento normativo. Las aplicaciones VB6 no soportan los protocolos de cifrado modernos (TLS 1.3, AES-GCM), no tienen logging estructurado, no permiten auditorías y dependen de OCX/ActiveX que llevan más de una década sin recibir parches. Esto choca frontalmente con el RGPD, el Esquema Nacional de Seguridad (si trabajas con la administración pública), las directrices de DORA (sector financiero) y los requisitos de NIS2. Una auditoría de cumplimiento puede convertirse en un problema serio.
  2. Escasez de talento creciente. Cada año hay menos desarrolladores capaces o dispuestos a trabajar con VB6. Las universidades dejaron de enseñarlo hace más de quince años. El coste-hora de un desarrollador VB6 senior se ha disparado, y encontrar relevo cuando alguien clave del equipo se jubila o cambia de empresa es cada vez más complicado.
  3. Imposibilidad de integrarse con sistemas modernos. Tu CRM en cloud, tu ERP nuevo, tu pasarela de pago, tu plataforma de e-commerce, las APIs de tus proveedores logísticos, los servicios de Microsoft 365 — todo está construido sobre REST, OAuth 2.0, JSON, gRPC, GraphQL. Ninguno de esos protocolos se implementa de forma natural en VB6. Conseguir que tu aplicación legacy hable con el ecosistema actual implica wrappers frágiles, intermediarios manuales o procesos batch que rompen la experiencia de usuario.
  4. Limitación a 32 bits y arquitecturas obsoletas. VB6 sólo compila aplicaciones 32-bit. En un entorno empresarial donde los servidores y clientes ya son 64-bit, esto se traduce en límites de memoria (no más de 4 GB direccionables), problemas de rendimiento al manejar grandes volúmenes de datos y conflictos con drivers modernos (ODBC 64-bit, OLE DB 64-bit, etc.).
  5. Coste creciente de mantenimiento. Cada cambio funcional sobre código VB6 cuesta más caro y tarda más que sobre código .NET equivalente: peor tooling, depuración manual, dependencias sin documentar, controles de terceros que ya no se fabrican, librerías comerciales que el proveedor abandonó. La deuda técnica crece exponencialmente.
  6. Dependencia de máquinas virtuales y workarounds. Muchos clientes nos llegan ya ejecutando su aplicación VB6 dentro de una VM con Windows 7 o Windows Server 2008 R2 — sistemas operativos también fuera de soporte. Esto multiplica el riesgo: ya no es sólo VB6, es también el SO base, los drivers, la conectividad de red.
  7. Pérdida de competitividad. Mientras tu empresa mantiene un sistema cerrado, monolítico y de escritorio, tus competidores despliegan aplicaciones web responsive, API públicas, integraciones móviles y dashboards en tiempo real. La diferencia se acumula año a año.
Necesito migrar mi proyecto de VB6.0

Qué hacemos exactamente cuando migramos VB6 a .NET

Servizi di Intelligenza Artificiale

Nuestro proceso en 7 fases

A diferencia de las herramientas automáticas que prometen una conversión “click-and-done” (y luego dejan al cliente con un proyecto que no compila), nosotros aplicamos una metodología iterativa que combina automatización donde aporta valor e trabajo manual donde es imprescindible.

Fase 1 — Análisis gratuito (5 días laborables)

Recibimos tu código fuente bajo NDA y ejecutamos un inventario técnico completo:

  • Conteo de líneas de código efectivas (ELOC) por proyecto, módulo, clase y formulario.
  • Detección de código muerto — métodos y clases que ya no se invocan en ninguna ruta de ejecución, candidatos a no migrar.
  • Mapa de dependencias: librerías OCX, controles ActiveX, DLLs propias y de terceros, referencias COM, declaraciones a la API Win32.
  • Identificación de patrones no migrables directamente: parámetros As Any, redimensionamiento dinámico de arrays, uso intensivo de GoSub/Return, eventos del entorno VB6 sin equivalente en WinForms/WPF.
  • Análisis de la capa de datos: ADO, DAO, RDO, conexiones directas a SQL Server, Access, Oracle.
  • Análisis de los reportes: Crystal Reports (versión y dependencias), Microsoft Reporting, reportes propios.
  • Estimación de complejidad en horas-desarrollador, con desglose por módulo.

Al final de esta fase entregamos un informe ejecutivo de 20-30 páginas con la viabilidad, el coste estimado en rango (mínimo-máximo), el plazo realista y los principales riesgos. Este informe es tuyo, lo uses con nosotros o con cualquier otro proveedor.

Fase 2 — Análisis de negocio y requisitos

Una migración técnica sin entender el negocio termina mal. En esta fase, nuestro consultor funcional se sienta con tu equipo (negocio + IT) para responder a tres preguntas clave:

  • ¿Qué procesos de negocio que la aplicación VB6 soporta hoy ya no son válidos o han cambiado? Migrar tal cual procesos obsoletos es desperdiciar presupuesto.
  • ¿Qué funcionalidades nuevas necesita la aplicación migrada? Aquí decidimos qué metemos en el alcance y qué dejamos para una fase posterior.
  • ¿Qué KPIs o indicadores debe seguir mejorando la aplicación tras la migración? Tiempos de respuesta, concurrencia de usuarios, accesibilidad desde móvil, integración con un CRM concreto, etc.

Fase 3 — Diseño de la arquitectura objetivo

Decidimos contigo:

  • Plataforma destino: .NET Framework 4.8 (si necesitas compatibilidad máxima con tu entorno actual), .NET 8 LTS o .NET 9 (recomendado para proyectos nuevos).
  • Lenguaje: C# (recomendación por defecto, ecosistema más amplio) o VB.NET (si tu equipo seguirá manteniendo el código y prefieres minimizar la curva de aprendizaje).
  • Tipo de aplicación:
  • WinForms moderno (si quieres mantener la experiencia escritorio).
  • WPF (interfaz más rica, MVVM, mejor para aplicaciones con mucho data binding).
  • Blazor Server / Blazor WebAssembly (si quieres convertirla en aplicación web sin abandonar el ecosistema .NET).
  • MAUI (si necesitas multiplataforma: Windows + macOS + móvil).
  • Capa de datos: Entity Framework Core, Dapper, o ADO.NET puro según el caso.
  • Patrones: Clean Architecture, MVC, MVVM, microservicios si tiene sentido (no siempre lo tiene).
  • Estrategia de despliegue: on-premise, cloud (Azure preferentemente, también AWS), híbrida.

Documentamos todo en un ADR (Architecture Decision Record) que se entrega al cliente y queda como referencia.

Fase 4 — Preparación del código VB6

Antes de migrar conviene reducir y estabilizar el código origen:

  • Eliminamos código muerto detectado en la Fase 1.
  • Refactorizamos los módulos que sabemos que son problemáticos (parámetros As Any, arrays dinámicos sin tipo, llamadas COM tardías).
  • Sustituimos referencias a controles obsoletos por equivalentes que sí tienen mapeo claro a .NET.
  • Aplicamos el VB6 Code Advisor de Microsoft (sí, sigue funcionando) para identificar puntos críticos.

Esta fase no siempre se hace si el cliente prefiere “tocar lo mínimo” del original; lo recomendamos pero no es obligatorio.

Fase 5 — Migración modular controlada

Aquí está la diferencia con las herramientas mágicas. Migramos por módulos, no de golpe. Para cada módulo:

  1. Conversión semi-automática del código (usamos VBUC de Mobilize.Net, VB Migration Partner de Code Architects o herramientas propias según convenga al cliente).
  2. Revisión manual línea a línea por un desarrollador senior.
  3. Sustitución de las referencias problemáticas (ActiveX → .NET equivalent, ADO → Entity Framework Core o Dapper, Crystal Reports → Crystal for .NET, Microsoft Reporting o un motor moderno).
  4. Pruebas unitarias en xUnit/NUnit del módulo migrado.
  5. Pruebas de integración contra el resto del sistema (que aún puede tener módulos en VB6 corriendo en paralelo gracias a interop COM).
  6. Entrega del módulo migrado al cliente para validación funcional.

Este enfoque iterativo, inspirado en el patrón Strangler Fig, permite que la aplicación nunca esté “rota”: siempre hay una versión funcional, y vamos sustituyendo módulos uno a uno.

Fase 6 — Pruebas funcionales y de aceptación

  • UAT (User Acceptance Tests) con casos de uso reales aportados por el cliente.
  • Comparación de outputs entre la aplicación VB6 original y la nueva versión .NET sobre los mismos datos de entrada (test de paridad funcional).
  • Pruebas de rendimiento: tiempos de respuesta bajo carga, consumo de memoria, concurrencia.
  • Pruebas de seguridad: análisis estático con SonarQube, detección de vulnerabilidades, revisión de manejo de credenciales.

Fase 7 — Despliegue, formación y soporte

  • Despliegue en entorno productivo (on-premise, Azure App Service, IIS, contenedores Docker, Kubernetes — lo que aplique).
  • Formación al equipo de IT del cliente: cómo está estructurado el nuevo código, cómo desplegar, cómo depurar.
  • Soporte post-migración: 3, 6 o 12 meses según contrato. Bug-fixing, ajustes funcionales menores, resolución de incidencias.
  • Documentación técnica completa entregada (arquitectura, decisiones, manual de operación).

Modalidades de servicio

Ofrecemos cuatro modalidades según las necesidades del cliente:

01

Migración 1:1 (más rápida y económica)

Convertimos VB6 a .NET preservando exactamente la misma interfaz, los mismos formularios, el mismo comportamiento. El usuario final no nota ningún cambio. Ideal si tu prioridad es eliminar el riesgo de VB6 sin tocar la experiencia del usuario.

02

Migración + UI moderno

Convertimos el código y simultáneamente rediseñamos la interfaz: ribbon-bar, navegación moderna, modo oscuro, accesibilidad WCAG, controles redimensionables, layouts adaptativos. La aplicación se siente actual.

03

Migración + Web​

Convertimos la aplicación de escritorio en aplicación web moderna (Blazor o ASP.NET Core MVC). El usuario accede desde navegador, móvil, tablet. Ideal para empresas que quieren ofrecer SaaS o acceso remoto seguro

04

Migración integral (todo en uno)

Migración + UI moderno + arquitectura web + integración con sistemas modernos (CRM, ERP, pasarela de pago, APIs). Es el proyecto más ambicioso y el que más valor entrega.

Cómo gestionamos los componentes problemáticos

Esta sección responde a las preguntas técnicas reales que se hacen los responsables de IT cuando llaman para pedir presupuesto. Si vienes hasta aquí, probablemente tu aplicación tiene al menos uno de los siguientes elementos.

Controles ActiveX y OCX

El problema: VB6 usa intensivamente controles ActiveX (.ocx) propios y de terceros. Muchos fabricantes ya no existen, y los que existen pueden no tener una versión .NET equivalente. El motor de formularios de VB6 no tiene relación directa con WinForms ni con WPF.

Cómo lo resolvemos:

  • Inventario completo de todos los OCX referenciados en el proyecto.
  • Para cada control, una de cuatro estrategias:
    • 1. Sustitución directa por un control nativo .NET equivalente (ej. MSFlexGrid → DataGridView o DataGrid de WPF).
    • 2. Sustitución por un control comercial moderno con mapeo cercano (Telerik, DevExpress, Syncfusion).
    • 3. Wrapping COM-Interop temporal: si el control no se puede sustituir de inmediato, lo mantenemos vía COM Interop mientras se desarrolla el reemplazo. No es la solución final, pero permite la migración en fases.
    • 4. Reescritura del control desde cero en .NET si es un control crítico y propio.

Nuestra recomendación general: huir del COM Interop como solución permanente. Funciona, pero arrastra todos los problemas de VB6 que se quería abandonar.

Crystal Reports

El problema: muchísimas aplicaciones VB6 usan Crystal Reports (versiones 8, 9, 10, 11) para imprimir informes, facturas, listados. Estas versiones antiguas de Crystal ya no son soportadas, dependen de runtime obsoletos y no se llevan bien con sistemas operativos modernos.

Cómo lo resolvemos (cuatro caminos):

  1. Migración a Crystal Reports for Visual Studio: actual, soportada por SAP, sintaxis de informes muy similar. La conversión de los .rpt antiguos suele funcionar con ajustes menores. Recomendado si tienes muchos informes y quieres cambiar lo mínimo.
  2. Migración a Microsoft Reporting Services (RDLC): gratuito, integrado con Visual Studio, perfecto si vas a desplegar en entorno Microsoft. Requiere rehacer los informes desde cero, pero el resultado es más mantenible.
  3. Migración a un motor moderno como QuestPDF, JasperReports.NET o Stimulsoft: más flexible, mejor para escenarios web/cloud.
  4. Migración a Power BI / Reporting embebido: si los informes son más analíticos que operativos, a veces conviene replantear el enfoque entero.

Documentamos cada informe con su origen, destino, parámetros, joins, agrupaciones y formatos antes de migrarlo, para que el output sea idéntico al original.

Acceso a datos (ADO, DAO, RDO) 

El problema: VB6 utiliza ADO (mayoritariamente), DAO o RDO. En .NET la capa de datos ha evolucionado: ADO.NET, Entity Framework, Entity Framework Core, Dapper, micro-ORMs.

Cómo lo resolvemos:

  • ADO clásico → ADO.NET: conversión casi mecánica, funciona pero no es lo recomendable a largo plazo.
  • ADO clásico → Entity Framework Core: refactor más profundo, pero el resultado es código tipado, mantenible, con migrations versionadas. Recomendado para proyectos que vayan a evolucionar.
  • ADO clásico → Dapper: punto medio, código SQL explícito pero con tipado .NET. Excelente para aplicaciones con consultas complejas y mucho rendimiento.
  • DAO/Access → SQL Server / PostgreSQL + EF Core: si tu aplicación aún usa Microsoft Access como base de datos, casi siempre conviene migrar también la BD. La hacemos en paralelo.

Aplicamos siempre consultas parametrizadas (los desarrollos VB6 tradicionales suelen ser vulnerables a SQL injection por concatenación de cadenas) y revisamos la gestión de transacciones.

Llamadas a la API Win32 (Declare ... Lib "user32")

El problema: muchos programas VB6 tienen docenas de declaraciones Declare Function ... Lib "user32" ... para acceder a funcionalidad del sistema operativo no expuesta directamente por VB6.

Cómo lo resolvemos:

  • Sustitución por equivalentes del .NET Framework: el 80% de las llamadas Win32 tradicionales tienen equivalente directo en System.Windows.Forms, System.IO, System.Drawing, etc.
  • P/Invoke (DllImport) para el 20% restante: cuando no hay equivalente, mantenemos la llamada nativa con la sintaxis moderna de .NET. Documentamos cada P/Invoke con su justificación.
  • Revisamos especialmente las declaraciones con parámetros As Any: en VB6 era habitual y en .NET requiere refactor (no existe el tipo Any).

Eventos COM y servidores ActiveX EXE

El problema: aplicaciones VB6 sofisticadas a veces tienen un servidor ActiveX EXE como núcleo de comunicación entre módulos, manejando contextos compartidos. Esto fue uno de los desafíos del caso público de Maginus migrado por fecher: dependía de un ActiveX server para context-switching entre aplicaciones manteniendo el cliente activo.

Cómo lo resolvemos:

  • Sustitución por patrones de mensajería .NET: MediatR, eventos del dominio, message bus interno.
  • Para escenarios distribuidos: gRPC, SignalR (real-time), o un broker como RabbitMQ.
  • Si la lógica es compleja, a veces conviene mantener temporalmente el ActiveX server y migrar el resto, integrando vía COM Interop. No es bonito pero permite avanzar.

Bases de datos Microsoft Access

Si tu aplicación VB6 usa Access (.mdb o .accdb), casi siempre conviene migrar también la base de datos a SQL Server, PostgreSQL o MySQL. Lo hacemos en paralelo:

  • Análisis del esquema Access (tablas, relaciones, consultas, formularios — los formularios Access se descartan).
  • Generación del esquema en la nueva BD.
  • Migración de datos con scripts repetibles y validación cruzada.
  • Conversión de consultas QBE/SQL Access a T-SQL/PL-pgSQL.
  • Pruebas de integridad referencial post-migración.
Necesito un servicio de migración

CASI DI SUCCESSO

Migración VB6 a .NET 8 en empresa industrial española

Cliente y contexto

Empresa industrial española del sector metalmecánico con sede en la Comunidad de Madrid, 180 empleados, facturación de 32 M€ anuales. Su sistema central de gestión — fabricación, control de stock, OF (órdenes de fabricación), trazabilidad de producto y facturación — fue desarrollado en Visual Basic 6 entre 2001 y 2004, y se siguió manteniendo internamente durante 21 años. Volumen del código: 685.000 líneas de código efectivas (ELOC) repartidas en 14 proyectos VB6 interconectados.

Punto de partida

El cliente nos contactó tras la jubilación inesperada del desarrollador senior que mantenía el sistema. La aplicación corría en un Windows Server 2008 R2 virtualizado (también fuera de soporte). Una auditoría de seguridad reciente había detectado 17 hallazgos críticos y el departamento de Compliance daba 18 meses para regularizar la situación. Pidieron presupuesto a cuatro proveedores. Eligieron Impulsa3.

Stack original

  • Visual Basic 6.0 SP6
  • Crystal Reports 9 (47 informes)
  • 23 controles ActiveX (12 propios, 11 de terceros, de los cuales 4 fabricantes ya no existían)
  • 8 declaraciones Declare Function a user32.dll y kernel32.dll
  • ADO 2.8 contra SQL Server 2008 R2
  • Una DLL propia en C++ no documentada (¡siempre hay sorpresas!) que gestionaba la comunicación con la maquinaria de planta vía protocolo serie RS-232/RS-485.

Stack destino

  • C# y .NET 8 LTS
  • WPF (escritorio) + componente Blazor para el dashboard de producción accesible desde tablets en planta
  • Entity Framework Core 8 contra SQL Server 2022
  • Crystal Reports for Visual Studio (manteniendo los 47 .rpt con ajustes)
  • Sustitución de los 23 ActiveX por: 14 controles nativos WPF, 7 controles Telerik, y 2 wrappers temporales mantenidos durante la fase 1 (eliminados en fase 2)
  • API REST en ASP.NET Core 8 expuesta para integración futura con su nuevo CRM (HubSpot)
  • La DLL en C++ se mantuvo, accedida ahora vía P/Invoke documentado

Cifras del proyecto

 

IndicadorValor
Líneas de código origen (ELOC)685.000
Líneas de código destino (C#)412.000
Reducción por refactor y eliminación de código muerto-39,8 %
Duración del proyecto11 meses
Equipo dedicado1 PM + 4 desarrolladores senior + 1 QA + 1 arquitecto a tiempo parcial
Modalidad de pagoPrecio cerrado por hitos
Fase de soporte post-migración6 meses incluidos
Downtime durante el cutover final14 horas (un fin de semana)
Bugs críticos detectados en los 6 meses de soporte7 (todos resueltos en SLA)

Resultados a 12 meses

  • Tiempos de respuesta del sistema: -64% en consultas frecuentes, -41% en informes pesados (gracias a EF Core con queries optimizadas y nuevos índices en la BD).
  • Disponibilidad: pasó de 97,2% (con la VM antigua) a 99,8% (en el nuevo despliegue Azure híbrido).
  • Cumplimiento normativo: los 17 hallazgos críticos cerrados.
  • Reducción del coste de mantenimiento anual: -52% según contabilidad analítica del cliente, principalmente por eliminación del coste-hora premium del desarrollador VB6 y reducción de incidencias.
  • Nuevas funcionalidades habilitadas: integración con HubSpot CRM, dashboard móvil para responsables de planta, exportación automática a Power BI, autenticación Azure AD.
  • Estimación de coste de reescritura desde cero: que el cliente había recibido era de 890.000 €. El proyecto Impulsa3 se cerró en 318.000 €. Ahorro: 64% sobre la alternativa de reescribir desde cero, manteniendo el 100% de la lógica de negocio probada durante 21 años.

Cita de nuestro cliente

“Lo que más nos sorprendió fue que el equipo de Impulsa3 entendía nuestro código VB6 mejor que nuestro propio mantenedor histórico. Detectaron lógica de negocio que ni siquiera sabíamos que existía. La migración no fue una traducción mecánica, fue una arqueología técnica que nos ha dejado una aplicación moderna sin perder nada de lo que funcionaba.” — Propietario, empresa cliente (referencia disponible bajo NDA)

¿Herramienta automática o migración profesional?

Esta es una de las preguntas más habituales que recibimos: “¿No basta con usar una herramienta automática y ahorrarme la consultora?”. Veamos qué hace cada cosa.

Las herramientas automáticas más conocidas

  • Microsoft Visual Basic Upgrade Wizard (incluido en Visual Studio 2003-2008): histórico, descontinuado en versiones nuevas. Convierte código pero el resultado normalmente no compila sin trabajo manual. Funciona razonablemente para proyectos pequeños y simples.
  • Visual Basic Upgrade Companion (VBUC) de Mobilize.Net: comercial. Conversión más sofisticada, soporta análisis de proyectos grandes, genera informes de diagnóstico. Conversiones declaradas del 80-95%. Buena opción como apoyo, no como solución completa.
  • VB Migration Partner de Code Architects: comercial. Excelente compatibilidad con ActiveX, DAO, APIs personalizadas. Permite migración por fases con interoperabilidad VB6/.NET durante la transición. Caso público: migración de SiS de 950.000 líneas en 9 meses.
  • GAPVelocity AI Migrator: la nueva generación, con IA generativa. Conversiones más adaptativas, mejor manejo de edge cases. Coste por línea de código.
  • Microsoft .NET Upgrade Assistant + Visual Studio 2008: el camino oficial recomendado por Microsoft hoy para conversiones VB6 → .NET. Combina lo viejo y lo nuevo.

Qué hacen bien las herramientas

  • Convertir sintaxis trivial (declaraciones de variables, bucles, condicionales, llamadas a métodos): ~70-90% de éxito en proyectos típicos.
  • Generar el esqueleto del proyecto .NET equivalente.
  • Mapear controles intrínsecos básicos (TextBox, Label, Button, Form).
  • Acelerar el trabajo de un equipo experto que sabe qué revisar después.

Qué NO hacen las herramientas

  • Entender tu lógica de negocio. La herramienta convierte código, no comprende el “por qué” de cada decisión. Bugs lógicos disfrazados de “comportamientos esperados” se propagan tal cual.
  • Decidir qué refactorizar y qué dejar igual. Las herramientas convierten todo con el mismo criterio, perpetuando la mala arquitectura original.
  • Sustituir controles ActiveX que ya no existen. Las herramientas dejan referencias rotas que hay que resolver manualmente.
  • Migrar Crystal Reports antiguos. Eso es un proyecto aparte.
  • Refactorizar la capa de datos. La conversión ADO → ADO.NET o EF Core requiere decisiones de arquitectura humanas.
  • Sustituir el modelo de eventos VB6 por uno moderno (async/await, eventos del dominio, MVVM).
  • Hacer pruebas funcionales. Compilable ≠ funcional.
  • Aportar garantía de proyecto a precio cerrado.

La regla práctica que aplicamos en Impulsa3

Para proyectos por debajo de ~50.000 líneas de código y sin ActiveX exóticos, una herramienta + un par de semanas de trabajo manual de un buen desarrollador puede funcionar. Es una migración tipo “kit”.

Para proyectos por encima de ~100.000 líneas, con dependencias complejas (Crystal Reports, ActiveX de terceros descatalogados, integración con hardware, lógica de negocio crítica), la herramienta es un acelerador, no una solución. Sin un equipo que entienda VB6, .NET y tu negocio, el resultado es siempre malo.

Y entre ambos extremos hay un mundo gris donde el análisis previo decide. Por eso nuestro análisis inicial es gratuito: a veces aconsejamos al cliente hacerlo ellos mismos con una herramienta + soporte puntual, en lugar de venderles un proyecto completo. Preferimos un cliente bien aconsejado a un proyecto mal vendido.

Necesito un servicio de migración

Preguntas frecuentes — FAQ

Depende fundamentalmente de tres factores: tamaño del código (líneas efectivas), complejidad (controles ActiveX, integraciones, reportes, lógica de negocio) y alcance funcional (migración 1:1 vs. modernización completa con UI nueva y web).

Como referencias orientativas para el mercado español:

  • Aplicación pequeña (< 30.000 ELOC, sin ActiveX exóticos, < 10 informes Crystal): 15.000-40.000 €.
  • Aplicación media (30.000-150.000 ELOC, algunos ActiveX, reportes, integración con BD SQL Server): 40.000-150.000 €.
  • Aplicación grande (150.000-500.000 ELOC, dependencias complejas, hardware, varios módulos): 150.000-450.000 €.
  • Aplicación muy grande (>500.000 ELOC, alta complejidad): proyecto a medida, generalmente entre 400.000 € y 1,2 M€.

El análisis previo gratuito te da un rango ajustado a tu caso concreto.

Para proyectos típicos en el rango medio (50.000-200.000 ELOC), entre 6 y 14 meses de calendario. La duración no es lineal con el tamaño porque depende mucho de la complejidad. Una aplicación de 100.000 líneas con 30 ActiveX descatalogados puede tardar más que una de 250.000 líneas limpia.

Lo que sí garantizamos es que el proyecto avanza por hitos visibles y que la aplicación nunca queda “rota”: migramos por módulos.

No. Trabajamos en paralelo. Tu aplicación VB6 sigue en producción mientras nosotros migramos. El único momento de parada controlada es el cutover final, normalmente un fin de semana, cuando se sustituye la versión vieja por la nueva. Para aplicaciones críticas 24×7 podemos plantear migración blue-green con cero downtime.

Hacemos inventario de cada uno y aplicamos una de cuatro estrategias: sustitución por control nativo .NET, sustitución por control comercial moderno (Telerik, DevExpress, Syncfusion), wrapping COM-Interop temporal, o reescritura del control desde cero. Lo decidimos en la fase de análisis tras evaluar el coste-beneficio de cada opción.

Migrarlos es parte estándar del proyecto. Las opciones son: Crystal Reports for Visual Studio (mantienes el .rpt con ajustes), Microsoft Reporting Services (rehacer en RDLC), o un motor moderno (QuestPDF, Stimulsoft, Telerik Reporting). Decidimos contigo en función del número de informes, su complejidad y dónde se ejecutarán (escritorio, web, servidor).

Por defecto: .NET 8 LTS para proyectos nuevos. Es la versión Long-Term Support con soporte hasta noviembre de 2026, ampliamente probada y con todo el ecosistema disponible.

.NET 9 si quieres lo último (lanzado noviembre 2024) y no necesitas LTS.

.NET Framework 4.8 sólo cuando hay dependencias del cliente que lo exigen (por ejemplo, otros sistemas internos que aún no se pueden actualizar).

Recomendamos C# por defecto. Razones: el ecosistema .NET evoluciona empujado principalmente por C#, hay mucho más talento disponible, todas las novedades del lenguaje aparecen primero en C#, y la documentación es más abundante.

VB.NET sigue soportado, sigue compilando y sigue siendo válido. Si tu equipo va a mantener el código y tienen background VB, la curva de aprendizaje a VB.NET es más suave que a C#. En ese caso aceptamos VB.NET sin problema.

Lo que no recomendamos es una migración mixta (parte en VB.NET, parte en C#). Es factible (.NET es multi-lenguaje) pero genera deuda técnica innecesaria.

Sí, es la Modalidad 3 o Modalidad 4 de nuestro servicio. Convertimos la aplicación a Blazor (Server o WebAssembly) o a ASP.NET Core MVC + frontend SPA. La aplicación pasa a estar accesible desde navegador, móvil y tablet. Esto suele requerir un rediseño parcial de la experiencia de usuario porque los paradigmas escritorio y web son distintos, pero el resultado vale la pena: deployment centralizado, acceso remoto, integración con el resto del ecosistema cloud.

Sin problema. .NET tiene mejor soporte de hardware industrial que VB6 hoy. Trabajamos con protocolos RS-232, RS-485, USB-HID, Modbus, OPC-UA, MQTT. Si tu aplicación VB6 ya hablaba con la maquinaria mediante una DLL en C++, normalmente la mantenemos accesible vía P/Invoke. Si era código VB6 propio, lo reescribimos en C#.

Sí. Ofrecemos el análisis técnico de viabilidad como servicio independiente (de pago, no el inicial gratuito que es comercial). Te entregamos el informe completo con inventario, estimación de horas y riesgos, y lo usas como pliego para licitar entre proveedores. Garantizamos imparcialidad: no condicionamos el informe a que nos contrates después.

No. Tenemos sede en Madrid pero trabajamos con clientes de toda España y, ocasionalmente, internacionales (cuando hay equipo del cliente que habla español). Modalidad de trabajo: mixta presencial/remota. En proyectos grandes, presencia en cliente al menos 1-2 días al mes.

Por supuesto. Firmamos NDA antes de cualquier intercambio de código fuente o documentación sensible. Si tu empresa tiene un modelo propio de NDA, lo revisamos y firmamos. Si no, te enviamos el nuestro.

No. Todos nuestros proyectos incluyen fase de soporte post-migración de 3, 6 o 12 meses según contrato, donde resolvemos bugs, hacemos ajustes funcionales menores y atendemos incidencias. Después de esa fase, ofrecemos contrato de mantenimiento evolutivo para clientes que prefieren externalizar el mantenimiento, o traspaso completo del conocimiento a tu equipo si prefieren internalizarlo (con documentación, sesiones de formación y código en orden).

Tenemos en el equipo desarrolladores que trabajaron profesionalmente con VB6 entre 1998 y 2010, antes de que Microsoft retirara el soporte. Conservamos entornos de desarrollo VB6 funcionales (en máquinas virtuales con licencias originales) para análisis de código heredado. Y mantenemos un stack de conocimiento sobre el lenguaje, sus particularidades y los problemas típicos de migración. En 20+ años hemos visto prácticamente todo.

Sí. Trabajamos bajo RGPD y LOPDGDD. Para clientes del sector público adaptamos los entregables al Esquema Nacional de Seguridad (ENS). Si tu empresa está sujeta a NIS2 o DORA, integramos los requisitos en el diseño de la nueva aplicación (logging, auditoría, cifrado, gestión de identidades). Tenemos experiencia con auditorías ISO 27001.