Choices: Migrating from Classic ASP to .NET or Migrate to Open-Source Platform

Question

My organization has a lot of legacy ASP software on its hands.

Since our perception is that Microsoft has shown a distinct lack of support for its older products, we need to figure out what to migrate to next.

If we migrate to ASP.NET from Classic ASP, It feels like that'd be a 'complete rewrite' "migration". Since that is probably the case, we're thinking about turning to a free (as in beer and as in speech) platform. I particularly think our investment (in programming effort, I mean) would be better spent with a platform that will let us evolve, rather than forcing us to dump very single line of code every 4 / 5 years. This is the main argument we've been using to advocate moving towards a 'free' platform.

Currently we're thinking about using a mixture of Java with a dynamic language like JRuby or Groovy.

My questions are: What would be a good migration choice? Are our fears unfounded? Would we (conceivably) need to rewrite a large portion of the codebase after 4 or 5 years anyway? What arguments do you have for moving to either .NET or to a free platform?

Answer 1

You know mono exists right?

I think you'll find that the longevity of a language is not as important as you think it is, since the lifetime of the major versions of an app is really quite likely to be less than that of most languages. And to be fair to .NET 2.0 -> 3.0 is a pretty small shift up, not a "dumping every single line of code" exercise. If you even wanted to shift up, which isn't really required yet.

I think a strong case could be made for any given platform you might consider, I'd look at other factors like your programmers comfort/skills/familiarity, community support, extensions, and fitness for purpose.

Answer 2

I don't think you can escape the pain of migrating every 4-5 years given that the industry is in a continuous flux and tools, platforms and languages evolve to maximize efficiency. There's no guarantee that Groovy/Ruby/C# won't change to adopt the next big thing.

Personally I wouldn't lose sleep trying to 100% future proof myself. If that is the goal then you might as well use assembly and even then there's no guarantee that'll stay constant either.

Just consider the following 1) What do your guys know? If they are vb guys it makes sense to move to VB.NET 2) What budget do you have for tools? 3) Does the platform you want to move to have the stuff that you need? I remember some time back discovering with amazement Powerbuilder's support (or lack thereof) for regular expressions 4) Is there a community around the platform?

Answer 3

We recently migrated a substantial ASP project to ASP.NET and it's definitely possible to do a migration that doesn't become a complete rewrite, preserving a susbstantial proportion of the original code (although we benefited from some fairly well architected code with good separation between the business logic and the presentation layers from the outset).

We looked at two possible routes to the migration:

1. A ground-up rewrite as a 'proper' ASP.NET application making the most of the built-in controls and shifting all of the business and data access layers into classes etc - ie the way we approach a new ASP.NET project.

2. A more basic syntactic migration, taking the ASP pages and changing them over to ASP.NET without making too many up-front changes to the structure or logic. Then building on that as we continue to develop the site by making better use of ASP.NET controls, separate classes etc for new and revised functionality.

Due to schedule pressures, we adopted the second route, allowing us to make the switch sooner rather than later and then take a longer-term view on more fundamental changes as part of future developments.

On that basis, for the initial migration we were able to re-use the majority of the existing code, although this is gradually being replaced as we go forward. With an 'average' page having, say, 50-200 lines of HTML and 50-500 lines of VBScript code (as separate functions, not mixed into the HTML spaghetti-style), we found it took about an hour per page to migrate them, including changing all of the ADO data access to a new ADO.NET data access layer. Some simple pages took just a few minutes - some of the more complex pages took a whole day - but about an hour a page was the overall figure across hundreds of pages, with the time to change the data access representing a significant part of the effort.

If we were to redo the migration today, we'd use ASP.NET MVC rather than web forms as it maps better to the way that the original pages were written - although I couldn't comment on whether or not a migration to MVC would take more or less time.

This doesn't necessarily have any bearing on whether or not you want to move to a free platform or change languages - you might have other reasons for wanting to do this. (Our client was Windows based so moving to ASP.NET, development time aside, carried no additional costs.) However, I can say that it's possible to migrate a substantial ASP site to ASP.NET without a complete rewrite - and it's equally possible to migrate from earlier versions of ASP.NET to more recent versions with minimal work. Obviously the route that we chose, preserving some of the ASP feel to the code rather than opting for a complete redevelopment, might not suit everyone - but it does give you a low impact entry point into ASP.NET that then allows you to build on that groundwork while making the most of your existing codebase and skills.

Answer 4

The choice lies in your company's ability to support whatever you choose.

Are you going to support the code yourselves? If so, what is your skill set base right now?

If you are currently enjoying ASP, ASP.NET (code rewrite or no) seems like the first idea to try, even if you don't realise it, by having used ASP thus far, you have probably acquired a great deal of knowledge in maintaining IIS, as well as the plethora of Microsoft based Services and Servers that you can reuse or at least easily adapt to, in ASP.NET development, deployment and support.

JAVA, RUBY, Whatever you choose, the beauty/usefulness/power/usability/durability of any technology lies on the people behind its maintenance.

The questions you should be making are:

1. best directed at your team
2. who will be developing, planning managing the resulting app/service?
3. Are you Ruby people? If not, do you want to be?
4. Are you JAVA people? same as above
5. are you....?

..and so on..

Don't distract yourselves with costs here and there or free versus non free.

when the technology is unknown/new to the people behind a project, man hours in support can be much more expensive than most packaged software solutions out there, which will then provide you with support.

This is also true for development environments where you have to pay more for the IDE/Server/etc, but on the bottom line you have less of a learning curve to go through and support at your level of expertise.

Besides: just like @annakata said, you have plenty of opportunities/projects to implement "free as in beer" ASP.NET functionality.. mono or not..

Example: you can set up ASP.NET service with Apache if you like that sort of thing..

Choose what technology you want to adopt by what you know and what you want to know, not what you think is the latest and greatest in buzz, specially if the whole reason why you even started thinking about rebuilding your code set is due to the lack of support for ASP from Microsoft.