¿Qué es VBA? - Límites, futuro, cuándo reemplazarlo y un patrón realista de migración

En las consultas sobre VBA suelen mezclarse temas como estos.

• Qué es VBA en primer lugar
• Se dice que las macros son peligrosas: ¿ya no deberían usarse?
• ¿Dejará de poder usarse en el futuro?
• ¿Habría que trasladarlo todo a Office Scripts o Power Automate?
• ¿Deberían conservarse los activos existentes en .xlsm o Access, o descartarse?
• ¿Se puede ejecutar Excel en un proceso batch nocturno o en un servidor?

Este no es un tema que se resuelva del todo con una sola respuesta. Lo primero que hay que mirar no es tanto si algo es nuevo o antiguo, sino dónde se ejecuta, quién lo usa, si Excel o Access son en sí mismos la interfaz, o si se trata de una ejecución sin supervisión.

En este artículo organizamos, en este orden, qué es VBA, dónde están sus límites, si dejará de poder usarse, en qué situaciones conviene reemplazarlo y cómo llevar a cabo una migración gradual y realista. El contenido parte de la información oficial de Microsoft disponible hasta marzo de 2026.¹²³⁴⁵

1. Ante todo, la conclusión

Antes de entrar en detalle, dejamos aquí las conclusiones.

• VBA es un lenguaje orientado a eventos para extender las aplicaciones de escritorio de Office. Es una tecnología pensada para funcionar dentro de Excel, Word, PowerPoint, Access y programas similares.¹
• Al menos hasta marzo de 2026, no se puede confirmar en la información oficial de Microsoft ningún anuncio claro de que «VBA en sí vaya a terminarse pronto». Lo que está ocurriendo no es tanto una «eliminación repentina y total» como un cambio en el que se están precisando los lugares donde se puede usar y las condiciones previas.¹²³⁴
• En concreto, en Excel for the web no se pueden crear, ejecutar ni editar macros VBA. Además, las macros de archivos procedentes de internet se bloquean de forma predeterminada.²³
• Por lo tanto, el debate actual no es «descartar VBA por completo», sino qué áreas dejar en VBA y cuáles sacar hacia fuera.
• En particular, los procesos que requieren ejecución sin supervisión, ejecución en servidor, uso por varias personas, compatibilidad con navegador, distribución centralizada o auditorías estrictas no deberían depender únicamente de VBA. Tampoco Microsoft recomienda ni admite la automatización de Office en el lado del servidor.⁶
• No existe un único destino de reemplazo. Es realista repartirlo así: si se conserva Excel, sacar el procesamiento hacia una DLL de .NET o un proceso aparte; si el flujo de negocio vive en Microsoft 365, Office Scripts + Power Automate; si se necesita una extensión multiplataforma, Office Add-ins; y si Excel ya no funciona como interfaz, migrar a una aplicación de Windows o web.⁴⁵⁶

En resumen, lo más práctico es ver VBA no como «una tecnología a punto de morir», sino como «una tecnología con un lugar claro donde encaja».

2. Qué es VBA

VBA son las siglas de Visual Basic for Applications, una variante de Visual Basic incluida en Microsoft Office. La propia documentación oficial de Microsoft lo describe como un lenguaje de programación orientado a eventos para extender las aplicaciones de Office.¹⁷

Lo importante aquí es que se ajusta más a la realidad ver VBA no como una plataforma genérica de desarrollo de aplicaciones, sino como un lenguaje de extensión que se inserta dentro de una aplicación de Office.

En el caso de Excel, por ejemplo, opera muy cerca de elementos como estos.

• Workbook
• Worksheet
• Range
• Botones y formularios
• Eventos al abrir el libro, al guardarlo o al cambiar una celda

Es decir, el punto fuerte de VBA es que está muy próximo a la pantalla, los informes y la estructura del libro de Excel o Access. El usuario abre Office en su escritorio, pulsa un botón, procesa datos de un archivo local o de una carpeta compartida, y a partir de ahí obtiene directamente un informe. Ese tipo de «automatización que se completa en las manos del propio usuario» sigue siendo hoy uno de sus puntos fuertes.¹

