Dan Jones just blogged about the proposed upgrade paths and supported platforms for Denali. I’m glad they are publishing this information long before a new CTP is released. In that blog post, Dan encourages you to reach out to them via Connect (linked in his blog post) and I would say the same: if you have any issues or concerns, or agree with what I’m going to post here, let ’em know! Speak now or forever hold your peace.

Here’s my take on what Microsoft is proposing. You may disagree and I would love to hear your comments.

Windows Server 2003 Is Dead
If you haven’t gotten the hint, Microsoft has released two OSes (Windows Server 2008 and Windows Server 2008 R2) since Windows Server 2003/R2. Yet, I still know many customers (talk to them often) that still only support Windows Server 2003. I’ll just say this: if you haven’t started looking at, evaluating, certifying, deploying, etc. Windows Server 2008 (and at this point, it should be Windows Server 2008 R2) in your IT organization, start now. That should be a huge priority.

Supporting Windows Server 2008 with Service Pack 2 Is A Mistake
I’m focusing mainly on the server side. I know Windows Server 2008 (no R2) is Vista server. I’m in full agreement that Vista the desktop OS should be supported. Supporting Windows Server 2008 with Service Pack 2 is a huge problem for me. Why? Let me state my case.

  1. Windows Server 2008 mainstream support ends in 2013.
    Check the Microsoft lifecycle site for your country if you don’t believe me – it’s slated to end mainstream support in July, of 2013. We do not know any RTM dates, but it’s fair to assume most of you at the earliest won’t even think about Denali until sometime in 2012, if not later. Do you want to deploy on an OS that is already out of mainstream support and you can’t get hotfixes for? Yeah, I didn’t think so. This also plays into the whitepaper I wrote about supportability and staying ahead of the curve.
  2. From an AlwaysOn standpoint, Windows Server 2008 R2 SP1 brings much more to the table.
    Windows failover clustering, which both the SQL Server failover clustering feature as well as the new availability groups feature rely upon, has been further enhanced in Windows Server 2008 R2. The biggest improvement is PowerShell integration.
  3. Windows vNext is around the corner.
    Again, we don’t know release dates but Microsoft recently unveiled the first looks at Windows 8 the client OS, which means its server counterpart is also in the works. If Denali ships with Windows Server 2008 SP2 support, that means their support needs to worry about Denali on three different OS platforms with their own quirks. That’s not a scenario I would want if I was Microsoft.
  4. [EDIT – Added] Server Core and failover clustering.
    I’m not giving away any trade secrets, but you may have heard that Denali will be supported on the Server Core variation of Windows (i.e. no GUI). Server Core is part of both Windows Server 2008 and Windows Server 2008 R2. However, if you want to do something like failover clustering, cluster validation (the Windows process) only has a PowerShell cmdlet (not a cluster.exe implementation), and that would require Windows Server 2008 R2.
  5. 32-bit is dead. Long live 64-bit.
    Windows Server 2008 (no R2) does have a 32-bit flavor. That means Denali would have to ship a 32-bit server (which may be the main reason behind the decision to support that OS). However, let’s face it: 32-bit is a dying breed in most environments. Truth be told, I haven’t implemented anything but an x64-based SQL Server (even under virtual machines) in my test environments as well as at all of my customers for at least 3 or 4 years going back to Windows Server 2003. I would argue most of you who need 32-bit need legacy support in some way, and that is done via some old platform. Your new apps are probably moving on, even if you are using Windows Server 2003 64-bit and not Windows Server 2008/R2.Windows has killed 32-bit. I believe Exchange has. Why not SQL? I don’t understand the wishy-washy reluctance to not embrace 64-bit fully and kick 32-bit to the curb. It’s time to move on. 32-bit has been a great platform, but let’s retire it with dignity.This does not mean that Microsoft shouldn’t support 32-bit on the desktop … I’m purely talking about deploying it in a production capacity.There’s another big reason I would recommend this: make the testing matrix smaller. Removing 32-bit as a server platform allows MS to have better testing coverage for everything else. The more platforms, the more testing, the bigger the matricies. Having done QA in the past, I know this is huge.

What About SQL Server 2000 Upgrades?
It’s clear by the list you won’t be able to go directly from SQL Server 2000 to Denali. Hopefully by now most of you know that SQL Server 2000 is not supported on any version or variation of Windows Server 2008. While Windows Server 2003 supports SQL Server 2000, 2005, and 2008, it’s gone. Kaput. Forget about it. In that context, it makes sense that upgrading in-place would not be possible to Denali. This is much like the SQL Server 7.0 upgrade scenario where in some cases with later versions of SQL Server you need to do a “double hop” (i.e. get it to 2000, and then upgrade to a later version). In this case, you’d have to do an intermediate step to 2005 or 2008. If you’re going to have to go from 2000 to Denali, start thinking about that and come up with a short term plan so you can minimize your downtime in the Denali upgrade.

I know that the decision here will not make some of you happy, but it does make sense at this point to cut the 2000 lifeline directly. I know customers out there are still using it. You have options, but you need to just figure out what you want and need to do.

What Version of SQL Server 2005, 2008, or 2008 R2 Are You On?
So the published list of minimum upgradeable SQL Server versions (meaning you can be at that version or greater) is 2005 SP4, 2008 SP2, or 2008 R2 SP1. If you’re not at any of those, as with what I said about 2000, start planning to get there now. It’ll save you a lot of grief and aggrivation in the long term.