Migrar Access, VB6 o FoxPro a web: guía por tecnología

Migrar un sistema de Access, Visual Basic 6 o Visual FoxPro a web consiste en sacar los datos a un motor SQL de servidor, extraer las reglas de negocio escondidas en formularios, consultas y código, y reconstruir las pantallas como aplicación web por módulos, con ambos sistemas conviviendo hasta el corte. Casi todo lo valioso se rescata: los datos, los cálculos y el formato de los reportes. Lo que no se rescata es el código tal cual, porque ninguna de estas tecnologías corre en un navegador.

Esta guía va tecnología por tecnología: qué riesgo real corres si sigues con cada una, qué se aprovecha y cuál es la ruta de migración. Si buscas la estrategia general (rehost, replatform, strangler fig, diagnóstico y corte), ya la explicamos en cómo modernizar un sistema legado sin detener tu operación. Aquí bajamos al detalle de cada plataforma.

Definición rápida: un sistema legacy (o sistema heredado) es software que sigue sosteniendo procesos críticos, pero está construido sobre tecnología sin soporte o que ya no se puede cambiar ni integrar con un costo y un riesgo razonables. Lo define la fragilidad, no la antigüedad.

¿Por qué tantas empresas siguen con Access, VB6 o FoxPro?

Porque funcionan. Muchos de estos sistemas se hicieron a finales de los noventa o en los dos mil, los programó alguien que conocía muy bien el negocio y llevan años facturando, controlando inventario o calculando nómina sin grandes fallas. Reemplazar algo que funciona da miedo, y con razón.

El problema no es que hoy fallen. Es que cada año dependen de menos personas que saben mantenerlos, de computadoras específicas que nadie quiere tocar y de una red local que ya no corresponde a cómo trabaja tu equipo: desde casa, desde el celular o desde otra sucursal. La modernización de sistemas heredados no se trata de seguir una moda, sino de quitarte un riesgo antes de que se vuelva una emergencia.

Microsoft Access: ¿qué riesgo real tiene seguir usándolo?

Access es una herramienta excelente para lo que fue diseñada: bases de datos de escritorio para un área o un grupo pequeño. Los problemas aparecen cuando un sistema legacy en Access se convierte en el sistema de toda la empresa.

Límite de tamaño. Microsoft documenta en sus especificaciones de Access un máximo de 2 GB por archivo de base de datos (.accdb o .mdb), incluidos todos los objetos y datos, menos el espacio de los objetos del sistema. Un sistema con varios años de ventas, movimientos de inventario o archivos adjuntos llega a ese techo antes de lo que parece.

Multiusuario en red. La misma tabla de especificaciones marca 255 usuarios concurrentes como máximo teórico, pero el límite práctico es otro. Access trabaja sobre un archivo compartido en una carpeta de red, no sobre un servidor de base de datos. Microsoft recomienda dividir la base de datos en un archivo de datos compartido y una copia local de formularios por usuario, precisamente porque así mejora el rendimiento y, cuando hay daño en un archivo, suele limitarse a la copia local del usuario. Si tu sistema no está dividido, todos abren el mismo archivo y una desconexión a mitad de una escritura puede dañarlo. Y en su guía sobre formas de compartir una base de escritorio, Microsoft menciona el límite de 2 GB como una razón para pasar a un servidor de base de datos como SQL Server.

Acceso remoto. Access no está pensado para usarse a través de internet. Trabajar desde fuera de la oficina suele terminar en escritorio remoto contra una máquina específica.

Qué se rescata: las tablas y sus relaciones casi íntegras, las consultas (que son SQL y documentan las reglas de cálculo), los informes como diseño de referencia y el código VBA de los formularios, que es donde viven las validaciones.

Ruta típica: primero se migran las tablas a un motor SQL de servidor y se vinculan desde el mismo Access. El sistema sigue funcionando igual para los usuarios, pero los datos ya están en un servidor con respaldos y sin el límite de 2 GB. Después se construye la aplicación web por módulos sobre esa misma base. Si tu caso es más bien un conjunto de hojas de cálculo, lee de Excel a sistema web.

Visual Basic 6: ¿qué dice Microsoft sobre su soporte?

Aquí conviene ser precisos, porque circula mucha información a medias. Según la declaración oficial de soporte de Visual Basic 6.0:

