Prolongar la vida útil o migrar aplicaciones VB6 / Access — Tabla de decisión: mantener, envolver o reemplazar

«Parte del núcleo del sistema todavía funciona en VB6» o «el libro de registros hecho en Access en realidad sostiene el trabajo de un departamento entero»: en las consultas con pequeñas y medianas empresas, estas dos situaciones siguen apareciendo con bastante frecuencia hoy en día. Lo que tienen en común es que la persona que las creó ya se ha ido de la empresa, o que nadie puede explicar con precisión por qué siguen funcionando. Aun así, como no se rompen y siguen funcionando, la prioridad para atenderlas tiende a quedar relegada.

En este blog ya hemos tratado elementos técnicos concretos: qué es COM / ActiveX / OCX, la tabla de decisión de mantener, envolver o reemplazar para ActiveX / OCX, y las limitaciones y el futuro de VBA. En este artículo acotamos el alcance y reunimos una guía práctica sobre dos grandes activos heredados que siguen muy presentes hoy en las pequeñas y medianas empresas japonesas —las aplicaciones VB6 y las aplicaciones de negocio en Microsoft Access— para decidir si «mantenerlas tal cual», «envolver solo una parte para prolongar su vida útil» o «reemplazarlas». El esquema de decisión sigue siendo el mismo trío de «mantener, envolver o reemplazar» que usamos en el artículo de ActiveX / OCX, pero como el objeto cambia, también cambia el contenido de los riesgos, así que aquí nos centramos en los puntos propios de este caso.

Para leer este artículo solo hacen falta dos premisas. La primera es que tanto VB6 como Access son tecnologías centradas en 32 bits que se apoyan en COM (ActiveX / OCX), por lo que su encaje con el Windows y el Office actuales, ya en 64 bits, tiende a generar problemas. La segunda es que usamos como esquema de decisión el trío «mantener, envolver o reemplazar». A lo largo del texto iremos enlazando explicaciones detalladas de tecnologías concretas como COM o VBA, pero si prefiere leerlas todas juntas como conocimiento previo, están recogidas al final en «Artículos relacionados», así que en una primera lectura puede seguir el texto de principio a fin sin seguir esos enlaces.

1. Conclusión inicial

• El IDE / entorno de desarrollo de VB6 en sí dejó de recibir soporte oficial en abril de 2008. Ya no se ofrece ningún medio oficial para hacer desarrollo nuevo o modificaciones.¹
• En cambio, el runtime de VB6 (como msvbvm60.dll) sigue funcionando durante el período de soporte de la versión de Windows en la que viene incluido. La premisa de que «las aplicaciones VB6 existentes, en general, siguen funcionando en las versiones de Windows compatibles» sigue siendo válida hoy, pero está completamente subordinada al período de soporte del lado de Windows.¹
• VB6 es exclusivo de 32 bits y no admite compilación nativa de 64 bits. En un sistema operativo de 64 bits funciona dentro de WOW64, el entorno de compatibilidad de 32 bits.¹ En cuanto surge la necesidad de conectar con un DLL, SDK o componente COM exclusivo de 64 bits, deja de ser posible resolverlo dentro de un único proceso.
• El «Access Database Engine (ACE)», que lee y escribe los archivos .mdb / .accdb de Access, también tiene sus propias ataduras de 32/64 bits. En un mismo equipo solo puede instalarse una de las dos versiones, y debe coincidir con los bits de Office.² Como desde Office 2019 / Microsoft 365 la instalación predeterminada pasó a ser de 64 bits, las aplicaciones de Access y los componentes ActiveX creados bajo la premisa antigua de 32 bits pueden dejar de funcionar en cuanto se cambia a un equipo nuevo.³⁴
• Que varias personas abran a la vez un .accdb en una carpeta compartida sigue siendo habitual hoy en día, pero es un factor de riesgo de corrupción y de bajo rendimiento. Se indica que la escritura a través de la red puede derivar en corrupción de datos si la conexión se vuelve inestable.⁵ Cuando el tamaño del libro de registros o el número de usuarios simultáneos aumenta, llega el momento de considerar un ascenso de escala hacia SQL Server u otra plataforma.
• El eje de la decisión es el mismo que en el caso de ActiveX / OCX: si el activo es una simple pantalla o un límite que contiene lógica de negocio y datos. Si funciona de forma estable y su alcance está cerrado, se mantiene; si solo se quiere modernizar una parte, se envuelve; si las limitaciones de la interfaz o de la plataforma de ejecución frenan el negocio, se reemplaza, en ese orden de razonamiento.
• En este artículo, «envolver» significa no tocar el activo antiguo en sí, sino preparar a su alrededor una nueva interfaz (un servidor COM en otro proceso, tablas vinculadas hacia SQL Server, una API web, etc.) para que desde fuera pueda tratarse como un mecanismo nuevo. Como no se reconstruye el contenido, el esfuerzo es fácil de estimar, y se usa como punto de aterrizaje temporal para modernizar primero las partes de mayor riesgo (capítulo 8).

