When porting legacy a legacy asp application to IIS8 there is a number of additional configuration steps required. Classic asp doesn't automatically run. Once you have this configure, you'll need to test (and possibly debug) the application before deploying to production. When you first try to browse a asp application in IIS8, you'll be presented with a screen citing an extension configuration error.
This is because classic asp (and handlers) are not installed. These features need to be added to the web server role.
Once these features are added, you'll need to test you site works as expected. Unfortunately if any errors are encountered, you are prompted with an user friendly message, rather than the error itself.
To send error messages to the browser, additional ASP configuration is required within Internet Information Services Manager. This can be configured at the server or site level. Select the "ASP" button, drill down into the debugging properties and set the Send errors to browser property to true.
You'll now receive the familiar error feedback when refreshing the browser
This can be be taken a step further by installing the Tracing feature and enabling Failed Request Tracing for a given status code (typically 500)
Breaking this down
Install the Tracing feature (under health and diagnostics)
Configure the Tracing
Add a Tracing rule
Once this is configured there should be a new folder within C:\inetpub\logs called FailedReqLogFiles which will capture all the failed requests in XML log files.
Now, when you refresh the site, you'll be present with the standard HTTP Status code 500, but if you browse to the FailedReqLogFiles you get a detailed breakdown of whats going on
A detailed post Using Failed Request Tracing to troubleshoot Classic ASP errors explains how to make the most of this tracing feature