El código real puede ser tan breve como esto. Es la forma más mínima, pensada para asignarse a un botón sobre la hoja.

' Colocar en un módulo estándar de Excel. Pensado para invocarse desde un botón de la hoja
Option Explicit

Public Sub ClearMeisai()
    Dim ws As Worksheet
    Set ws = ThisWorkbook.Worksheets("Detalle")

    If MsgBox("Se van a borrar los datos de la hoja Detalle a partir de la fila 2. ¿Desea continuar?", _
              vbOKCancel + vbQuestion, "Confirmación") <> vbOK Then
        Exit Sub
    End If

    ws.Rows("2:" & ws.Rows.Count).ClearContents
End Sub

Si coloca en la hoja una forma o un botón de control de formulario, y con el botón derecho elige «Asignar macro» para seleccionar este ClearMeisai, el proceso se ejecutará cada vez que se pulse el botón. Lo que interesa observar aquí es que objetos de Excel como ThisWorkbook, Worksheets o Rows aparecen directamente, sin pasar por conversiones ni llamadas a una API intermedia. Eso es, en concreto, lo que significa «un lenguaje que funciona dentro de Office»: esa cercanía. Dicho de otro modo, en las alternativas donde se pierde esa cercanía no se puede escribir con el mismo número de pasos.

En cambio, el territorio propio de VBA nunca fue, de entrada, el servidor, el navegador, el móvil ni los sistemas web multiinquilino.

3. Por qué se sigue usando hoy

El motivo por el que VBA sigue presente en el día a día no es simplemente «que quedó por inercia porque es antiguo».

Para empezar, en Excel y Access no solo entran datos: es fácil que se cuele el propio procedimiento de negocio.

• El aspecto visual de los informes
• La configuración de impresión
• Las validaciones de entrada
• El orden del cierre mensual
• Las reglas de excepción de cada departamento
• Los procedimientos operativos a los que el personal lleva años acostumbrado

Todo esto no se resuelve solo con «trasladar el código» al migrar a otro sistema. Como el aspecto visual, la operación, las excepciones y la forma de trabajar están integrados en un solo bloque, los activos VBA cargan con más especificaciones de las que aparentan.

Además, como VBA está próximo al modelo de objetos de Office, en los casos en que se opera directamente sobre el Excel que el usuario tiene delante y se devuelve un resultado, requiere pocos pasos. Esta cercanía también importa a la hora de pensar en los candidatos sucesores, porque no siempre basta con reescribirlo simplemente en una tecnología nueva.

En la práctica, resulta natural razonar así.

• Si Excel sigue siendo la interfaz, vale la pena conservar parte de VBA
• Si Excel solo hace falta para la entrada y salida de datos, es fácil sacar la lógica interna hacia fuera
• Si Excel ya no cumple su función original como interfaz, se convierte en candidato a rehacerse

4. Las principales limitaciones de VBA

4.1 Está pensado para el escritorio

Esta es la mayor limitación. VBA es, básicamente, una tecnología que funciona dentro de la versión de escritorio de Office.

La información oficial de Microsoft también indica que, en Excel for the web no se pueden crear, ejecutar ni editar macros VBA; se puede abrir y editar un libro con macros, pero no ejecutar VBA.²⁸

Llegados a este punto, encaja mal con requisitos como estos.

• Querer que todo se complete en el navegador
• Querer usar la misma extensión en Mac, iPad y Web indistintamente
• Que el administrador quiera distribuirlo de forma centralizada
• No querer depender del Excel de escritorio local

La propia Microsoft indica, en la documentación del propio VBA, que si se quiere crear una extensión para varias plataformas, conviene mirar Office Add-ins.⁹⁵

4.2 La fricción de seguridad y distribución es alta

Buena parte del motivo por el que se malinterpreta que VBA «ya no se puede usar» es, en realidad, el refuerzo de la seguridad.

