Modernizar Classic ASP hosting con AxonASP

¿Se puede modernizar Classic ASP sin tirar a la basura miles de líneas de VBScript que todavía funcionan? Sí. AxonASP es un runtime escrito en Go que ejecuta tu código ASP clásico fuera del sistema operativo Windows y baja el consumo de memoria en reposo a unos 18MB. Para modernizar Classic ASP sin reescribir nada, AxonASP corre detrás de IIS apoyándose en el módulo HttpPlatformHandler v1.2+.

AxonASP es un motor de ejecución (runtime) para Classic ASP construido en Go, presentado por Lucas Guimarães en una guía técnica publicada el 19 de junio de 2026. No reemplaza a IIS: ejecuta el código VBScript o JavaScript del lado servidor de forma nativa, desacoplado del worker de Windows, con una arquitectura centrada en la aplicación parecida a la de .NET Core o un contenedor Docker.

En 30 segundos

Qué es: AxonASP, un runtime de Classic ASP hecho en Go que ejecuta VBScript fuera del SO Windows.
El número que importa: consumo en reposo de alrededor de 18MB, contra los megabytes que se come el worker de IIS tradicional.
No es un reemplazo de IIS: corre detrás de IIS usando el módulo HttpPlatformHandler v1.2+, así que tus configuraciones actuales siguen valiendo.
La idea de fondo: arquitectura application-centric, igual que .NET Core o Docker, sin registrar objetos COM en el SO.
Para quién: empresas con código ASP crítico que no pueden reescribir a .NET pero quieren bajar su dependencia de Windows Server.

Hosting es un servicio que proporciona espacio en servidores para almacenar archivos y aplicaciones de sitios web, permitiendo que sean accesibles a través de Internet. Los proveedores de hosting gestionan la infraestructura física y conectividad necesaria para mantener los sitios en línea.

¿Por qué tantas empresas siguen atadas a Classic ASP?

Ponele que entrás a un panel de administración interno de una empresa mediana y, abajo de todo, ves un .asp en la URL. No es un museo. Es código que factura, que mueve stock, que liquida sueldos.

El problema casi nunca es el lenguaje. Como lo plantea la guía original, el VBScript o el JavaScript del lado servidor “todavía hace exactamente lo que tiene que hacer”. Lo que envejeció mal es la arquitectura de hosting: registros de objetos COM, dependencia total del proceso worker de IIS y un acople tan profundo con el SO que mover la aplicación a otro lado es un dolor de cabeza. Lo explicamos a fondo en opciones de cloud hosting modernas.

Acá viene lo interesante. Reescribir todo a .NET Core suena lindo en una reunión, pero cuesta plata, meses y un equipo que entienda la lógica vieja (que muchas veces ya no está en la empresa). Por eso la mayoría elige no tocar nada. AxonASP apunta justo a ese punto medio: modernizar el hosting sin reescribir la aplicación.

¿En qué se diferencia AxonASP del hosting tradicional con IIS?

La diferencia central es conceptual. IIS tradicional ejecuta tu ASP dentro de su propio proceso, atado a COM y al sistema operativo. AxonASP ejecuta el código por su cuenta, en Go, y se pone detrás de IIS como una aplicación independiente.

Aspecto	IIS tradicional (Classic ASP)	AxonASP detrás de IIS
Motor de ejecución	Worker de IIS (w3wp), atado al SO Windows	Runtime en Go, desacoplado del SO
Memoria en reposo	Megabytes (varía según pool)	~18MB
Objetos COM	Registro en el SO obligatorio	Arquitectura sin registro COM en el SO
Arquitectura	Monolítica, centrada en el servidor	Application-centric (como .NET Core o Docker)
Rol de IIS	Ejecuta el ASP	Hace de front: estáticos y reverse proxy
Portabilidad	Atada a Windows Server	Pensada para portar a Docker/Linux

modernizar classic asp hosting diagrama explicativo

El patrón es el de un reverse proxy. IIS recibe el request, sirve los archivos estáticos (CSS, JS, imágenes) y le pasa lo dinámico al proceso de AxonASP, que devuelve la respuesta. Tus configuraciones de IIS siguen siendo válidas, según la documentación oficial. No empezás de cero.

