Asp MVC section and partial views

Let me start off by saying, "I feel your pain, brutha." I went through this 3 years ago, and I wish MVC had matured at that point because the WebForms solution I designed fairly well resembles the MVC model without actually having the Microsoft libraries built for me (of course, there were several glaring "Why the hell did I do that" differences).

I also ended up using iFrames to manage the content differences using .Net as the parent application and classic asp as the slave. I developed the framework architecture in .Net and implemented that. The classic asp pages were then "culled" of unnecessary presentation pieces (includes and whatnot) and loaded into iFrames. Data was then passed in through the url using a custom encryption. To make sure that the authentication could not be spoofed easily and the page accessed by cracking the query string we also employed Wildcard handlers in IIS that forced .Net to authenticate before parsing classic asp pages.

Given that, my recommendation would be to head to MVC straight away.

1. MVC will give you access to routing at the global.asax level. With clever manipulation of a controller, you could develop your models in a proper fashion and have a common controller that handles all classic asp requests as necessary.
2. MVC will make it very simple to add a test project and allow you to refactor individual application pieces based on the new model structure while providing adequate test coverage to make sure you're getting it all right. The value of this is absolutely incalculable because in any refactor code coverage is a huge concern.
3. MVC follows a more scripted approach to presentation than WebForms does. WebForms tries to mix it all up like it's some kind of stateful application (which it isn't), and that can be quite a culture shock for people accustomed to classic asp. Don't get me wrong, your developers are going to have culture shock no matter which way you go, but if you can take some of that shock out of the presentation layer you might find greater success.

I like both WebForms and MVC (though I'll admit with the introduction of Razor I'm becoming a little biased towards MVC). They both have their places, and I think an application such as the one you describe may be ideally suited for an MVC implementation particularly given the "staggered" nature you'll need to adopt in rolling out refactored application pieces.

Whichever way you go, I think you need to make sure that the .Net application is always the parent application when it comes to authentication/authorization/routing/etc. A colleague of mine implemented his migration on a similar application with classic asp as the parent, and he had a large number of problems when it came finally to integrating everything back together.

Actually, building individual views for each of the IContract classes would not be breaking DRY -- presumably they have some different info with different needs. You aren't repeating yourself, you are successfully using polymorphisim.

I had a somewhat similar conoundrum for a project MVC1 project -- before DisplayFor provided a pretty good built-in solution. We used MVC Contrib's RenderAction delegates to send the polymorphic object off to a specialized controller that was responsible for dispatching things to the appropriate rendering pipeline. The internals get a bit squirrely, but it has been a rock solid system for us for 3 years or more.