Microsoft bloquea de forma predeterminada las macros VBA contenidas en archivos procedentes de internet. Un .xlsm adjunto a un correo o descargado no se ejecuta con la misma naturalidad que antes solo con abrirlo.³

Esto va en la dirección correcta desde el punto de vista de la seguridad. Sin embargo, desde el lado operativo aparece más fricción:

• No funciona al distribuirlo por correo adjunto
• No funciona una plantilla descargada de un sitio externo
• El comportamiento vía OneDrive, SharePoint o red resulta confuso
• Un aviso del tipo «actívelo, por favor» se convierte en un punto débil operativo

Ahora bien, esto no termina en un simple «no funciona, y punto». En el mismo documento, Microsoft también describe los medios para ejecutar macros de archivos en los que se confía. En la operación diaria se usan sobre todo estos cuatro.³

Al mismo tiempo, las precauciones también están claras.³

• Una ubicación de confianza o un sitio de confianza implican confiar en todo lo que se coloque allí. Es necesario limitarlo a lugares donde se pueda controlar «quién puede escribir».
• Los editores de confianza son una configuración de todo Windows, no algo exclusivo de Office.
• Si un complemento de Excel (.xla / .xlam) tiene la marca Mark of the Web, no funciona aunque se firme y se confíe en el editor. En ese caso, hay que quitar la marca Mark of the Web o colocarlo en una ubicación de confianza.
• Si se abre una carpeta de red mediante una dirección IP, eso por sí solo puede no encajar ni en sitios de confianza ni en la intranet local, y quedar bloqueado.

Dicho de otro modo, si se decide conservar VBA, hay que decidir, aparte del propio código, dónde se coloca y cómo se genera la confianza, como parte del diseño de distribución. Seguir distribuyendo .xlsm por correo adjunto sin haber decidido esto es la forma de operar con más fricción.

En definitiva, el problema de VBA no está solo en «las funciones del lenguaje», sino que también aparece en el diseño de la distribución y la confianza.

4.3 Existe la barrera de 32 bits / 64 bits

Office tiene versiones de 32 bits y de 64 bits, y en Office 2019 y Microsoft 365 la opción predeterminada es de 64 bits.⁷

Por eso, entre el código VBA antiguo, en particular el que llama a la API de Windows con Declare, hay casos que no funcionan tal cual en un entorno de 64 bits. Microsoft también indica que es necesario absorber la diferencia entre 32 y 64 bits usando PtrSafe, LongPtr, LongLong y elementos similares.⁷

Lo complicado es que no solo el código, sino también dependencias como estas suelen convertirse en un problema a la vez.

• COM / ActiveX / OCX antiguos
• DLL externas pensadas para 32 bits
• Componentes que requieren registro en el registro de Windows
• Desajustes en las referencias configuradas de Office

Es decir, la migración de VBA suele ser, más que una reescritura del lenguaje, una reorganización de la arquitectura de bits de Office y de las dependencias externas.

4.4 No es apto para la ejecución sin supervisión ni en servidor

Este punto es bastante importante. Microsoft afirma explícitamente que no recomienda ni admite la automatización de aplicaciones de Office en el lado del servidor. Office está diseñado partiendo de un escritorio interactivo y un perfil de usuario, por lo que en un entorno sin supervisión pueden producirse inestabilidad o interbloqueos.⁶

Por eso, configuraciones como estas tienden a ser peligrosas.

• Iniciar Excel desde un servicio de Windows
• Automatizar Office desde ASP.NET o DCOM
• Mantener funcionando indefinidamente un Excel invisible en el Programador de tareas
• Delegar por completo la generación de informes a un Excel en un servidor

A veces «funciona de vez en cuando». Pero que algo funcione y que sea una arquitectura sostenible son cosas distintas.

Si se necesita ejecución sin supervisión, lo primero que hay que cuestionar no es VBA, sino la propia arquitectura que hace funcionar la aplicación Excel.

4.5 Tiende a salir perdiendo en mantenibilidad, capacidad de prueba y control de cambios

En VBA, el código tiende a quedar encerrado dentro del libro o del archivo de Access. Como resultado, es fácil que aparezcan problemas como estos.

