I want to port an existing, legacy, ecommerce website from ASP to ASP.NET.
What approaches do I have ?
is there a way to run an ASP file with an ASP.NET engine ?
are there tools to automatically convert ASP to ASP.NET and do they work on complex websites ?
other approaches ?
Thanks for your help
Jerome Wagner
No, but if you have Asp.NET on the server, that doesn't mean the Asp pages won't run anyway. Having Asp.Net installed does not break classic asp. However, newer versions of Windows come with classic Asp turned off by default, so you have to go into add/remove programs/add/remove windows components and drill down to install asp. And there's nothing to prevent you from having asp pages sitting side-by-side with Asp.Net pages in te same website, or even the same directory, so really the first question si not really an issue.
I've never heard of them. Classic ASP is so different from Asp.NET that it's just not feasible.
Manually, one page at a time. And that is an approach that has issues because sharing session between Asp and Asp.Net is not trivial and relies on hacks.
I know this isn't an answer to your question and it's probably none of my business, but in my experience, this may be a good time to look at a commercial ecommerce site. Several are out there at good prices. The amount of time you'll spend on this may be way less than you'd spend. Also, PCI rules and security issues have changed so much since classic Asp was a "real" development platform that you're definitely better off with a commercial app.
I say this from experience. We just replaced our old shopping cart with a commercial one after spending quite a bit of time going back and forth on our best approach. If you can afford it, i strongly recommend it.
The other answers are valid, so I'll only add that there is a migration tool of sorts provided by microsoft: The ASP to ASP.NET 1.x Migration tool . It doesn't claim to completely migrate a site, but may assist with a large portion of it. Of course, this assumes that a asp.net 1.1 site will run just fine on the latest incarnation of asp.net.
Step 1. Gather requirements for the new system
Step 2. Does anything exist that already meets your needs? if so, stop here and buy it.
Step 3. Build a data model and screen designs.
Step 4. Does the new system jive with the stake holders expectations. Go back to step 1 if necessary.
Step 5. Code new site
If necessary, review various standard project templates (scrum, waterfall, whatever). Pick one and stick to it.
You'll notice a distinct lack of anything remotely related to "converting" the old code / data files to the new platform. This is to preserve your sanity and help ensure the project will be a success.
To answer the actual question: no. You might as well have asked if there were tools to convert a php site to java. They are radically different things with their own approaches.
Related
I am new to ASP.NET. and having big job converting ASP E-commerce website (It has lots of things those are customised like business logic, having own Database structure) to ASP.NET. Here, I am getting confused with some issues... I am writing this here after having lots of thinking of these issues but still they are unsolved. I have estimated 8-10 weeks for these job, and this is 2nd week is going on...
Is it better to create E-Commerce website from scratch or Modify current available Solutions?
If Creating new one, than which one is better ? ASP.NET Web Forms using N-tier Structure or MVC (Having no experience in this)
Is it true that MVC makes website access faster than Web Forms does?
Or its better to take some time, learn MVC and go ahead?
I think, may be there are questions like these, than please redirect me on that.
Thanks.
If you know web forms, use web forms. Web forms is still a good technology with great third-party controls. There's no reason to use an unfamiliar technology.
I looked up the EF mentioned and came across http://efvote.wufoo.com/forms/z7x3p9/
Apparently there is a list close to 1000 experts including MVPs that state that EF is no longer a viable option unless MS invests in its improvement.
I have been looking at ASP.Net Web Pages and I think it would be a good replacement for some classic asp sites I am working on. There is a lot about them that is similar to how classic asp did things, so I believe there is a chance I can drag the other programmers into the present. My problem is that I have yet been able to find any indepth documentation to see if there is any "gotchas" I need to be aware of if I choose to go down this path. So if anyone knows of any, I could really use that information. I think going straight to MVC and Web Forms would be a bridge too far for the others at the moment. Thanks.
Wade
I found a link from Mike Brind - should I use WebMatrix to build a real-world website?
I'd suggest that Web Pages as a framework is probably the best next step you can take, but I would also advise that at least one person in the team takes time to understand the basics behind the MVC pattern. You may decide it's too much for the majority of the team at the moment, and that's fair enough, but you can use your knowledge to plan the development of the Web Pages site so that it can be more easily converted to MVC at some stage in the future, should you decide that's the way to go.
The things I would look at (coming from a classic ASP background myself) are functions and helpers. Decide on a data access strategy - The Entity Framework works well with Web Pages and can be transferred to MVC easily. Avoid the Database helper. Use Visual Web Developer 2010 SP1 for the Intellisense option.
As Knox said, you have the whole of the ASP.NET framework available to you so there should be no Web Pages specific "gotchas", and it's a massive step up from classic ASP.
I've been using Webmatrix/WebPages/Razor for a while now and like it. It's been a while since I used Classic ASP, but WebPages to me feels like a true successor to classic asp and what ASP.net should have been from the start. I'm actually moving most of my smaller sites to the WebPages framework from WebForms. Here are some things I've encountered.
I'm not sure if this is a gotcha or not, but I thought I would mention that with WebPages the scope of your variables may behave differently. I know a lot of Classic ASP sites that used to use include files to run snippets of code. Many of them depended on global variables set in the parent document. In WebPages, if you use RenderPage or Helpers to replace includes they run mostly outside of the Parent's scope. If you used Server.Execute instead of includes then you might not notice much difference, but if you did use includes and lots of global variables you may notice it.
Another possible gotcha is in ClassicASP <%=%> doesn't encode output, but in WebPages the Razor syntax # encodes output by default.
Another thing to consider is using C# vs VB.net with Webpages. Although vb.net works you'll find that most samples, tutorials and people in forums use C#.
Finally something that bothers me is that it is named the "webpages" framework. I've found it hard to do a good Google search using the term "webpages". Even "asp.net webpages" brings back mostly webform results. I have more success using "webmatrix" or "razor".
Can't recommend any documentation but here is an introduction to Web Matrix on mikesdotnetting.com blog where he has blogged quite a lot about Web Pages with Web Matrix.
We have two production sites, developed using Web Matrix. One serves our customers, the other is an intranet for our staff. They've been running in production for almost a year. I'd say about 95% of the sites were developed purely in WebMatrix IDE with about 5% going into Visual Studio, especially for the occassional obscure debugging. We're happy with WebMatrix / Web Pages. I didn't use WebForms because I was concerned about WebForm's ability to do really lightweight pages, since many of our users are using cellular data on iPads or iPhones. I didn't use MVC because of the additional complexity, since many of our pages are just showing the user read-only data from our production database. Because WebMatrix gives you access to the complete ASP.NET library, I haven't felt held back at all.
We are currently converting our ASP pages to Web Matrix. We tried to do conversions using WebForms a few years ago, only ending in frustration. After a small learning curve on the C# and Razor syntax, our development staff feel that we made a correct decision in going with Web Matrix.
We need to develop quite a powerful web application for an investment bank. The bank IT would like us to build it on top of the SharePoint platform, but we would prefer to do pure ASP.NET programming.
The web-app should have the following characteristics.
1) It will be a site for bank's clients that will allow them to view their stock portfolios, get miscellaneous reports with graphs and charts, etc.
2) The web-app will also allow clients to send orders to the bank to buy stocks and perform other financial operations.
3) The number of users will be approximately 3 000 000 (total) and 20 000 at any one time.
We have never made any SharePoint programming, but as far as I know, SharePoint is primarily designed to create intranet sites for colleagues to communicate with each other and work more efficiently, to maintain a document library, etc.
However, the bank IT told us that SharePoint has in fact lots of other features that will help us make the project more efficiently - for example, it seems that SharePoint has some built-in scalability and high availability technologies.
I heard saying that SharePoint development is very tedious, that the platform cannot be very easily customized, etc.
The question is: is it better to create our web-app on pure ASP.NET and deal with scalability and other issues ourselves, or base it on SharePoint - taking into account that the web-app we need to create is non-standard and complex?
Thank you,
Mikhail.
UPDATE
In the answers, someone suggested using ASP.NET MVC. My another question is: should we use "classic" ASP.NET or ASP.NET MVC for such project (if we leave out the SharePoint option)?
Do you need document management? Do you need version management? Do you need to create "sites"? Do you need audience filtering? Do you need ECM (fancy word for CMS), Do you need collaboration stuff on your site? If your answer is no then SharePoint is not for you.
You said "We have never made any SharePoint programming" and for that reason alone I think you should not use SharePoint. You also say that your app is going to be "non-standard" and complex, another reason not to use SharePoint.
Sounds like you know ASP.NET so I would advice to stick with ASP.NET or ASP.NET MVC.
Hope this helps
The answer is simple, you should go with what you know. If you prefer to do it in ASP.NET then, that is what you should go with. Trying to learn a new technology on that size of a project will almost certainty cause you severe problems when trying to develop it. Can sharepoint scale to that number of users, probably, but you don't know how to make it do that. That is the real key.
They are correct SharePoint does have a lot of functionality out of the box, but that doesn't mean that it will make you more efficient, because you don't know all of the APIs etc. to access.
Actually, if you want to know the way to cheat. If they force you into using it, you can run ASP.NET applications under SharePoint (well kind of). You can tell SharePoint to essentially ignore a path in the site and use regular ASP.NET as a web application just like any other site does. Really, this isn't using SharePoint, but it can get you out of a bind, in the "Needs to use SharePoint to make them happy scenario".
Mayo suggested contacting MS. I have a feeling they already have a relationship with the bank and have provided some insight about the project. I would contact: http://www.mindsharp.com/ and see if they can help you out. They are a training company, but I bet that the owners would be willing to help consult, and I haven't found anyone with more knowledge on SharePoint than Todd Bleeker.
I'll not go into the merits of sharepoint, but suffice it to say that I have been developing in sharepoint since it was known as "digital dashboard" - it was just a javascript-encrusted today page for outlook. With respect to its .NET incarnations, it has taken me about 3 years to become what some might call "expert" on SharePoint 2007/MOSS.
First up, let me give you some warnings concerning the politics of these kind of jobs. As a contractor, ALL of my jobs over the last 6 years - covering shaerpoint 2003 and 2007 - WITHOUT fail, have been getting about me on site with a client who has demanded sharepoint, and a development shop with decent ASP.NET developers who have become hopelessly lost and more than likely have blown 95% of the budget on the last 5% of the project because they have embarked on writing custom extensions to the platform without fully understanding the product.
If clients, and the shops who service them, spent more time understand the product and studied it to see how they could change/streamline their business processes & requirements slightly to suit sharepoint instead of being rigid in their specs (that were ALWAYS written with next to zero real experience of the platform) and deciding to get custom development done, then more sharepoint projects would be delivered on time and on budget. Sadly, this is not the case.
So, number one: SharePoint 2007 is an excellent product, but please, for the love of jeebus, find yourselves some top gun sharepoint developers who really understands the product before you embark on this journey. If you don't, you will all go down in flames.
-Oisin
What a load of CRAP that sharepoint isn't cut out for what the op wants to use it for. Especially the "Do not get yourself wrapped up in SharePoint" comment from ChaosPandion. Maybe he thought it to difficult and gave up...
Sure SharePoint development takes some getting used to, but it is able to what is wanted by the op most definately. SharePoint is built using ASP.NET so anything you do in ASP.NET can be used / ported to SharePoint. It is not a standalone product, but a DEVELOPMENT PLATFORM. It will scale to serve that many users, using multiple WFE's (Web Front Ends) and a SQL Cluster as backend.
The question here is: is sharepoint the most suited platform for building this site? Then I would have to answer, probably not, seeing as the wanted functionality is almost all custom development. If you plan on doing web content management as well, then yes, SharePoint is definately worth looking into. Also, SharePoint takes away all (or at least most :-D) authorisation and authentication wories. It is Department of Defense certified. And if the offered out of the box security is not enough, just write an authentication provider (seeing as SharePoint uses ASP.NET's provider model).
To answer your questions:
The bank IT told us that SharePoint has in fact lots of other features that will help us make the project more efficiently - for example, it seems that SharePoint has some built-in scalability and high availability technologies.
SharePoint is farm based, to which you can add machines, having each machine perform a different task, which means either app server, index server, WFE, document conversion services., WFE's can be behind a load balancer to distribute requests. Also I want to mention the web content management again.
I heard saying that SharePoint development is very tedious, that the platform cannot be very easily customized, etc.
Like I said, SharePoint is based on ASP.NET, so it is as much customizable as ASP.NET is. You could even create an ASP.NET web site, put all UI in Controls and then use those is SharePoint, maybe even have the controls use it's own database. As for it being tedious, not really. It's just DIFFERENT and deployment / testing is not like normal deployment / testing. SharePoint uses so called solution files (.wsp files), to package up functionality and deploy it to the server. This IMHO makes it possible to deploy functionality in a very modular way. Furthermore, there are loads of cool open source projects out there that make sharepoint development much easier and also provide cool extensions to "pimp" your site and make it more fun and easy to use for end-users.
Nuff said....
SharePoint development can be tedious but I'd hardly say the platform cannot be easily customized. I recently began developing with it full time and so far, I impressed at it's flexibility and suitability for my application but my needs are quite different from what you've described.
I understand 2007 is a vast improvement over 2003 so perhaps your information is only outdated. I hear 2010 is going to again be a significant improvement.
It's your job to deliver the functionality that the customer desires. If they desire a SharePoint solution, unless there's some particular reason why SharePoint really is a weaker model, that's what you should be able to deliver. In the event that SharePoint isn't a good fit, you need to be able to explain why to the bank's satisfaction. I'm not convinced "We don't know SharePoint" is an acceptable response in this situation: the bank's inclination should, at that point, be to find someone who knows both technologies well enough to deliver a product in SharePoint or better explain why SharePoint isn't actually what they want.
UPDATE: After looking at this more I would add that I do not believe that SharePoint is for you. As I mention below SharePoint is for collaboration. If the users that come to the site require an isolated experience then SharePoint is more overhead than you need.
SharePoint is built on top of ASP.NET so you have everything that you want to do with ASP.NET in addition to what SharePoint provides. Anyone who says that it is difficult is trying to make it that way. You can deploy stand alone custom pages with 100% of your own code and it will run under sharepoint, or you can create new application pages that also contain any code you want to write, or you can simply add your own webparts that can be added to any page you choose with 100% of your own code.
Here is just one example.
Creating an Application Page in Windows SharePoint Services 3.0
What SharePoint offers on top of that is a whole different paradigm on collaboration tools. If you wish to leverage it (if not the cost on return is somewhat limited) you can build amazingly complex and integrated solutions that is build around the aggregation of data from across an enterprise.
That being said, do not go into it lightly. If deployed wrong or with a half understanding of where SharePoint excels and where it does not will result in a diaster. Unless you have the time to understand the core concepts of SharePoint I would warn against it but your client is right. If you do build it in SharePoint you get a great deal more flexibility. One right off the bat is the ability to mix authentication modes. I designed a solution that mixed custom forms authentication with an LDAP backend with Windows Authentication. Anyone could visit the same pages but your authenticated account could come from two different locations.
This is a matter of what kind of concerns you want to have in the application:
Building it to look and function your way, go with sharepoint.
Building it to have infrastructure for authentication, permissions, http/web security, scalability, backup, database maintenance PLUS getting it to look and function your way (but now way more under your control), go with a more pure .NET approach.
I would pick the one I am best at, as Kevin said above.
Edit
More about Kevins post: you can also have your application under sharepoint but with full access to the API, in my projects we do it as a normal ASP.NET application, with own masterpages and everything, but we still use the authentication, lists and doc libraries for uploads, roleassignments for permissions etc. Its a very viable hybrid.
You said,
I heard saying that SharePoint
development is very tedious, that the
platform cannot be very easily
customized, etc.
You have been misinformed about SharePoint. All SharePoint pages are ASP.NET pages. You can customize any of them, either directly, or by using Microsoft Office SharePoint Designer, which is free.
Get started at http://msdn.microsoft.com/en-us/sharepoint/default.aspx.
SharePoint is a lot of work and with that amount of users I personally (and being a SharePoint developer) wouldn't bother.
I would go down the ASP.MVC route in all honesty and not because it's new and the latest buzz technology. I would use it because it's hands down faster. This site for example is written in ASP.NET MVC and it handles all these requests per day on I think 3 servers. 2 front end and 1 database. Correct my if I'm wrong with that.
The problem with asking whether Sharepoint is easy to customize is that there's a wide range of levels of customization people are experienced with. And for some reason, most people also seem to think that whatever level they customized Sharepoint to is the extent to which anyone else would also try to customize Sharepoint.
It's hard to talk about degrees of customization in concrete terms. What is "customization" to me is wrangling with the core DAL, fighting with bugs in the CAML to SQL query optimizers, overriding the SPListItem hydration pipeline, etc. To others, "customization" might mean building some web part widgets and deploying them in a WSP. If you find that there is some impedance mismatch between your logical model and Sharepoint's working model, you will have a really hard time reconciling the two.
Welcome to the dark land of politics.
It's worth making sure that your team properly evaluate and understand any compromises that SharePoint will have you make. Asking here is a good start. Things I'd look at include:
What's the whole solution going to include? Often the administration of a site can involve as much or more development work as the front end. While the 3M+ user front end is the glamorous part it may not be the bulk of the work.
Are there reference sites for 20K+ simultaneous user SharePoint sites? Honestly? What kind of hardware did that require? Is that available?
Get a small group of experienced contractors in for a few weeks to properly estimate the work, both on ASP.NET MVC and SharePoint. Make sure they've worked on large sites. (There's plenty of contractors around at the moment!)
Also, anticipate failure. Have a fall-back option:
If the MVC technologists win out, expect heat from senior management, and possibly even a skunk-works we'll-do-it-properly-anyway project that duplicates your efforts.
If you do end up with SharePoint, listen very carefully to users throughout the development process and be prepared to create Web parts, MVC pages or whathaveyou to address problem points.
I've been in a similar situation where it turned out that there was heavy vendor influence at a very senior level. The senior team had bought into SharePoint and required it to be used for all internal systems; the OCTO (Office of the Chief Technologist) had mandated open-source technologies. It was fun to watch the fur fly in the middle.
(Our option in the end was to use a service-based architecture based on REST, which effectively booted the current version of SharePoint out of the system altogether.)
I would build this on SharePoint. It is quite suitable for big sites and many sites have already been built on it: topsharepoint.com
SharePoint (like all complex applications) does require sufficient knowledge that you do not seem to have at the moment which is a big risk in my mind. Don't listen to the nay-sayers though.. lack of knowledge is a common problem for devs dealing with SharePoint but it doesn't mean you can't make it do whatever you want.
Regardless, what other options do you have? I think the days of building completely custom CMS's have passed just as building completely custom Intranets are not cost effective anymore. There are many competitors to what they want to do with SharePoint (Umbraco, Sitecore, Sitefinity, etc) and most of them seem better than 100% custom.
So the answer might be neither ASP.NET or Sharepoint..
Although I develop all of my company’s web-sites in .net, all of my personal sites are still in "Classic ASP". I'm always being pressured to move away from it... but it works! Why change?
There are some reasons to change but in the end, if your sites are up and running and you don't really need the new stuff, stick with it.
One good reason to change is existing support from MS and the developers community. I guess is harder to get a answer for a problem with ASP since most people moved to .net long ago.
The only real reason would be because the technology is getting to the point where you're going to find yourself without a platform to run your code on.
...who knows how much longer Microsoft is going to keep Classic ASP support in IIS.
In general, I'd never upgrade working code just for the heck of it because it's in an older, deprecated language. Especially for something like a personal page.
I can think of one exception, though: are you currently in the job market? You probably don't want to give clients/employers the impression that you're stuck in Classic ASP land.
I have a lot of Classic ASP production code, though, and I feel you on the Classic ASP "backlash." It's actually kind of embarassing to have that .asp extension in your URLs. I've actually considered changing the extension on all the .asp files to something new and changing IIS' settings so that new extension is handled by the ASP component.
I was in a similar situation - working on .NET at the office, and 5 or 6 sites at home on ASP that worked fine. For me the compelling reason to switch was when the .NET MVC community preview was released. I had been working with other MVC frameworks for years and was glad to be able to use a well-built native MS one.
I have switched about 4 ASP sites over to MVC as a way to learn the new framework and I am really glad I did. I'll always have a soft spot for ASP (and can still remember enough to answer most questions), but .NET MVC feels so much more advanced.
If you feel your skills with what you do at your job is fine (don't need more practice) and you are happy with your personal sites the way they are then leave it.
The only thought to consider is if you were to want to use the personal sites as a way to promote yourself it could be viewed as old tech and thus your skills may be looked down upon.
It is outdate? absolutely, but is it Irrelevant? well it is based on scope of your application, if it is just a simple database driven (eg: CMS, e-commerce) i personally think that classic asp still relevant for that, in fact that I still use it for some CMS/e-commerce projects since I already have application legacy written with it and has satisfied my clients for years.
but if you going to build large business application with multi programmers involved then you may need to think about .NET
For me personally, ASP.NET has been more reliable. I mean, some bad ASP.NET code can't as easily take down IIS as some bad ASP code. Again, that's just from my own experiences. I don't know how much merit there is to it.
But I don't see the harm in running your personal sites in classic ASP really as long as it's working for you.
Classic ASP certainly isn't as common now as it was before the introduction of the .NET family, but I don't think you're hurting yourself much by maintaining personal sites in it. If you were self-employed and looking for work as a .NET developer, it might be odd to have personal sites only in Classic ASP; in that situation, you could convert one or more to .NET, and that might help you demonstrate your skills in both sets of languages.
I am a .Net developer that has been tasked with upgrading a classic asp website to asp.net. The website is currently running on luck and bubble gum but there is not enough time or money to stop progress and do a full rewrite. Of course I will still need to be able to deliver new features while I am upgrading.
What strategies should I use to make a smooth gradual change to asp.net? Should I convert to a single tier .net solution and then refactor to a proper multi-tier solution or should I design my business and data layers now? Should I go straight to 3.5 or is it easier to just get to 1.1 and upgrade to 2.0 or 3.5 after?
A full conversion would probably take 3-5 months. There is also some existing 1.1 code, which is why I am considering using that as a jumping off point.
Don't throw away your code!
It's the single worst mistake you can make (on a large codebase). See Things You Should Never Do, Part 1.
You've invested a lot of effort into that old code and worked out many bugs. Throwing it away is a classic developer mistake (and one I've done many times). It makes you feel "better", like a spring cleaning. But you don't need to buy a new apartment and all new furniture to outfit your house. You can work on one room at a time... and maybe some things just need a new paintjob. Hence, this is where refactoring comes in.
For new functionality in your app, write it in C# and call it from your classic ASP. You'll be forced to be modular when you rewrite this new code. When you have time, refactor parts of your old code into C# as well, and work out the bugs as you go. Eventually, you'll have replaced your app with all new code.
You could also write your own compiler. We wrote one for our classic ASP app a long time ago to allow us to output PHP. It's called Wasabi and I think it's the reason Jeff Atwood thought Joel Spolsky went off his rocker. Actually, maybe we should just ship it, and then you could use that.
It allowed us to switch our entire codebase to .NET for the next release while only rewriting a very small portion of our source. It also caused a bunch of people to call us crazy, but writing a compiler is not that complicated, and it gave us a lot of flexibility.
Also, if this is an internal only app, just leave it. Don't rewrite it - you are the only customer and if the requirement is you need to run it as classic asp, you can meet that requirement.
Having been a longtime classic asp programmer, and now an ASP.NET dev, I would take the time and architect it properly in the 2.0 framework (3.5 if you want/need the features).
My last job we had a large handful of very badly build classic asp apps that we were rebuilding, and the "nuke and pave" approach was the most successful. Use the existing classic app as your functional spec and wireframes, and build your tasks and tech specs off of that.
How long would a complete conversion/rewrite take? It's also going to depend on how you've structured your original project.
I can answer that you should just target v2.0 (3.5 if you want/need it's features) from the beginning. There's no need to subject yourself to 1.1 of the framework.
Try these links
Migrating from ASP
Key Considerations
Converting ASP to ASP.NET
ASP to ASP.NET Migration Guide
You may want to look at the new ASP.NET MVC framework. The level of flexibility is amazing and the coding style is slightly more akin to the ASP classic approach, albeit with much better separation of church and state.
Take a look at Snitz Forums (www.snitz.com) - they are currently in ASP but the port to ASP.NET is almost complete. Both code bases are available for you to look at so you may get an idea of how it has been done there to help you.
I would avoid going into .NET 1.1 since Microsoft is ending support for v 1.1 of the .NET Framework on 10/14/2008. The extended support runs through 10/8/2013 but is typically expensive to purchase. Any bugs or security holes will not be addressed and are your problem.
http://support.microsoft.com/lifecycle/?LN=en-us&x=11&y=10&p1=1249
Paul
easiest way to do it is to just jump in head first. get some asp.net books and dive into visual studio. Do the examples, play with it, build something fun for yourself. You'll learn by doing.
I'm also working on a gradual migration from classic ASP to ASP.NET. Our first phase is migrating some common logic from an ASP include to a .NET assembly that is exposed to COM Interop so they can be called by both classic ASP and ASP.NET. I've written some tests using ASPUnit to verify the behavior after migration to the .NET assembly (with the added benefit of safer refactoring). Once the core logic is in .NET, we can begin creating new pages in ASP.NET and migrating individual ASP pages to ASP.NET at our own pace.
I would recommend .NET 2.0 or 3.5 over 1.1. ASP.NET MVC looks like an attractive upgrade path.