2. Situación actual de VB6 — el runtime sigue vivo, pero sin respaldo de desarrollo

Empecemos por dejar clara la premisa. Microsoft declaró, con fecha del 8 de abril de 2008, que «el IDE de Visual Basic 6.0 (y el IDE de Visual Studio 6.0) queda fuera de soporte», y deja clara su postura: ya no se ofrece ningún medio oficial para crear o mantener aplicaciones VB6, y se recomienda encarecidamente reemplazarlas por tecnologías modernas.¹

Por otro lado, en el mismo comunicado también se indica que el runtime de VB6 sigue siendo objeto de soporte durante el período de soporte de la versión de Windows en la que viene incluido. Se espera que las aplicaciones VB6 existentes «sigan funcionando tal cual» en las versiones de Windows compatibles, y se aclara que el alcance de ese soporte se limita a regresiones graves y a problemas de seguridad importantes.¹ Es decir, se puede esperar como mínimo que «no se rompa al instalarla en un Windows nuevo», pero no hay soporte en el sentido de «que añadan funciones o investiguen un caso concreto cuando surja un problema».

Otro punto que pesa en la práctica es que el runtime de VB6 es un archivo exclusivamente de 32 bits, y en un sistema operativo de 64 bits solo recibe soporte dentro de WOW64, el entorno de emulación de 32 bits.¹ Esto significa que «las aplicaciones VB6 solo podrán seguir existiendo como procesos de 32 bits de aquí en adelante». Cuando surge la necesidad de usar un SDK de instrumentación exclusivo de 64 bits o una nueva biblioteca criptográfica, en principio no es posible cargarlo directamente en el proceso de VB6. En la práctica, la única forma de superar esta barrera es «extraerlo a otro proceso y conectarlo», y la configuración concreta puede tomarse tal cual del artículo «Ejemplo real de un puente COM que llama a un DLL de 64 bits desde una aplicación de 32 bits». El razonamiento es el mismo cuando el puente se usa desde una aplicación VB6: la funcionalidad de 64 bits queda encerrada en un servidor COM fuera de proceso o en un EXE auxiliar, y el lado VB6 se limita a invocarlo.

La mayoría de las aplicaciones VB6 incorporan controles ActiveX / OCX como componentes de pantalla. La decisión de mantener, envolver o reemplazar esos componentes en sí se trata en detalle en «Cómo tratar hoy ActiveX / OCX», así que para decidir sobre cada control incrustado dentro de una aplicación VB6 consulte ese artículo. Aquí nos centramos en la decisión de un nivel superior: cómo tratar la aplicación VB6 en su conjunto.

3. Situación actual de Access — el formato de archivo, los bits de ACE y la realidad de las carpetas compartidas

3.1 .mdb / .accdb y los bits de ACE

Los datos de Access se guardan en archivos .mdb (formato antiguo) o .accdb (desde 2007), y el componente de runtime que los lee y escribe es el Access Database Engine (ACE, sucesor de Jet). Un problema muy frecuente en la práctica es la incompatibilidad de bits. El proveedor OLE DB de Jet tradicional solo se ofrece en versión de 32 bits, y aunque ACE está disponible tanto en 32 como en 64 bits, se indica que en un mismo equipo solo puede instalarse una de las dos versiones, y debe coincidir con los bits del Office instalado en ese equipo.² Del lado de Visual Studio también se documenta que, desde que Visual Studio 2022 pasó a ser un proceso de 64 bits, hay herramientas de datos que usan el proveedor de Access de 32 bits y que dejan de poder conectarse.⁶