• Se vuelve ambiguo cuál es el archivo «original»
• Las responsabilidades se dispersan entre formularios, hojas y módulos estándar
• Las referencias configuradas o las dependencias de ActiveX se desajustan según el entorno
• Es difícil revisar el código o comparar diferencias
• Es difícil construir pruebas unitarias
• Las propias direcciones de celda de Excel terminan convirtiéndose en especificación

Esto no es un problema exclusivo del lenguaje VBA, sino un problema de la estructura de «tener la lógica de negocio dentro de un archivo de Office». En automatizaciones pequeñas puede no notarse gran cosa, pero en cuanto el conjunto se convierte en un sistema de negocio, el efecto se hace notar de repente.

4.6 Si existe dependencia de VBScript, se necesita otra precaución

En 2025, el blog de desarrolladores de Microsoft 365 anunció que la eliminación gradual de VBScript en Windows también puede afectar a los proyectos de VBA. En particular, se ven afectados los casos que ejecutan un .vbs externo y los que dependen de la referencia a VBScript.RegExp.¹⁰

Por otro lado, Microsoft también está avanzando en la respuesta: a partir de Microsoft 365 versión 2508 (compilación 19127.20154), en la versión de Office para Windows la clase RegExp se incluye de forma predeterminada en VBA.¹⁰

Para saber si los propios activos se ven afectados, basta con buscar estos tres puntos, ya sea con el buscador del menú «Editar» del IDE de VBA, o mediante un grep sobre el texto exportado a .bas / .cls.

La lista de referencias configuradas se puede consultar en el menú «Herramientas» del IDE de VBA, en «Referencias».

De estos, en cuanto a RegExp, como se explicó antes, la solución ya avanza: a partir de Microsoft 365 versión 2508 (compilación 19127.20154), en la versión de Office para Windows la clase RegExp queda incluida de forma predeterminada en VBA.¹⁰ El impacto más pesado corresponde al patrón de la tercera fila, «ejecutar un .vbs externo»; en ese caso hace falta plantearse llevar ese procesamiento al propio VBA o a otra plataforma de ejecución. Si estos tres puntos se registran a la vez al elaborar el inventario de activos (apartado 8.1), se evita tener que hacer el trabajo dos veces.

Lo importante aquí es que la eliminación de VBScript y la eliminación de VBA no son la misma historia. No se trata de que VBA mismo vaya a desaparecer, sino, de forma más precisa, de que hay que revisar parte de las dependencias externas que colgaban de VBA.

5. ¿Dejará VBA de poder usarse en el futuro?

Ante todo, no se trata de que «mañana deje de poder usarse por completo». Pero tampoco estamos ya en la época de «sirve para todo, en cualquier lugar».

Al menos leyendo la información oficial de Microsoft, la dirección que se aprecia con más fuerza es esta.

• VBA, como extensión del Office de escritorio, sigue existiendo¹
• En el lado web / multiplataforma se combinan Office Scripts y Office Add-ins según el caso⁴⁵⁹
• La seguridad en la distribución de macros se trata con más rigor que antes³
• Componentes periféricos como la dependencia de VBScript pueden verse afectados en el futuro¹⁰

Además, respecto a Office Scripts, Microsoft indica explícitamente que VBA está centrado en el escritorio, mientras que Office Scripts está pensado para soluciones seguras, multiplataforma y basadas en la nube. Al mismo tiempo, también explica que por ahora, la cobertura de funciones de Excel disponibles en el cliente de escritorio es más amplia en VBA.⁴

Al poner estas dos ideas una junto a la otra, el panorama se vuelve bastante práctico.

• En el manejo profundo de Excel de escritorio, el terreno de VBA todavía es amplio
• En el navegador, M365 o los flujos de trabajo compartidos, resulta más natural Office Scripts o Add-ins
• Por eso, ni «basta con cambiarlo todo a Office Scripts» ni «basta con mantener VBA en el centro para siempre» son la respuesta correcta

Lo más natural es ver el futuro de VBA como una delimitación de sus fronteras, más que una desaparición.

