Out with the old, in with the new

So I've been working on integrating Classic ASP with MVC 5 on the "same" web site.  The client has a lot of old classic asp code with business logic in there that is not feasible to move all at once, but wants any new functionality to be in MVC.  This has posed a number of interesting challenges, from security integration (it can be done!  I'll go into the details of that in another post) to access to the request and response objects between .net and native code (the classic asp).  Interesting fact, if you access the request or response object from .net, native code in the same app pool can no longer access them.  That makes for lots of fun.  So I saw two choices, either let the classic asp be the "root" of the web site as it had been, or put MVC in charge.  The two choices bring different pros and cons.  Putting classic asp at the root requires only two separate application pools, but then you have to bury all the .net stuff into an application underneath the root, so any .net code would be in a sub folder (i.e. http://site.com/MVC/controller/action/id, instead of http://site.com/controller/action/id).  Putting MVC at the root and you get a different issue, namely that you then have to make applications out of every folder where classic asp lives in order to keep them in a separate application pool from the root .net code.  However this allows MVC to live at the root and lets the controllers, views, etc work from there instead of a sub folder.  I opted to go with MVC at the root, as I think this will allow a smoother migration path from classic asp to MVC where we don't have to update links to everything when migrating the classic asp pages (i.e. they won't have to live in that subfolder).  However this will necessitate migrating entire folders at once to avoid the link updates, as the .net code and the classic asp code won't live merrily together in the same application.  I think this is a fair trade-off to move forward with.