Lo que complica aún más las cosas es el cambio en el valor predeterminado del lado de Office. Office 2010 a 2016 instalaba por defecto la versión de 32 bits, pero desde Office 2019 y Microsoft 365 la instalación predeterminada pasó a ser la versión de 64 bits.³ Además, como el proceso de Office de 64 bits no puede cargar binarios de 32 bits, los controles ActiveX y los complementos COM de 32 bits que ya existían no funcionan tal cual en un Office de 64 bits.⁴ Es decir, muchos de los incidentes del tipo «llevábamos años usando la misma aplicación de Access y, al cambiar de PC, de repente dejó de funcionar» tienen como causa que los bits de Office cambiaron por defecto y que ACE y los controles incrustados no pudieron seguir ese cambio. El procedimiento para diagnosticar este tipo de incidentes está recogido en «Causas y pasos de comprobación cuando ActiveX no funciona en Office 2024/Microsoft 365».

Como es fácil confundirse sobre «quién queda atado a los bits de quién», dejamos las dependencias en una tabla (el fundamento de cada fila es el que se cita en esta sección y en el capítulo 2).

El orden vertical de la tabla es, literalmente, la ruta por la que se propaga un incidente. Cuando cambian los bits de Office (primera fila), se ven afectados a la vez ACE, los componentes que carga Access y las aplicaciones propias que se conectan a ellos. El primer punto que siempre hay que comprobar antes de renovar un equipo es: «¿de cuántos bits es el Office del equipo nuevo?».

3.2 El riesgo del uso multiusuario en carpetas compartidas

Otra configuración habitual en las aplicaciones de Access es que varias personas abran a la vez un .accdb situado en una carpeta compartida. A pequeña escala puede funcionar sin problemas durante años, pero se trata de una configuración inherentemente frágil. Se indica que la escritura a través de la red puede provocar fallos de escritura o corrupción del archivo si la conexión se vuelve inestable,⁵ y también se conocen desde hace tiempo casos en los que Access reporta un error de disco o de red cuando el acceso al servidor de archivos se retrasa o expira por tiempo de espera.⁷ El germen de la corrupción es, en esencia, el acceso simultáneo a un archivo compartido, una estructura muy parecida al patrón de conflicto que tratamos en «Conceptos básicos del control de exclusión en la integración de archivos» de este blog. Access incorpora un control de exclusión mediante un archivo de bloqueo (.laccdb), pero cuantas más «rutas propensas a la inestabilidad de conexión» existan —portátiles por Wi-Fi, teletrabajo a través de VPN, reconexión tras salir del modo de suspensión—, mayor es la tasa de incidentes.

La vía de escape habitual cuando aumenta el número de usuarios simultáneos o el procesamiento se vuelve pesado es trasladar las tablas de Access a SQL Server o Azure SQL, y hacer que Access las referencie como tablas vinculadas. Usando herramientas como SQL Server Migration Assistant (SSMA), tras migrar las tablas de Access y sustituir las tablas originales por vínculos a las tablas de destino, se puede trasladar solo los datos a una base más robusta manteniendo intactas las pantallas (formularios, informes, consultas).⁸ Sin embargo, se sabe que la vinculación de tablas trae problemas propios de después de la migración, como consultas de agregación que se vuelven lentas (si dependen de funciones que no pueden ejecutarse en el servidor, Access baja toda la tabla localmente antes de procesarla) o cambios en el comportamiento de las columnas de autonumeración, lo que a veces obliga a sustituirlas por consultas de paso a través o por vistas.⁸ Además, desde hace tiempo se recomienda dividir las aplicaciones de Access en una base de datos «back-end» que contiene las tablas y una base de datos «front-end» que contiene pantallas, consultas y macros.⁹ Lo importante aquí es que dividir por sí solo no basta. La configuración correcta consiste en dejar solo el back-end (las tablas) en la carpeta compartida, y copiar el front-end en el equipo de cada usuario para que cada uno lo use desde su copia local. Si incluso el front-end sigue siendo un único archivo en la carpeta compartida que todos abren a la vez, aunque esté dividido persiste el riesgo de que «pantallas, consultas y macros se lean y escriban simultáneamente sobre un archivo compartido», lo que provoca problemas como tiempos de apertura cada vez más largos o conflictos al cambiar el diseño. Tanto si se opta por prolongar la operación en carpeta compartida como si se migra hacia SQL Server, el primer punto de control es comprobar si ya se cumplen las dos condiciones: «el back-end está compartido» y «el front-end está desplegado en cada equipo».