¿Qué necesitás para correr AxonASP detrás de IIS?

Los requisitos son pocos, pero hay uno que no es negociable.

El módulo HttpPlatformHandler v1.2 o superior: es la pieza que orquesta AxonASP dentro de IIS. Sin esta versión, no hay setup. La guía es explícita en este punto.
El binario de AxonASP y su archivo de configuración: AxonASP trae su propio ejecutable y un axonasp.toml donde definís, entre otras cosas, el directorio raíz.
Permisos de directorio correctos: la identidad con la que corre el sitio (típicamente la ApplicationPoolIdentity o el grupo IIS_IUSRS) tiene que poder leer y ejecutar en la carpeta de la aplicación.
Un SO Windows compatible con IIS: seguís usando IIS como front, así que el servidor sigue siendo Windows por ahora.

Un detalle práctico del axonasp.toml: podés apuntar el directorio raíz al mismo directorio del sitio por defecto de IIS. Así IIS sirve los estáticos desde ahí y no duplicás archivos. Cubrimos ese tema en detalle en solucionar problemas de hosting comunes.

¿Cómo se configura AxonASP en IIS paso a paso?

La guía oficial tiene el manual completo, pero la lógica del armado es esta:

Instalá HttpPlatformHandler v1.2+ en el servidor IIS. Es el requisito que habilita todo lo demás.
Descargá el binario de AxonASP y dejalo en la carpeta de tu aplicación junto con el axonasp.toml.
Configurá el directorio raíz en el .toml para que coincida con el directorio del sitio por defecto de IIS y sirva los estáticos desde IIS.
Declará el handler en el web.config: HttpPlatformHandler arranca el proceso de AxonASP, le asigna un puerto interno por variable de entorno y le hace de proxy. Esa es la forma estándar en que este módulo levanta runtimes externos (lo mismo que hace con Node, Java o Python).
Validá que el proceso levante: si IIS no logra arrancar el ejecutable, casi siempre es permisos o una ruta mal puesta en el handler.

Para los nombres exactos de binarios y los valores precisos de configuración, conviene seguir el manual de soporte de IIS de AxonASP en vez de copiar valores de memoria. La parte que sí o sí tenés que respetar es la versión del módulo.

¿Cómo migrar aplicaciones ASP legacy sin romper todo?

Migrá con red. La regla de oro es no tocar producción hasta que staging te haya dado la razón.

Antes de mover nada, revisá qué objetos COM usa tu aplicación y qué tan acoplada está al SO. Esa auditoría te dice si la migración va a ser tranquila o si hay dependencias que necesitan atención especial. Después armás un ambiente de staging idéntico, levantás AxonASP ahí, y probás los flujos críticos: login, escritura en base, sesiones.

Ojo con el estado de sesión. Classic ASP guarda sesión in-memory, así que validá que el manejo de Session se comporte igual bajo el runtime nuevo antes de confiar. Y dejá el rollback preparado: si algo no cierra, volvés al IIS de siempre sin drama. Subís el runtime, lo probás en staging, validás sesiones y base, monitoreás un par de días, y recién ahí lo dejás fijo en producción.

¿Cuándo conviene elegir AxonASP?

Cuando tenés código crítico que no podés reescribir

Aplicaciones que facturan o liquidan y no pueden parar para una reescritura de meses. AxonASP moderniza el hosting sin tocar la lógica. Para más detalles técnicos, mirá estrategias DevOps para infraestructura.

Cuando querés bajar tu footprint de Windows Server

Los 18MB en reposo y la arquitectura desacoplada apuntan a reducir recursos. Si después querés mover infraestructura a un hosting más liviano o a un VPS, la portabilidad a Docker/Linux que promete el proyecto juega a favor. Para alojar ese tipo de cargas en Argentina, donweb.com tiene planes de hosting y VPS que te sirven de destino.

Cuando no hay presupuesto para .NET Core