6. Casos en los que conviene reemplazarlo y casos en los que no

Antes que nada, presentamos una tabla orientativa, aunque general, que resulta útil como guía.

El enfoque híbrido que aparece en la segunda fila de la tabla se usa en este artículo con el sentido de «dejar Excel o Access como puerta de entrada para la interfaz y los informes, y sacar hacia una unidad de ejecución externa solo la lógica de negocio o la E/S». La diferencia con un reemplazo total es que no cambia la pantalla ni la forma de operar que ve el usuario. La forma concreta se trata en 7.1.

Lo importante de esta tabla es que el eje de decisión para reemplazar no es «porque VBA es antiguo». Lo que de verdad hay que mirar es el entorno de ejecución, la operación, la distribución, las dependencias, la auditoría y la extensibilidad.

7. Alternativas realistas de reemplazo

Antes de entrar en el detalle, presentamos los candidatos en una sola tabla. Después de decidir «hacia dónde inclinarse» con la tabla de criterios del capítulo 6, use esta tabla para confirmar «qué exige ese destino».

Lo que más se pasa por alto es la columna «Requisitos / licencia». Office Scripts, en particular, tiene condiciones muy definidas, así que las tratamos por separado en 7.3.

7.1 Conservar Excel y sacar solo el contenido hacia .NET o un proceso aparte

Lo más realista y menos propenso a fallar es esto.

• La puerta de entrada, la pantalla y los informes siguen siendo Excel / Access
• Los botones y formularios de entrada también se mantienen tal cual por ahora
• Sin embargo, la lógica de negocio, HTTP, el cifrado, CSV / JSON, los cálculos pesados y el procesamiento de archivos se sacan hacia fuera
• VBA queda reducido a «puente» y «manejo de la interfaz»

La ventaja de esta arquitectura es que es difícil que rompa el aspecto y la forma de operar que ve el usuario. Se puede avanzar hacia reducir las responsabilidades en lugar de hacer un reemplazo total desde el principio.

Artículo relacionado:

• Cómo usar una DLL de .NET 8 desde VBA con tipado - Exposición COM y dscom TLB

«Antes de reescribirlo todo, sacar primero solo la parte pesada» es un enfoque bastante práctico.

7.2 Para la ejecución sin supervisión y la generación de informes, apostar por la generación directa de archivos en lugar de automatizar la aplicación de Office

Si se quiere generar en grandes volúmenes informes de Excel mediante un proceso batch nocturno o un servicio, lo primero que hay que cuestionar no es «si VBA es antiguo», sino el propio hecho de estar iniciando la aplicación Excel.

Microsoft no recomienda la automatización de Office en el lado del servidor. En su lugar, recomienda manejar el archivo de Office directamente, por ejemplo mediante el formato Open XML.⁶

Es decir, si el requisito es algo como

• Querer crear un .xlsx
• Querer generar en grandes volúmenes informes de formato fijo
• Querer convertirlo a PDF
• Querer ejecutarlo en un proceso batch nocturno

el eje que hay que elegir no es si se hace funcionar a Excel, sino si se construye el archivo de Excel directamente.

Artículo relacionado:

• Cómo generar informes de Excel - COM/Open XML/plantillas

7.3 Para flujos de trabajo en Microsoft 365, Office Scripts + Power Automate

Si el trabajo ya gira en torno a OneDrive, SharePoint, Teams, Outlook o Forms, Office Scripts es un candidato bastante sólido.

Microsoft describe Office Scripts como orientado a soluciones seguras, multiplataforma y basadas en la nube. Además, combinándolo con Power Automate, se puede automatizar el procesamiento de Excel usando como disparador un correo, un formulario o una programación horaria.⁴¹¹

Sin embargo, antes de eso hay que confirmar los requisitos de uso. Estos son, en sí mismos, el punto de partida del costo y del entorno, así que más adelante siempre terminan pesando.¹²¹³