Representado en un diagrama queda así. Las líneas continuas muestran la situación actual (vínculo al back-end en la carpeta compartida) y las líneas discontinuas, el destino de la migración cuando aumenta el uso simultáneo.

flowchart TB
    subgraph CLIENTS["Equipo de cada usuario ── colocar una copia por persona"]
        FE1["Front-end .accdb<br/>Formularios, consultas, informes, VBA"]
        FE2["Front-end .accdb<br/>Otra copia con el mismo contenido"]
    end
    BE["Back-end .accdb en la carpeta compartida<br/>Solo contiene las tablas"]
    SQL[("SQL Server / Azure SQL<br/>Destino cuando aumenta el uso simultáneo")]
    FE1 -->|"Tabla vinculada"| BE
    FE2 -->|"Tabla vinculada"| BE
    BE -.->|"Ascenso de escala (upsizing)"| SQL
    FE1 -.->|"Destino del vínculo tras la migración"| SQL
    FE2 -.->|"Destino del vínculo tras la migración"| SQL

Figura 1: la división entre back-end y front-end, y el paso posterior a un ascenso de escala. Colocar un único front-end en la carpeta compartida y dejar que todos lo abran es un error habitual. Al migrar, las pantallas (el front-end) se mantienen igual y solo se cambia el destino del vínculo a SQL Server.

4. Tabla de decisión

Organizando las aplicaciones VB6 y Access según su situación de uso y sus factores de riesgo, se puede decidir de la siguiente manera.

Como aclaración, en esta tabla «envolver» significa, en la mayoría de los casos, modernizar primero solo los datos o solo el límite, manteniendo por el momento la pantalla y la experiencia de uso. No se trata de reconstruirlo todo de una vez, sino de entenderlo como un punto de aterrizaje temporal para ir abordando primero las partes de mayor riesgo.

Para usar la tabla de decisión, primero acote la fila de «objeto» y luego compruebe si su situación coincide con la «situación de uso / factor de riesgo». Es importante que, aun tratándose de la misma aplicación VB6, está permitido separar la decisión por fila o por función —mantener una pantalla y envolver otra funcionalidad, por ejemplo—. Si se agrupa todo bajo «es una aplicación VB6, así que se trata igual», se arrastra incluso las partes estables que en realidad podrían mantenerse, y el esfuerzo se dispara.

5. Cómo aplicar la decisión según el escenario

Al aplicar la tabla de decisión a consultas reales, casi siempre converge en uno de estos tres patrones.

Escenario 1: una aplicación VB6 de gestión de inventario de uso interno, con requisitos de cambio pequeños. Si los equipos de destino están fijados a unas pocas máquinas y la configuración ni siquiera sale a la red, la tabla de decisión se inclina hacia «mantener». Aquí la respuesta práctica se reduce a ir acumulando, con constancia, las medidas de mitigación de riesgo del capítulo 7 (copias de seguridad, documentación, fijación del entorno de ejecución). A menos que exista una razón de peso para migrar a .NET, lo habitual es que la relación costo-beneficio no compense.

Escenario 2: un libro de registros de Access compartido por varios departamentos, con un número de usuarios que va en aumento. Es una consulta habitual: una aplicación de Access que hace unos años usaban 2 o 3 personas ha pasado, por la integración de departamentos o la ampliación del negocio, a tener un acceso simultáneo de unas 10 personas. En este caso, la tabla de decisión se inclina hacia «envolver». Primero hay que comprobar si ya se cumple lo del back-end compartido y el front-end desplegado localmente en cada equipo (sección 3.2); si no es así, hay que dividir y redesplegar antes que nada. Hecho esto, si aparecen indicios de corrupción o de bajo rendimiento (el tiempo de apertura se alarga, quedan archivos .laccdb residuales que no liberan el bloqueo, etc.), se migran las tablas a SQL Server y se cambia la configuración de Access para que las referencie como tablas vinculadas.⁸ Como las pantallas se pueden seguir usando casi tal cual, se puede reforzar solo la base de datos manteniendo bajo el costo de formación de los usuarios.