• El entorno de desarrollo (IDE) de VB6 no tiene soporte desde el 8 de abril de 2008. Microsoft lo dice sin rodeos: como no hay una forma soportada de crear o mantener aplicaciones VB6, recomienda reemplazarlas con tecnología moderna.
• El runtime sí sigue soportado en Windows 11, Windows 10 y Windows Server 2016, 2019, 2022 y 2025, entre otros, durante el ciclo de vida de cada versión de Windows. Pero el soporte se limita a regresiones graves y problemas críticos de seguridad.
• El runtime es solo de 32 bits. En Windows de 64 bits corre en el entorno de emulación WOW.
• Los controles de terceros (OCX/ActiveX) no tienen soporte de Microsoft, y varios archivos que se usaban comúnmente aparecen como no soportados.

En la práctica, que tu programa compilado siga abriendo no significa que puedas cambiarlo. Para corregir un error o agregar un campo para CFDI 4.0 necesitas el IDE instalado en alguna máquina, los controles originales con sus licencias y a alguien que todavía programe en VB6. Ese es el riesgo real: no que el sistema deje de abrir mañana, sino que no puedas modificarlo cuando lo necesites.

Qué se rescata: la base de datos (normalmente SQL Server, Access o archivos DBF detrás del programa), las reglas de negocio en los módulos .bas y en los eventos de los formularios, y la estructura de los reportes, a menudo hechos en Crystal Reports o en el diseñador de reportes de VB.

Ruta típica: si la base ya es SQL Server, la convivencia es sencilla: el sistema nuevo se conecta a la misma base o a una copia sincronizada. Microsoft llegó a publicar herramientas para convertir VB6 a VB.NET, pero el resultado sigue siendo una aplicación de escritorio y arrastra el diseño original; para llegar a web casi siempre conviene reconstruir la interfaz y reaprovechar la lógica.

Visual FoxPro: ¿todavía se puede mantener?

Visual FoxPro tiene una de las situaciones más claras. Según el ciclo de vida oficial de Microsoft, el soporte principal de Visual FoxPro 9.0 terminó en enero de 2010 y el soporte extendido terminó en enero de 2015. No hay versión posterior: la 9.0 fue la última.

Eso significa que desde hace más de diez años no hay parches de Microsoft para el producto. Las aplicaciones siguen funcionando en muchas computadoras, pero cada actualización de Windows, cada antivirus y cada cambio de red es una apuesta que nadie puede garantizar.

FoxPro tiene además una particularidad: su base de datos son archivos DBF, CDX y FPT compartidos en una carpeta de red, con un esquema de bloqueo de archivos parecido al de Access. Los índices dañados y las tablas que hay que “reindexar” son parte de la rutina de muchas empresas que todavía lo usan.

Qué se rescata: prácticamente todos los datos (los DBF se leen bien con herramientas actuales), las reglas en los programas .prg y en los métodos de los formularios, y los reportes .frx como referencia de diseño.

Ruta típica: extraer los DBF, limpiar fechas vacías, claves duplicadas y campos de texto con caracteres mal codificados, y cargarlos en un motor SQL. Como FoxPro no se lleva bien con un servidor SQL moderno sin trabajo adicional, la convivencia suele resolverse con una sincronización periódica o un servicio intermedio, no con la misma base.

¿Y si mi sistema está en Delphi o en PHP 5?

Delphi sigue siendo un producto comercial con versiones actuales, así que el problema rara vez es el lenguaje: es la versión vieja en la que se quedó el sistema, los componentes de terceros que ya no existen y que suele ser de escritorio. La ruta es parecida a VB6: la base de datos se aprovecha y la interfaz se reconstruye en web.

PHP 5 ya es web, pero sin parches: según php.net, la última rama, PHP 5.6, llegó al fin de vida el 31 de diciembre de 2018. Aquí la modernización suele ser una actualización controlada más que una reescritura; lo explicamos en cómo actualizar PHP sin romper tu sistema.

Tabla comparativa: riesgos y ruta de migración por tecnología