Es decir, Office Scripts no es «un sustituto gratuito de VBA». Comparado con la operación de distribuir y hacer funcionar un .xlsm local, se añaden como requisitos previos OneDrive / SharePoint y una licencia de M365. Si se pasa esto por alto y se decide «migrar a Office Scripts» sin más, a mitad de la migración se termina volviendo al tema de la adquisición de licencias.

Dicho esto, tampoco es todopoderoso en el plano funcional.

• Office Scripts no admite eventos a nivel de Excel
• La ejecución es, básicamente, de inicio manual o mediante una llamada desde Power Automate⁴
• La integración con Power Automate requiere una licencia empresarial (business) de Microsoft 365¹¹
• La acción Run script tiene límites como 1600 ejecuciones al día por usuario y 120 segundos para el procesamiento síncrono¹²

En definitiva, es más exacto ver Office Scripts no como «un sustituto de VBA», sino como una pieza de automatización dentro de M365.

7.4 Si se necesita una extensión multiplataforma, Office Add-ins

Si se quiere extender Word, Excel, Outlook y programas similares en Windows / Mac / iPad / navegador, Office Add-ins es el primer candidato.

La documentación oficial de Microsoft también explica que Office Add-ins se construye con HTML / CSS / JavaScript, funciona en varias plataformas y también es apto para la distribución centralizada.⁵

Esto encaja, por ejemplo, con requisitos como los siguientes.

• Querer conectar Office con un portal interno o un sistema central
• Querer mostrar la misma interfaz o los mismos comandos en Outlook, Excel y Word
• Querer una distribución gestionada por el administrador, en lugar de una distribución de macros por PC
• Querer alejarse del modelo de distribución local basado en .xlsm

Como el terreno es distinto al de VBA, la sensación de escribir código dentro de Excel cambia bastante. A cambio, la operación y la distribución son más fáciles de organizar.

7.5 Si Excel o Access ya no cumplen su función original como interfaz, migrar a una aplicación de Windows o web

Si ya se ha llegado a un estado como este, es más natural rehacerlo como una aplicación que prolongar la vida de VBA.

• Las transiciones de pantalla y el control de permisos se han vuelto excesivos
• El centro pasa a ser la base de datos, el registro de auditoría, el flujo de aprobaciones o la gestión de usuarios
• Hay integración con equipos externos o procesos de larga duración
• Las celdas o los formularios de Excel han terminado sustituyendo a las especificaciones de negocio
• Resulta doloroso que el estado desaparezca al cerrar el libro

En este caso, si la herramienta de negocio está pensada para Windows, una aplicación de escritorio en C# / .NET encaja mejor; si los usuarios o los dispositivos son diversos, una aplicación web permite una estructura más natural.

8. Cómo llevar a cabo una migración por etapas

Lo más peligroso al reemplazar VBA es intentar volcarlo todo, desde el principio, hacia una sola tecnología nueva. En la práctica, en general es más seguro avanzar por etapas, en el orden que se describe a continuación.

8.1 Primero, elaborar un inventario de activos

Lo primero que conviene identificar no es tanto la cantidad de código como las dependencias.

• Qué archivos .xlsm / .xlam / .accdb / .mdb existen
• Cuáles son la puerta de entrada real de la operación
• Qué hay en las referencias configuradas
• Qué Declare, DLL externas o componentes COM / ActiveX / OCX existen
• Cómo está definido el supuesto de 32 bits / 64 bits
• Qué macro usa quién y con qué procedimiento
• Cuáles son las salidas (Excel, CSV, PDF, impresión, envío de correo, etc.)

Si se avanza en el reemplazo dejando esto en la ambigüedad, más adelante se producen accidentes del tipo «una macro que nadie creía usar seguía viva, solo a fin de mes».

8.2 Dividir el código por responsabilidades

Lo siguiente es dividir, no por archivo, sino por unidad de responsabilidad.

• Manejo de la interfaz de Excel / Access
• Entrada y salida de hojas
• Diseño de informes
• Reglas de negocio
• E/S de API externas, archivos o bases de datos
• Procesamiento por lotes
• Impresión / distribución