Escenario 3: una aplicación central en VB6 cuyo desarrollador ya se fue de la empresa, y hay demanda de pasarla a la web. En una situación en la que existe el código fuente pero nadie puede tocarlo, y además ha surgido la demanda de usarla desde fuera de la empresa, la tabla de decisión se inclina hacia «reemplazar». Sin embargo, cuanto más central es la aplicación, más alto es el riesgo de lanzarse directamente a una reescritura completa. Siguiendo el procedimiento del capítulo 9, lo realista es empezar por el inventario de la lógica de negocio y extraer primero las funciones de menor impacto, avanzando mediante una migración por etapas.

6. Antipatrones habituales

Antes de nada, compartimos los patrones de fracaso que se repiten en los proyectos de prolongación de vida útil y migración de VB6 y Access. Antes de aplicar la tabla de decisión, compruebe primero si su caso encaja en alguno de estos.

De todos estos, los dos que ocurren con más frecuencia son dejar sin resolver la mezcla de bits y dejar que crezca el número de usuarios en la carpeta compartida. Ninguno de los dos es un problema que «se rompe hoy»; ambos comparten el rasgo de que se manifiestan tarde o temprano, con un disparador que siempre acaba llegando, como una renovación de equipos o un aumento de usuarios.

7. Medidas realistas de mitigación de riesgo si se opta por mantener

Hay muchos casos en los que decidir mantener es realista, y en sí mismo no es un error. Sin embargo, cuanto más se prolongue el «no tocarlo porque funciona», más se acumula el riesgo de que nadie pueda explicar las premisas. Como mínimo, conviene atender lo siguiente.

• Automatizar la gestión de generaciones de copias de seguridad. Como el .accdb de Access se completa en un solo archivo, con solo hacer copias de seguridad generacionales a diario ya se puede absorber una buena parte de los incidentes. Para las aplicaciones VB6, hay que resguardar todo el código fuente (.vbp, .frm, .bas, .cls) junto con los OCX y DLL de los que depende y la información de registro necesaria.
• Documentar las premisas del entorno de ejecución como medida ante la ausencia de sucesor. Deje constancia del sistema operativo compatible, los bits de Office, el runtime necesario, las DLL de las que depende y los procedimientos de registro, al menos con el nivel de detalle suficiente para saber «qué comprobar cuando deje de funcionar en un PC nuevo».
• Fijar deliberadamente el entorno de ejecución. Como las actualizaciones automáticas de Windows u Office pueden cambiar los bits o la configuración predeterminada y disparar incidentes (sección 3.1), separe la política de actualizaciones de los equipos afectados y despliegue las actualizaciones solo después de haberlas verificado.
• Preparar pruebas de humo (smoke tests) en un entorno limpio. Tener un procedimiento que permita confirmar, en un entorno completamente limpio, que la instalación, el registro, el arranque y las operaciones principales funcionan antes de desplegar en un equipo nuevo reduce el tiempo perdido en el típico «debería funcionar pero no funciona» en cada despliegue.
• Concentrar los puntos de llamada en un solo lugar. En la medida de lo posible, evite dispersar por toda la aplicación las llamadas COM de VB6 o las referencias a tablas vinculadas de Access, y reduzca los puntos de entrada; así, cuando llegue el momento de envolver o reemplazar, el punto de partida quedará claro.

Como punto de atención propio de VB6, cabe mencionar también la conservación de la propia máquina de desarrollo. El medio de instalación y la licencia del IDE, la versión de desarrollador de los controles externos (OCX) necesarios para compilar y las notas del procedimiento de compilación son activos que se dispersan incluso más fácilmente que el entorno de ejecución. Aunque no haya planes de modificación a corto plazo, conservar un entorno (por ejemplo, una instantánea de máquina virtual) en el que la compilación se pueda reproducir amplía enormemente las opciones cuando llegue el momento de una pequeña modificación.

Si desea mantener o modificar software Windows existente sin romperlo, esto entra dentro del área de Modificación y mantenimiento de software Windows existente.

8. Opciones realistas si se opta por envolver

«Envolver» es el enfoque de encerrar el activo antiguo dentro de un límite estrecho y mostrarlo hacia el exterior como una nueva interfaz. En VB6 y Access, esto se reduce en general a estos tres patrones.

