Let’s be honest: when most developers hear "Classic ASP," they picture legacy Windows Servers, clunky COM object registrations, and an architecture deeply entangled with asp.dll and the IIS worker process (w3wp.exe).
But the code itself—often thousands of lines of critical business logic written in VBScript or server-side JavaScript—still does exactly what it needs to do. The problem isn't necessarily the language; it’s the aging, monolithic hosting architecture.
This is where AxonASP changes the game. Built in Go, it completely untangles ASP from the Windows OS, executing code natively and dropping idle memory usage down to around 18MB.
However, moving to this engine requires a fundamental shift in how you think about hosting your applications.
The Paradigm Shift: Application-Centric Architecture
Now, regarding your biggest concern about hosting architecture: AxonASP is not a direct replacement for IIS; it is a Classic ASP runtime. It operates on a modern, application-centric architecture—structurally identical to how modern .NET Core or Docker applications are deployed.
This means all your existing IIS configurations remain entirely valid. To properly orchestrate AxonASP within IIS, you must use the HttpPlatformHandler v1.2+ module. You can read more about the setup in the official manual here:
For example, in the axonasp.toml file, you can set the root directory to match your default IIS site directory. This allows you to serve your static files (CSS, JS, images) through IIS natively while AxonASP handles the application logic and dynamic .asp requests.
The whole idea is to universalize and implement modern administration practices for ASP so it can run on any platform or server. This way, if one website runs out of control or exhausts its memory, it won't crash the other applications or the main server, because every application runs its own distinct, isolated instance of axonasp-http.exe.
This setup also allows you to run ASP inside Docker containers, significantly reducing the costs associated with Windows servers. It might seem a bit complicated at first, but it is definitely worth migrating to this approach—it is more secure, highly distributable, cheaper, and ultimately easier to manage.