Con esta división, se vuelve más fácil ver qué conservar, qué reducir y qué sacar hacia fuera.

8.3 Decidir el destino de migración según cada responsabilidad

El reparto que resulta más recomendable es este.

• Interfaz y manipulación de hojas: se dejan en VBA por el momento
• Lógica de negocio: se saca hacia una DLL de .NET, un proceso aparte o un servicio
• Generación de informes sin supervisión: se traslada a Open XML o a una generación directa
• Flujos de trabajo de M365: Office Scripts + Power Automate
• Interfaz multiplataforma: Office Add-ins
• Áreas convertidas en sistema de negocio: se separan hacia una aplicación de Windows o web

Lo importante es no unificar el destino de migración en uno solo. El contenido de los activos VBA suele mezclar, en general, varias responsabilidades a la vez.

8.4 Fijar primero la interfaz

Antes de empezar la migración, conviene decidir al menos lo siguiente.

• Cuál es la entrada
• Cuál es la salida
• Cómo se devuelve el error
• Qué hoja, qué rango con nombre y qué ruta de archivo se convierten en «contrato»
• En qué momento se considera que el resultado queda confirmado

Si se avanza sin decidir esto, la propia dirección de celda termina convirtiéndose en la API, y el conjunto se vuelve frágil.

8.5 Comparar mediante ejecución en paralelo

En especial los informes y las agregaciones, es más seguro no cambiarlos de golpe.

• Sacar en paralelo la versión antigua en VBA y la nueva implementación
• Comparar los .xlsx / CSV / PDF resultantes
• Verificar las diferencias en fechas, redondeos, formato y área de impresión
• Probar también los casos excepcionales y los de datos vacíos

Los accidentes al reemplazar VBA suelen ocurrir no tanto por «si funciona o no», sino en la forma de que los números o el formato se desvíen en silencio.

9. Errores frecuentes

9.1 Empezar con «VBA es antiguo, así que todo a Office Scripts»

Office Scripts es una opción sólida, pero la propia Microsoft explica que VBA cubre una gama más amplia de funciones de Excel de escritorio. Además, Office Scripts no admite eventos a nivel de Excel.⁴

Por eso, la idea de trasladar tal cual una macro con una dependencia profunda del Excel de escritorio es arriesgada.

9.2 Seguir iniciando Excel aunque la ejecución sea sin supervisión

Esto es bastante frecuente. Mientras funciona, parece cómodo, pero Microsoft no recomienda la automatización de Office en el lado del servidor.⁶

Si se trata de un proceso batch nocturno o un servicio, es más seguro inclinarse hacia construir el archivo de Excel en lugar de hacer funcionar Excel.

9.3 Cambiar a la vez pantallas, informes y reglas de negocio

Lo que de verdad da miedo al reemplazar VBA no es la propia conversión de código, sino la pérdida de especificaciones de negocio. En las hojas de Excel o en los formularios de Access suelen estar enterradas bastantes reglas operativas que no están escritas en el código.

Si se cambia todo de golpe, es fácil que se produzcan accidentes del tipo «el aspecto es parecido, pero solo a fin de mes es distinto».

9.4 Dejar para después los 32/64 bits y las referencias externas

En los proyectos de migración, con frecuencia lo que explota primero no es el propio código VBA, sino elementos como

• Declare
• DLL externas
• COM / ActiveX / OCX
• La arquitectura de bits de Office
• Las referencias configuradas

Si se posterga esto, se vuelve muy pesado de golpe hacia el final de la implementación.⁷

9.5 Confundir el tema de VBScript con el de VBA

La eliminación gradual de VBScript es, visto desde VBA, un tema de revisión de parte de sus dependencias. No significa lo mismo que el fin de VBA en su conjunto.¹⁰

Si se mezclan ambos temas, es fácil que se difunda por la organización, sin más matiz, información imprecisa del tipo «parece que VBA se va a terminar».

10. Resumen

En una frase, VBA es un lenguaje de extensión muy pegado a las aplicaciones de escritorio de Office. Junto a Excel o Access, para automatizar el trabajo que el usuario tiene entre manos, sigue siendo hoy bastante práctico.¹