(a) Llamar a un componente COM de VB6 desde .NET mediante interoperabilidad COM. Si un módulo de clase escrito en VB6 se expone como un DLL ActiveX (o un EXE si es fuera de proceso), se puede invocar desde el lado de .NET mediante interoperabilidad COM. Como el lado VB6 sigue siendo de 32 bits, al llamarlo desde una aplicación .NET de 64 bits vuelve a aparecer la misma barrera de bits mencionada en el capítulo 2. La elección entre igualar el lado que llama a 32 bits o encerrar el componente en un proceso de 32 bits como servidor COM fuera de proceso puede resolverse aplicando, invertida, la configuración de «Ejemplo real de un puente COM que llama a un DLL de 64 bits desde una aplicación de 32 bits». Para las bases de COM en sí, consulte «Qué es COM / ActiveX / OCX».

(b) Trasladar por etapas la lógica VBA de Access a .NET o a la web. Dentro de las aplicaciones de Access conviven casos en los que la lógica de negocio está muy concentrada detrás de los formularios y casos en los que se limita a la simple entrada de datos o a listados. Lo realista es empezar por inventariar los módulos VBA, extraer primero la lógica de cálculo y validación pura que no depende de otros sistemas hacia una biblioteca de clases de .NET, y cambiar progresivamente para que el lado de Access la llame vía COM o a través de una API web intermedia. Los límites propios de VBA y hasta dónde conviene dejar la lógica en VBA se detallan en «Qué es VBA: limitaciones, futuro y cuándo conviene reemplazarlo».

(c) Reemplazar primero solo la interfaz, conservando los datos y la lógica. Si las quejas principales son que los formularios de Access son viejos, lentos o inaccesibles desde fuera de la empresa, existe la opción de reemplazar solo la interfaz por tecnología nueva, web o de escritorio, dejando intactas la capa de datos (tablas migradas a SQL Server) y la lógica. Combinado con la vinculación de tablas de la sección 3.2, también es posible un funcionamiento dual transitorio en el que «los datos están en SQL Server, y tanto la interfaz antigua (Access) como la nueva ven los mismos datos». Sin embargo, si el VBA del lado de Access acopla estrechamente la interfaz con la lógica, esta misma separación no es viable sin completar antes el inventario del punto (b).

Resumiendo las tres opciones, queda de la siguiente manera.

Si se encuentra en la etapa de querer consultar primero sobre la delimitación de límites o la política de migración, esto corresponde a Aprovechamiento y migración de activos existentes; como revisión de diseño antes de entrar en la implementación, corresponde a Consultoría técnica y revisión de diseño.

9. Cómo proceder si se opta por reemplazar

Se opta por reemplazar en situaciones en las que las limitaciones de la interfaz o de los bits frenan directamente la velocidad del negocio, o en las que, al no haber desarrollador disponible, el propio mantenimiento deja de ser viable. En lugar de lanzarse directamente a una reescritura completa, seguir el siguiente orden reduce los incidentes.

1. Verificar primero la migración de datos. En una migración de datos como la de Access a SQL Server, hay diferencias que solo se manifiestan después de la migración: distinta sincronización en la asignación de autonumeración, dependencia de funciones exclusivas de Access, falta de índices únicos, entre otras.⁸ Complete las pruebas de ida y vuelta de la migración y de los escenarios de negocio sobre una copia de los datos de producción antes de avanzar hacia el cambio en producción.
2. Hacer el inventario de la lógica de negocio. Examine por funcionalidad el contenido de los formularios/módulos de VB6 y del VBA/macros/consultas de Access, y distinga si se trata de «una simple pantalla» o de «un límite que contiene especificaciones». Este criterio es el mismo que se usa para ActiveX / OCX, pero en el caso de VB6 y Access hay un peso propio: como la comprensión del negocio acumulada durante años de operación es en sí misma un activo, suele llevar más tiempo desenterrarlo.
3. Avanzar mediante una migración por etapas (patrón strangler). En lugar de reemplazar todas las funciones a la vez, extraiga hacia el nuevo sistema primero las funciones de bajo riesgo y alta independencia, y haga que la aplicación antigua y la nueva convivan durante un período determinado. Dejar claro, por funcionalidad, cuáles datos son los válidos —los antiguos o los nuevos— y decidir de antemano la condición de término del período de convivencia son las condiciones mínimas para que este enfoque no fracase.
4. Resulta más sencillo si se resuelve antes el reemplazo de los componentes de interfaz o de la composición de pantallas. Si la aplicación VB6 usa ActiveX / OCX como componentes de interfaz, reemplazar antes solo esos componentes por controles modernos facilita la estimación del reemplazo global en etapas posteriores. Para la decisión sobre cada componente, consulte «Cómo tratar hoy ActiveX / OCX».
5. Preparar medios de observación durante el período de convivencia. Mientras la aplicación antigua y la nueva conviven, prepare registros o mecanismos de contraste que permitan comparar qué resultado produjo cada proceso. Si avanza con el cambio sin medios de observación, puede que no note el incidente de «al pasar al nuevo sistema, las cifras dejaron de cuadrar» hasta varios meses después.

