You may have seen either my blog post about SQL 2016 found here or one of many of the other posts by SQL professionals, leaving you with the question:
Should you migrate to SQL 2014 or wait for 2016?
Microsoft gives access to several release candidates of SQL server before the general release to the public.
Software vendors rarely announce support for the latest version as soon as the general release is available.
Either they have not completed all their testing, or they might be waiting for any initial teething issues to be fixed by Microsoft first.
That leaves a gap between the general release and vendors announcing that they will support the latest version of their applications on the latest SQL platform.
This then leaves businesses that want to move to the newest version with a dilemma.
Do you move to SQL 2016 anyway and hope you do not have any support issues, or do you wait for it to be formally announced?
This is hard enough to decide for just one application, but what if your environment is shared and you have dozens of different applications using your SQL servers?
You now need to determine if you only move the applications with announced support and split your environment into two.
Those supported on SQL 2016 and those that are not or wait for all of your applications to announce they are supported.
Splitting the environment can double your licensing costs overnight, which can be very expensive.
Migrate to SQL 2014 or wait for SQL 2016?
SQL allows you to put a database into compatibility mode, making it feel like it is running on a previous SQL Server.
You can usually go back about two versions before the server version. This may or may not allow your application to work. You will need to test it on each database as it will be application specific.
Suppose you are currently on any version of SQL Server before 2014. Both the vendors and Microsoft support you. If your application vendors do not help SQL 2012 or SQL 2014, they will unlikely support SQL 2016.
In that case, it might be worth ignoring SQL 2016. By getting everything currently on a previous version of SQL server onto SQL 2014, you can ensure that all of your databases are on a supported platform.
This will also give you a good idea about your applications and if they will work on SQL 2016.
By consolidating any SQL versions in your business onto a supported SQL platform, you might be able to save on licensing costs which can be substantial, especially if your business is suffering from a rapid growth cycle creating server sprawl.
This will give you a good starting position to move to SQL 2016 later.
I wouldn’t say I like running applications on SQL, OS, or even hardware the vendor does not support. I want the security of knowing if I phone up about an issue, they will not tell me that it is an unsupported configuration – two words can strike fear into the heart of any administrator.
If you hear those words, they say you are alone.
You might want to jump to SQL 2016 because you need to use one of the new features, such as the support for R or the recent mobile reports.
You might want access to the faster query processing or the latest version of AlwaysOn.
If you need these features, then you will need to check that your application will run on SQL 2016 and do thorough testing.
Conclusion
So should I migrate to SQL 2014 or wait for 2016?
If you need one of the new or latest features, then you need those features and will need to go to SQL 2016.
If you do not need the new features and are worried about using an unsupported application on SQL 2016, they do not go to SQL 2016.
If you want to go to SQL 2016 but can wait for your application vendors to announce support, wait a bit longer. Once they promote and support you, you can test and move in your own time.
What do you think the answer is to the question ‘should I migrate to SQL 2014 or wait for 2016?’ for your business?