Sin embargo, lo importante para el trabajo diario de ahora en adelante es no tratar VBA como una tecnología central que lo resuelve todo.

• Si se necesita navegador / multiplataforma, mirar Office Scripts u Office Add-ins⁴⁵
• Si se necesita ejecución sin supervisión / procesamiento en servidor, evitar la automatización de Office⁶
• La lógica pesada o la integración externa, sacarla hacia .NET o un proceso aparte
• Si Excel o Access ya sufren como interfaz, migrar a una aplicación de Windows o web

La respuesta no es «reemplazarlo todo» ni «no cambiar nada», sino «dividir por responsabilidades e ir reduciéndolo por etapas».

Visto por encima, los activos VBA parecen antiguos. Pero, en la práctica, dentro de ellos hay bastante acumulado en forma de especificaciones de negocio, procedimientos operativos, diseño de informes y costumbres del personal.

Precisamente por eso, el reemplazo es más seguro llevarlo adelante no como una traducción, sino como una reorganización.

11. Artículos relacionados

• ¿Qué son COM / ActiveX / OCX? - Diferencias y relación explicadas
• Cómo usar una DLL de .NET 8 desde VBA con tipado - Exposición COM y dscom TLB
• Cómo generar informes de Excel - COM/Open XML/plantillas

12. 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.

¿VBA dejará de poder usarse en el futuro?

Al menos hasta marzo de 2026, no se puede confirmar ningún anuncio oficial claro de Microsoft de que «VBA en sí vaya a terminarse pronto». Lo que está ocurriendo no es una eliminación repentina y total, sino un cambio en el que se están precisando los lugares donde se puede usar y las condiciones previas. En concreto, en Excel for the web no se pueden crear, ejecutar ni editar macros VBA, y las macros de archivos procedentes de internet se bloquean de forma predeterminada. Es más natural ver el futuro de VBA como una delimitación de sus fronteras que como una desaparición.

¿Basta con migrar todo VBA a Office Scripts?

No lo recomendamos. La propia Microsoft explica que, por ahora, VBA cubre una gama más amplia de funciones de Excel disponibles en el cliente de escritorio, y Office Scripts no admite eventos a nivel de Excel. Es más exacto ver Office Scripts no como un sustituto de VBA, sino como una pieza de automatización dentro de Microsoft 365 que combina libros de OneDrive o SharePoint con Power Automate. Lo realista es elegir el destino de migración según cada responsabilidad por separado.

¿Se puede ejecutar una macro de Excel sin supervisión en un servidor o en un proceso batch nocturno?

Es peligroso. Microsoft afirma explícitamente que no recomienda ni admite la automatización de aplicaciones de Office en el lado del servidor. Office está diseñado partiendo de un escritorio interactivo y un perfil de usuario, por lo que en un entorno sin supervisión pueden producirse inestabilidad o interbloqueos. Si el requisito es generar informes en grandes volúmenes, se recomienda construir el archivo de Excel directamente, por ejemplo con el formato Open XML, en lugar de iniciar la aplicación Excel.

¿Cómo se deberían migrar los activos VBA existentes?

Lo más seguro es una migración por etapas, sin volcar todo desde el principio hacia una sola tecnología nueva. Primero se elabora un inventario de activos: los archivos .xlsm, las referencias configuradas, las DLL externas, los supuestos de 32/64 bits, etc., y se separa el código por responsabilidades —operación de la interfaz, lógica de negocio, informes, E/S—. A partir de ahí, se decide el destino de migración según cada responsabilidad: la interfaz y la manipulación de hojas se dejan en VBA por el momento, la lógica de negocio se traslada a una DLL de .NET o a un proceso aparte, la generación de informes sin supervisión pasa a Open XML, y los flujos de trabajo de M365 pasan a Office Scripts. En el caso de informes y agregaciones, conviene ejecutar en paralelo el sistema antiguo y el nuevo, comparar las salidas y solo entonces hacer el cambio definitivo.

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.