Tecnología	Estatus de soporte	Riesgo principal	Qué se rescata	Ruta de migración recomendada
Microsoft Access	Producto vigente dentro de Microsoft 365, con límite de 2 GB por archivo	Daño del archivo en red, tamaño, acceso remoto	Tablas, consultas SQL, VBA, diseño de informes	Tablas a SQL de servidor vinculadas desde Access; luego web por módulos
Visual Basic 6	IDE sin soporte desde 2008; runtime soportado solo para fallas graves y seguridad	No poder modificar el sistema; controles OCX sin soporte	Base de datos, módulos .bas, eventos de formularios, reportes	Nuevo sistema web sobre la misma base o una API; reemplazo por módulos
Visual FoxPro 9	Soporte extendido terminado en enero de 2015	Sin parches; DBF compartidos en red; índices dañados	Datos DBF, programas .prg, reportes .frx	Extracción y limpieza a SQL, sincronización temporal y corte por módulos
Delphi (versiones antiguas)	Producto vigente, versión del sistema sin soporte	Componentes de terceros abandonados	Base de datos y lógica de negocio	Similar a VB6, reconstruyendo la interfaz en web
PHP 5	Fin de vida el 31 de diciembre de 2018	Vulnerabilidades sin parche	Casi todo el código y la base	Actualización por etapas a una versión soportada

¿Cómo se migra paso a paso?

El método es parecido para las tres tecnologías principales. Cambian las herramientas de extracción, no la lógica.

1. Inventario del sistema

Antes de escribir código hay que saber qué hace realmente el sistema heredado: pantallas, reportes, procesos automáticos, archivos que exporta a contabilidad o al banco, y quién usa cada cosa. Es común descubrir funciones que ya nadie usa y procesos críticos que viven en un botón escondido. Este inventario es lo que permite estimar con fundamento; los factores que mueven el precio los desglosamos en cuánto cuesta modernizar un sistema legacy.

2. Extracción de reglas de negocio

Es el paso más subestimado. En estos sistemas las reglas no están documentadas, están repartidas en:

• Formularios: validaciones en eventos como “al salir del campo” o “antes de guardar”, cálculos de descuentos, bloqueos por saldo vencido.
• Consultas: en Access, las consultas guardadas contienen filtros y cálculos que alimentan los reportes de cierre.
• Código: módulos de VB6 o programas .prg con redondeos fiscales, reglas de comisión o cálculo de costos.

Se leen el código y las consultas, se entrevista a los usuarios clave y se preparan casos de prueba con datos reales: “este pedido debe dar este total”. Esos casos son la vara para medir que el sistema nuevo calcula igual.

3. Migración de datos a SQL

Los datos se extraen a un área intermedia, se limpian (clientes duplicados, RFC mal capturados, fechas vacías, claves repetidas) y se cargan en el motor SQL nuevo con scripts versionados que se ejecutan varias veces antes del corte. Al final se concilian conteos, saldos y existencias entre ambos sistemas. Si vas a timbrar desde el sistema nuevo, conviene validar desde aquí los datos fiscales que exige la facturación electrónica.

4. Convivencia temporal

Aquí está la diferencia entre una migración tranquila y un fin de semana de pánico. Hay dos formas comunes de que el sistema viejo y el nuevo trabajen al mismo tiempo:

• La misma base de datos. Funciona muy bien con Access (tablas vinculadas a SQL) y con VB6 cuando ya usaba SQL Server: ambos sistemas leen y escriben en el mismo lugar y los módulos web reemplazan pantallas poco a poco.
• Una API o sincronización. Cuando el sistema viejo no puede conectarse a la base nueva, como suele pasar con FoxPro, un servicio intermedio sincroniza la información o expone una API. Explicamos cómo se diseña en integración de sistemas por API.

5. Corte

Cuando el último módulo está probado en operación real, el sistema viejo se congela, se hace la extracción final, se concilia y se apaga. Los datos históricos que no se migraron quedan en una base de solo consulta. El detalle de cómo planear la ventana de corte y el plan de regreso está en la guía general de modernización que enlazamos al inicio.

¿Qué tecnología usar para el sistema nuevo?

Para sistemas administrativos solemos proponer una aplicación web con backend en un framework vigente, base de datos PostgreSQL, MySQL o SQL Server y despliegue en la nube con respaldos automáticos. Lo importante no es la marca, sino que tenga soporte activo, que haya gente que la mantenga y que la infraestructura en la nube tenga respaldos probados, algo que muchos sistemas en Access o FoxPro nunca tuvieron.

¿Cuándo no conviene migrar todavía?

Ser honestos aquí ahorra dinero. No siempre es momento de migrar un sistema legado:

