For .NET it may depend on the deployment target. .NET 3.5 is supported in even early editions of Windows XP, whereas 4.5 is only supported on Vista and above.

At my workplace we opted to stay on 4.0 because we still have workstations running on Windows XP Pro SP3 (which 4.0 supports). We cannot consider migrating until next year or so just because of that.

Another reason may be a dependency on external code libraries that have been compiled using an older version of the framework and for which no recent version exists.

“Good enough is the enemy of better.” — Jerry Pournelle

Seriously, there has to be a reason for an upgrade besides just “ooh, shiny!“. Among other issues, any time you switch versions of a package your code depends on, you switch out one set of bugs that you’re adapted for to another set that you may not be. In the process of switching, you frequently have to make code changes because of API differences or undocumented changes in behavior. And the list goes on.

There’s another question to be asked: “Why do projects opt to upgrade to a newer framework version?” Ideally, the answers will say something about the value to the project or its constituency of the upgrade. For example, with a commercial framework, the inability to get professional support for the older version. More often than not, the answer is “To take advantage of a capability not present in the older version.“.

Recommend an upgrade to a million dollar software project from v3.5 to v4.0 (Not always the same as going from .50 to 1.0), you better have a very good reason. Sorry, but just stating it’s 5-10 years old isn’t good enough IMHO.

Be prepared to identity the new features and how they will benefit this project. You could argue that if you don’t, making an even bigger jump of 3.5 -> 6.0 will be exponentially more expensive because the creator of your programming code won’t provide any sort of automated way of doing it as an example.

When you’re paying the bills, it’s easier to take comfort in “If it isn’t broke, don’t fix it.”

Providing support for an older OS is one reason (see Crono’s answer). The other reason is to “save money”. Quoted because it only saves money on the short run.

It depends on the type of project of course, but for business applications, which usually survive a significant number of years, there’s a good chance an upgrade will be required at some point, for whatever reason: support for newer platforms, new features, better performance…So either you postpone the upgrade until you have no other choice, or you continually upgrade as part of the normal development routine.

Small, quick, cheap steps, or big, slow, expensive steps. It’s exactly the same problem as with refactoring. Actually I guess you could even say a framework/library upgrade is a kind of refactoring.

Side note: There’s a discussion in the comments of JeffO’s answer about the car analogy. Since my rep is too low to comment, I’m leaving this note here. Software does not get old as a car does if it’s left untouched, yes, but it does get old if it’s worked on. Code is added. It gets bloated. Just as a car, if you don’t continually replace parts of it, something breaks. In the case of a car, you can still replace the part that’s broken, if it’s available. With old software, finding and fixing the issue gets so expensive with time you eventually have to give up.

Targeting a newer version of .NET when your application doesn’t rely on anything from the latest version of .NET is unnecessary, unless the target framework itself is reaching end of life. You’re introducing additional work to upgrade and test your application with no real benefit.

With that being said, we’ve had some software in our group that we’ve upgraded in the past from .NET 2.0 or .NET 3.5 to .NET 4.0. In most cases it was because we wanted to take advantage of the Task Parallel Library to improve performance.

We can’t upgrade anything to .NET 4.5 yet in our organization because it hasn’t been rolled out to any of our environments