Como servicio que abarca desde el inventario de especificaciones de aplicaciones Windows antiguas hasta su reemplazo por etapas, está Reemplazo de aplicaciones Windows.

10. Lista de verificación para empezar la migración

Antes de aplicar la tabla de decisión (capítulo 4), hacer el inventario en el siguiente orden puede reducir considerablemente el tiempo necesario para decidir la política a seguir.

1. Identificar los objetos. Enumere los .exe / .dll / .ocx de VB6 y los .mdb / .accdb de Access por nombre de archivo, versión y ubicación.
2. Comprobar la situación de uso. Verifique el número de usuarios, si hay acceso simultáneo, si funciona en carpeta compartida y con qué frecuencia se usa, diaria o mensual.
3. Comprobar las premisas del entorno de ejecución. Identifique la versión de Windows compatible, los bits de Office, el runtime necesario, las DLL de las que depende y si hay registros COM pendientes (capítulos 2 y 3).
4. Comprobar la ubicación y el tamaño de los datos. En el caso de Access, determine el tamaño del archivo, el número de tablas, el número de registros y el ritmo de crecimiento. Es material para decidir si conviene pasar a SQL Server.
5. Estimar la complejidad de la lógica de negocio. A partir del número de líneas de los módulos VBA, el número de macros, el número de formularios y el número de formularios/módulos de clase del lado VB6, haga una estimación aproximada del esfuerzo que llevará el inventario.
6. Comprobar si existen copias de seguridad y procedimientos de recuperación. Para los objetos que no tienen copias de seguridad, o cuya recuperación nunca se ha probado, hay que resolver esto primero, antes incluso de decidir.
7. Aplicar estos resultados a la tabla de decisión. Una vez organizados el objeto y la situación de uso, contrástelos con la tabla del capítulo 4 y fije provisionalmente, por funcionalidad, si se inclina hacia mantener, envolver o reemplazar.

Saltarse este procedimiento tiende a derivar en que, más adelante, el esfuerzo se dispara sin que nadie pueda explicar qué fue lo que resultó difícil.

11. Resumen

Al decidir cómo tratar VB6 y Access, lo primero que hay que mirar no es «si es viejo», sino estos tres puntos.

• ¿Se entiende correctamente la premisa de que VB6 es un entorno de ejecución exclusivo de 32 bits que perdió el respaldo de su IDE? (capítulo 2).
• ¿Se ha incorporado la premisa de que el ACE y ActiveX de Access quedan atados a los bits de Office, y de que en la operación en carpeta compartida el riesgo de corrupción aumenta cuanto más crece el acceso simultáneo? (capítulo 3).
• ¿Se sabe distinguir si el activo es una simple pantalla o un límite que contiene lógica de negocio y datos? (tabla de decisión del capítulo 4).

Si se aclaran estos tres puntos, se llega de forma natural a la manera de proceder correspondiente: si es «mantener», fijar el entorno de ejecución y no descuidar las copias de seguridad ni la documentación (capítulo 7); si es «envolver», proteger los datos y la lógica mediante puentes de 32/64 bits o una migración progresiva a .NET/web (capítulo 8); si es «reemplazar», hacer primero la verificación de la migración de datos y el inventario de la lógica de negocio (capítulo 9). VB6 y Access no son activos que deban descartarse a ciegas solo por ser viejos: son objetos concretos que concentran años de conocimiento de negocio. Sin embargo, tampoco se puede huir indefinidamente de las tareas pendientes necesarias para seguir conviviendo con ellos —fijar el entorno de ejecución, delimitar los límites y verificar la migración—. Recomendamos empezar por el inventario siguiendo la lista de verificación del capítulo 10.

