.NET Framework - When to Upgrade?

Question

I’m faced with a challenge of leading two (currently) separate .NET development groups with different development strategies. One group is developing on the .NET Framework 2.0 (with maybe a few applications on 3.5). The other group immediately adopts any new framework that comes out, and begins coding any new applications with it (they are running 2.0-4.0 applications). For this last group, applications written in an earlier version than the latest framework do not get upgraded.

What is the current school of thought when it comes to a company developing web applications on when to adopt a new framework, and whether to migrate applications built on previous versions to the latest framework or not? Years ago the thought was to wait until the technology became mainstream - but that doesn't seem to apply much now with .NET.

Answer 1

(The following is my personal opinion, based on aprox. 1 1/2 years of experience with .NET in the same corporate environment. Other opinions may certainly differ from mine.)

Probably the most important thing to consider would be which .NET framework versions their clients have installed on their machines.

For example, our main client at work has installed .NET 3.5 and Silverlight 3 on all (> 5,000) machines. While we would very much like to develop against the version 4 frameworks, that's not truly an option until the client's IT staff finally decides that it should deploy these frameworks. (We expect that to finally happen around mid-2011. But the client has many machines, so things always take longer than you'd like. They're also still running Windows Vista on all desktop machines. In other words: large clients are probably slower to adopt the newer .NET framework versions. That's another thing to keep in mind.)

However, I think it's safe to expect that your customers should have .NET 3.5 installed by now. .NET 2 slowly is a thing of the past, and you can probably even stop supporting .NET 1.1 on desktop machines.

Answer 2

The way I run my development teams is to do what's best for the individual project while keeping in mind the needs of the team AND the customers that we are supporting.

Typically, upgrading provides new features and makes it easier/quicker to write code to achieve what a customer may want. However, there is an obvious cost with upgrading - sometimes new training is needed and, sometimes there are problems with backwards compatibility (especially for any non-trivial application). Of course, all of this costs money.

For the most part, I try to keep my teams on the cutting edge since we have learned (through experience) that maintaining various versions of frameworks can create a lot of confusion and, ultimately, requires the same, or more, costs as just doing a one-time upgrade. With this said, there are a couple customers that we have that specifically do not want us to upgrade. Those are special cases, of course, but we manage those as needed.

Basically, to sum up the answer - decide what is most important to you. New features? Cost savings (which you need to think about multiple costs - development and customer costs)? Maintainability? Support? Once you have those things decided, and you have received input from your development teams, the answer should be fairly clear.

Answer 3

We have a two-person shop. If it were up to me, we would upgrade as soon as a new version of .NET and Visual Studio is released. My partner is more cautious, and prefers to wait at least 6 months to see if there are any known issues that come up.

Either way, i think it's best to update reasonably quickly, and my partner's approach, while frustrating to me, makes sense, so I follow her lead. The biggest concern I have is the number of versions of Visual Studio we need to keep around to support older apps. We still have VB6 (and one FoxPro for DOS) app because our predecessors never wanted to upgrade. We live in fear that a modification will need to be made to one of those apps. it usually ends up in a re-write because the old code is just that bad (or maybe we are bad at reading old code).

I think it's very smart to upgrade programs and codebase reasonably quickly as a new set of tools comes out. Usually the migration tools work better with relatively new to new conversions, as opposed to very old to new conversions. It just makes life easier.