• Si el sistema es pequeño, lo usan dos o tres personas en la misma oficina y no crece. Una base de Access bien dividida y con respaldos diarios puede seguir sirviendo años. Primero asegura respaldos y documenta las reglas.
• Si tus procesos son estándar. Si lo que hace tu sistema en FoxPro es contabilidad, nómina o facturación sin nada particular, quizá te convenga más un sistema comercial y migrar solo los datos. Lo comparamos en CONTPAQi o Aspel vs. software a la medida y en ERP a la medida vs. comercial.
• Si estás a punto de cambiar el proceso. Si vas a reorganizar áreas, abrir una sucursal o cambiar de modelo de negocio, migrar antes es construir sobre algo que va a cambiar. Mejor define el proceso nuevo y migra hacia él.
• Si nadie puede validar. Una migración necesita a alguien del negocio que revise resultados. Si en los próximos meses tu equipo no tiene tiempo, el proyecto va a avanzar mal.

En cualquiera de estos casos hay una acción barata que sí conviene hacer ya: sacar los datos del equipo de escritorio, ponerlos en un lugar con respaldos y documentar quién sabe qué del sistema.

Cómo te ayuda Tecsolt

En Tecsolt desarrollamos software a la medida desde junio de 2017 y llevamos más de 100 proyectos. Somos un equipo 100% remoto con base en León, Guanajuato. Para migrar un sistema en Access, VB6 o FoxPro empezamos por el inventario y la extracción de reglas, te proponemos un plan por etapas en el que el sistema actual sigue operando mientras entran los módulos nuevos, y desplegamos en Google Cloud con respaldos automáticos. El código, la documentación y los accesos quedan a nombre de tu empresa. Conoce nuestro servicio de software y ERP a la medida o agenda una reunión para revisar tu sistema.

Preguntas frecuentes

¿Se puede convertir una base de datos de Access a una aplicación web?

No existe un botón que convierta los formularios de Access en una aplicación web, pero los datos sí se migran completos a un motor como SQL Server, PostgreSQL o MySQL. Los formularios, consultas y macros se usan como especificación para construir las pantallas nuevas. Mientras tanto, Access puede seguir funcionando conectado a la nueva base con tablas vinculadas.

¿Visual Basic 6 sigue teniendo soporte de Microsoft?

El entorno de desarrollo de VB6 dejó de tener soporte el 8 de abril de 2008. El runtime, es decir, los archivos que permiten ejecutar las aplicaciones ya compiladas, sigue soportado en Windows 10, Windows 11 y Windows Server 2016 a 2025 mientras esas versiones de Windows tengan soporte, pero solo para regresiones graves y problemas críticos de seguridad. Microsoft recomienda de forma explícita reemplazar esas aplicaciones.

¿Cuándo terminó el soporte de Visual FoxPro 9?

Según el ciclo de vida oficial de Microsoft, el soporte principal de Visual FoxPro 9.0 terminó en enero de 2010 y el soporte extendido en enero de 2015. No hubo una versión posterior a la 9.0, así que desde entonces no hay una ruta oficial de evolución para el lenguaje.

¿Cuál es el límite de tamaño de una base de datos de Access?

Microsoft documenta un máximo de 2 GB por archivo .accdb o .mdb, incluidos todos los objetos y datos, menos el espacio que ocupan los objetos del sistema. Se puede repartir la información en varios archivos vinculados, pero es un parche: cuando un sistema se acerca a ese límite, conviene mover los datos a un motor de base de datos de servidor.

¿Cuánto tarda migrar un sistema en VB6 o FoxPro a web?

Depende del número de módulos, de cuántas reglas de negocio viven en el código y de la calidad de los datos. Un módulo acotado puede quedar en semanas; un sistema administrativo completo suele migrarse por etapas durante varios meses. El tiempo realista sale de un inventario del sistema actual, no de contar pantallas.

¿Puedo seguir usando mi sistema viejo mientras se construye el nuevo?

Sí, y es lo recomendable. Lo común es mover primero los datos a un servidor SQL y conectar ahí tanto el sistema viejo como el nuevo, o comunicar ambos mediante una API. Así cada módulo nuevo entra en operación cuando está probado y el sistema anterior se apaga al final.

• #sistemas heredados
• #migración de datos
• #microsoft access
• #visual basic 6
• #visual foxpro
• #modernización de sistemas