Equipos chicos sin plata ni gente para migrar a .NET completo. Acá AxonASP es el camino del medio: modernizás el cómo se hospeda, no el qué hace la aplicación.

Errores comunes al migrar a AxonASP

Instalar una versión vieja de HttpPlatformHandler: si no es v1.2 o superior, AxonASP no se orquesta bien dentro de IIS. Verificá la versión antes de pelearte con el resto.
Olvidarse de los permisos de la carpeta: el error más típico. Si la ApplicationPoolIdentity o IIS_IUSRS no puede ejecutar el binario, el proceso ni arranca y IIS falla silenciosamente y te devuelve un 500 Internal Server Error.
Asumir que AxonASP reemplaza a IIS: no lo hace. Es un runtime de Classic ASP, no un servidor web. IIS sigue al frente sirviendo estáticos y haciendo de proxy.
Migrar directo a producción: sin staging y sin probar el manejo de sesiones in-memory, te exponés a romper flujos en vivo. Probá primero.

Qué está confirmado y qué no

Confirmado (de la guía publicada el 19 de junio de 2026): AxonASP está construido en Go, ejecuta Classic ASP de forma nativa fuera del SO Windows, tiene un consumo en reposo de unos 18MB, no reemplaza a IIS sino que corre detrás con HttpPlatformHandler v1.2+, usa una arquitectura application-centric y un axonasp.toml para configurar el directorio raíz.

Pendiente o sin confirmar de forma independiente: los benchmarks de memoria son del propio proyecto, así que tomalos con pinzas hasta que haya pruebas de terceros. La portabilidad real a Docker/Linux está planteada como dirección de la arquitectura, pero conviene validarla en tu caso antes de prometerla. Y los nombres exactos de binarios y puertos dependen de la versión del manual: verificalos en la documentación oficial, no de oído.

Preguntas Frecuentes

¿Qué es AxonASP?

AxonASP es un runtime de Classic ASP escrito en Go que ejecuta código VBScript o JavaScript del lado servidor fuera del sistema operativo Windows. Fue presentado en una guía técnica publicada el 19 de junio de 2026 por Lucas Guimarães. Relacionado: automatizar el deployment con CI/CD.

¿AxonASP reemplaza a IIS?

No. AxonASP es un runtime de Classic ASP, no un servidor web. Corre detrás de IIS usando el módulo HttpPlatformHandler v1.2+, mientras IIS sigue sirviendo archivos estáticos y haciendo de reverse proxy.

¿Cuánta memoria consume AxonASP?

Según la guía oficial, el consumo en reposo ronda los 18MB, bastante por debajo del worker tradicional de IIS. Es un dato del propio proyecto, así que conviene validarlo con pruebas independientes.

¿Puedo correr Classic ASP fuera de Windows Server?

El runtime de AxonASP está hecho en Go y desacoplado del SO, con una arquitectura pensada para portarse a Docker o Linux. En el setup descrito sigue usando IIS como front, así que la independencia total del SO es una dirección del proyecto más que un hecho cerrado hoy.

¿Qué necesito para empezar a usar AxonASP?

Necesitás IIS con el módulo HttpPlatformHandler v1.2 o superior, el binario de AxonASP, su archivo axonasp.toml y los permisos de directorio correctos para la identidad del pool. El requisito que no podés saltear es la versión del módulo.

Conclusión

AxonASP cambia la pregunta. Ya no es “reescribimos todo el ASP o lo dejamos pudrirse en un Windows Server viejo”, sino “¿y si modernizamos solo el hosting?”. Un runtime en Go, 18MB en reposo, detrás de IIS con HttpPlatformHandler v1.2+, sin tocar la lógica de negocio.

Si tenés aplicaciones Classic ASP críticas y ningún presupuesto para migrar a .NET Core, el camino concreto es este: auditá tus dependencias COM, armá un staging, probá el manejo de sesiones, y recién después tocá producción. La promesa de portar a Docker/Linux es atractiva, pero hasta que la valides en tu propio caso, tratala como dirección y no como garantía.

Modernizar Classic ASP con AxonASP detras de IIS