Anyone who has not been locked in a cupboard for the past couple of years will be aware that two of Microsoft's core products will reach the end of their supported lives in the next few months.
The most imminent demise is that of Windows Server 2003, whose support comes to an abrupt but entirely expected end in July 2015. Not far behind is SQL Server 2005, whose support ends in April 2016.
If you are still using either of these products and are not well into some kind of upgrade project, chances are that this is not your only problem.
If you have not kept an eye on something as simple as when your database goes end-of-life, it is pretty likely to be behind on its service packs and patches too. After all, if you are running critical production systems on it you won’t have it set to auto-update and reboot itself at will; similarly the operating system.
So as well as having old software, it is probably more out of date and hence buggy than it could be if you had patched it properly. And if you have not yet moved to Windows Server 2008 or 2012, then one of two things is likely to be true.
You might have some highly specialist software which can't run on any server platform later than WS2003, which you have looked after by diligently patching and service packing your servers over the years. Or you don't have any such software and you have just not kept up. I know what I think.
Aside from software patching, the other potential issue is longevity. SQL Server 2005 has been around for more than nine years, so unless you have been super diligent it has probably seen a lot of database creep.
Your SQL Server box has gone from hosting the database you bought it for to inheriting a bazillion other databases for other apps that have appeared over the years.
And I can't blame you for that. SQL Server 2005 is a blindingly nice piece of software and more stable than my house, but it is not cheap – particularly if you needed the features of the Enterprise Edition – so why wouldn't you load up your database server with database instances instead of installing new boxes and paying for loads of new licences?
Along with database creep, one also tends to find that security has gone to pot, with server-level privileges instead of instance-level privileges, for example, or a user ID given a high privilege level instead of defining fine-grained permissions on a per-database basis.
Long arm of the law
There is a big problem shared by old versions of both your operating system and your applications: compliance.
If you are not a large company and you don't have to subject yourself to technical audits, compliance just means your basic responsibilities under data protection legislation (mainly the need to have sensible levels of security for any personal data you hold).
Most companies, however, have bigger compliance requirements to meet, and it is generally impossible to do so if your software is no longer supported by the vendor.
It is bad enough if you are subject to audit in your own right but worse if you are a service provider and customers decide to carry out due diligence audits on you before taking up or re-engaging your services.
Before we get down to solutions, let's look at the last main issue for companies still running Windows Server 2003 or SQL Server 2005.
Windows Server 2008 was released in February 2008. Many of us don't run with the first edition of any new product, but you would have run out of excuses for sticking with Windows Server 2003 by May 2009 when Service Pack 2 came out for Windows Server 2008. That means your average Windows Server 2003 installation is nearing its sixth birthday.
Similarly SQL Server 2005. Even if you avoided being bleeding-edge by waiting for the first service pack to SQL Server 2008, this was launched in April 2006. Chances are then that many SQL Server 2005 servers are nearly nine years old.
“Get to the point,” I hear you shout. OK, a fiver says that many of you have it running on the same hardware it was on when you installed it. Even if you have replaced the network, server and storage hardware at some point, you probably haven’t done it several times.
The law of averages says that as the software and operating system are approaching end of life, there is a good chance that so the underlying hardware is too or is already past its official limit.
To sum up, we have two ageing software packages that we need to upgrade, and they are most likely running on hardware that is old and by today's standards slow.
Also worth noting is that if your setup is more than about five years old it is probably not on a virtualised environment.
Microsoft Hyper-V was not around until 2008, and VMware ESX came of age at roughly the same time. So you probably have nasty, slow spinning disks on board in the server with a prehistoric RAID adaptor.
I reckon, then, that you may well be able to treat the need to upgrade your Windows Server 2003 and SQL Server 2005 estate as an opportunity to deliver a vastly improved server and database infrastructure to your users.
You do, of course, have the option of doing an in-place upgrade. Would you want to? Unlikely, unless you are the bravest IT person in the world. Upgrade the operating system and the database in-place? No, particularly not on old hardware.
The business case for a full implementation can be surprisingly convincing
A far less risky approach is to install afresh, preferably on fresh kit. You are probably thinking that having been stung for the cost of operating system and SQL Server licences, the bean counters won't stand for a pile of new server kit too.
The point is, though, that the business case for a full implementation can be surprisingly convincing when you consider these alternatives:
- Do nothing (not an option if you are doing the upgrade for governance and compliance reasons).
- Run up a later version of SQL Server on an existing server running a later Windows version, but do you have enough spare capacity and is the server up to it?
- Run up a later version of Windows and SQL Server on a fresh server, and again, do you have the capacity?
If you have just one or two Windows Server 2003-based machines then it may well be justifiable to stick with the traditional model of physical hardware per server.