Artículos relacionados

• Qué es VBA: limitaciones, futuro, cuándo conviene reemplazarlo y patrones realistas de migración
• Cómo tratar hoy ActiveX / OCX - Tabla de decisión de mantener, envolver o reemplazar
• Qué es COM / ActiveX / OCX - Diferencias y relaciones explicadas
• Causas y pasos de comprobación cuando ActiveX no funciona en Office 2024/Microsoft 365
• Ejemplo real de un puente COM que llama a un DLL de 64 bits desde una aplicación de 32 bits
• Conceptos básicos del control de exclusión en la integración de archivos - Mejores prácticas de bloqueo de archivos y claim atómico

Áreas de consultoría relacionadas

KomuraSoft LLC se ocupa del inventario de activos existentes —incluidos VB6 y Access— y de la definición de la política de migración, del diseño de prolongación de vida útil que incluye puentes de 32/64 bits, y de la planificación e implementación de reemplazos por etapas.

• Aprovechamiento y migración de activos existentes
• Reemplazo de aplicaciones Windows
• Modificación y mantenimiento de software Windows existente
• Consultoría técnica y revisión de diseño
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Las aplicaciones VB6 siguen funcionando en el Windows actual?

El IDE (entorno de desarrollo) de VB6 dejó de recibir soporte oficial en abril de 2008, pero el runtime de VB6 (como msvbvm60.dll) sigue siendo objeto de soporte durante el período de soporte de la versión de Windows en la que viene incluido. Es decir, las aplicaciones VB6 existentes, en general, siguen funcionando en las versiones de Windows compatibles. Sin embargo, como VB6 es exclusivo de 32 bits y en un sistema operativo de 64 bits funciona dentro del entorno de compatibilidad WOW64, en cuanto surge la necesidad de conectar con un DLL, SDK o componente COM exclusivo de 64 bits, se vuelve necesaria una configuración que lo extraiga a otro proceso y lo conecte desde ahí.

¿Por qué dejó de funcionar mi aplicación de Access al cambiar de PC?

En la mayoría de los casos, la causa es un cambio en los bits de Office. Office 2010 a 2016 instalaba por defecto la versión de 32 bits, pero desde Office 2019 y Microsoft 365 la instalación predeterminada pasó a ser la versión de 64 bits. El ACE (Access Database Engine), que lee y escribe los datos de Access, solo puede instalarse en una de las dos versiones —32 o 64 bits— en un mismo equipo, y debe coincidir con los bits de Office. Además, como el Office de 64 bits no puede cargar controles ActiveX ni complementos COM de 32 bits, los componentes creados bajo la premisa antigua de 32 bits dejan de funcionar en el equipo nuevo.

¿Es un problema que varias personas abran un archivo de Access desde una carpeta compartida?

Es un factor de riesgo de corrupción y de bajo rendimiento. La escritura a través de la red puede provocar corrupción de datos si la conexión se vuelve inestable. Cuantos más portátiles por Wi-Fi o más teletrabajo por VPN se sumen, mayor es la tasa de incidentes. Como mínimo, conviene adoptar una configuración dividida en la que solo se comparta el back-end con las tablas, y el front-end con las pantallas y consultas se copie y despliegue en el equipo de cada usuario. Cuando aumenta el número de usuarios simultáneos, llega el momento de considerar migrar las tablas a SQL Server y cambiar la configuración para que Access las referencie como tablas vinculadas.

¿Debería mantener, envolver o reemplazar mi aplicación VB6/Access?

El eje de la decisión es si el activo es una simple pantalla o un límite que contiene lógica de negocio y datos. Si el equipo y la versión de Windows están fijos y los requisitos de cambio son pequeños, mantenerlo con copias de seguridad, documentación y un entorno de ejecución fijo resulta rentable. Si se necesita conectividad de 64 bits o reforzar la base de datos, se envuelve solo una parte mediante un puente COM o la vinculación de tablas a SQL Server. Si no hay desarrollador disponible y el mantenimiento deja de ser viable, o hay demanda de pasar a la web, corresponde reemplazar, pero lo realista no es lanzarse a una reescritura completa de inmediato, sino avanzar con una migración por etapas que primero verifique la migración de datos y haga el inventario de la lógica de negocio.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.