January 7, 2015
I thought I’d put out some thoughts around why I think people who’d rather migrate to or start a project afresh with SQL Server [Previous] are potentially costing themselves a lot of pain, resource and thus cash in the longer term.
I’ve been working with SQL Server and Windows since the very early days – NT 3.5 and SQL 4.21a, back in those days there wasn’t as big adoption of the product as there is now, in fact Centre-File for whom I worked back in ’93, we were one of the first folk in the UK to use the product in anger. Back then companies were extremely cautious, they let other people take the risk with the new editions, the SQL product team were a fraction of the size and had a fraction of the resources they have now. Thus, a lot of folk, especially the banks tended to stay a full version behind the current version or service pack behind the current one.
Today, like rebooting your SQL Server every night, we’ve moved on, moved on significantly in fact. The product has a huge user base, the Community Technical Previews (CTP) goes out to a massive audience and with new methods of software development around Agile the quality is pretty much rock solid even in the later CTP’s. Given the size of the product there really isn’t that many bugs that come through – the contents of the cumulative updates highlight that.
One of the things that folk probably don’t think about is that the code base between versions is the same, albeit more recent versions have more features and code baked in, but bugs found in functionality/features are ported across all versions they affect, so there may be a bug found in say SQL Server 2014, if that bug is common to 2012 etc. then the fix will be applied there too. What you end up with is that each succeeding version is basically a build containing all the bug fixes of the previous version plus the new features.
I’ve knocked up the diagram below that shows version and service pack releases, the dates I’ve taken from http://sqlserverversions.blogspot.co.uk which I recommend you use for links to service packs and cumulative updates.
In the main a migration between versions is a big thing, the entire application needs to be regression tested to check for any peculiarities of performance or feature change. Moving to a new service pack isn’t that big a deal, you can concentrate on the areas the service pack has touched.
Consider the situation where you are on SQL Server 2008 or SQL Server 2008 R2, what version do you migrate to? Some folk would say SQL Server 2012 because they don’t want to be on the latest product (even though as I write this post it’s been out nearly a year!). What is the basis of that decision? We are business or IT folk – decisions need to be evidence based, they need to be explained, that said, I wonder if there are any other industries where a lot processes are done on a myth bases.
If you are going to allocate the resource, spend the money migrating from SQL Server 2008 R2 then you might as well do it directly to SQL Server 2014 because it’s the best time to do it, think about it from a business perspective, think about it being your money – what would you do? Would you spend the £70K migrating from SQL Server 2008 R2 to SQL Server 2012 only to spend another £90K in a couple of years time migrating from SQL Server 2012 to SQL Server 2014? No, if it was your money I very much doubt you would!
Common sense says that if you are going to go through all the testing of the applications to make sure they work on the new version they you would go for the very latest version, service pack and cumulative update – in the near term if has the benefit of saving money on service pack testing, you can also take advantage of the new feature set once your migration has been completed (as a separate phase).
So – to conclude, each version of SQL Server since 2005 has been built on the previous code base, spend the money once and migrate in one step to the latest version, think about it – you then have the money, time and resources to use the new features in the product to give your business a competitive advantage – an advantage I highly suspect your competitors are looking at.