Slashdot Mirror
A .Net 2.0 Migration Strategy?
An anonymous reader asks: "I work for a large organization where we use .Net 1.1 as our sole development language. We have many frameworks, applications and web sites that are developed in .Net 1.1, and these developments are by no means trivial since they are the result of an IT department of over 300 people and 2 years of development. It is my responsibility to develop a strategy to move to .Net 2.0, this includes the existing applications, new developments, integration, QA, live and development environments. Does any one have any experience in this (preferably at this scale) and can any one recommend any reading material that would help?"
I recently migrated a 250k LOC web app with no code changes, and a few dozen smaller tools as well. Had to change two lines of code in one of those tools.
The hardest part will be dependencies. If you have anything that won't (or can't) migrate to 2.0 then things get tougher. One of our tools was external, and it loads in external DLLs. It can't load a 2.0 DLL, so our DLL couldn't upgrade to 2.0, but our DLL consumed a shared DLL... that got messy. We worked around it (for the moment) by switching it to use a private version of the 1.1 shared DLL until we can get a 2.0 version from the external tool vendor.
Half the comments so far are advising the guy to ditch .NET ASAP so that he doesn't have to upgrade again.
He doesn't HAVE to upgrade at all! He's voluntarily decided to upgrade to a new version of an existing product. How is this a negative thing? It could definitely be a bad idea, but I don't see anyone saying that.
It's bad enough that people don't even read linked articles, do people even read the text of the story before posting anymore?
using namespace slashdot;
troll::post();
We are in the process of making the change from .Net 1.1 to 2.0, mostly due to a decision to migrate to Visual Studio 2005 Team. Thus far, the only issues we've run into is backwards compatibility with WSE2.0. We had to migrate to Web Services Enhancements 3.0 due to issues with IIS. Aside from that, we haven't had many issues other than a few test tools (AppSight)not yet compatible with v2.0.
If you think
One thing I haven't seen discussed here is taking a strategy on which parts to move. This isn't "do it all at once" kind of situation. .Net 1.1 is still there, works, and having .Net 2.0 doesn't break that.
.Net 2.0 are in things that use ASP, ADO, and so on. So, if you have core frameworks that are based on the core libraries, they probably can be very quickly ported to the new language. The optimum case is a recompile, retest and it's done. So, you can pick the stuff you think will mostly easily move to .Net 2.0, and port that.
.Net 2.0 road. For a really hard-core approach, pick both most critical and hardest to do first.
.Net 2.0. For example, you really may want to use those spiffy Web Part APIs on your portal, but get your old stuff running first.
There's a couple of strategies here. Firstly, you can go for low-hanging fruit. Many of the changes in
The other approach is to take a risk-aggresive approach. Take the most critical pieces you have (say, like a framework or a library that a lot of apps and so on use) and port those. Concentrate on that effort, because until those ports are done, you most likely can't move forward anyway. Repeat this approach until are well on the
Given your large code base, I think it is best to get the old code working first, as tempting as it may be to use all the latest features of
But, the key here is to pick those libraries, applications, etc. and work in stages. I don't think a big-bang migration will work very well here.