Last Update: Nov 19, 2024 | Published: Jan 05, 2016
As Brad Sams reported back in October, Microsoft is terminating extended support for SQL Server 2005 on April 12th. This means that, unless you pay hundreds of thousands or millions of dollars for a custom support contract, Microsoft will terminate all support for SQL 2005. No more technical support, no more hotfixes, and no more security fixes.
As Microsoft has done before for products, such as Windows XP, Microsoft has published a website specifically to deal with the challenges of upgrading or migrating customers from SQL Server 2005.
On this site, you can learn why you need to upgrade from SQL Server 2005, tools that will help you upgrade or migrate, and several different guides to help you through the process. There are also useful links to Microsoft services, videos, whitepapers, tools, and documentation, so this site should be your upgrade starting point.
The label “accidental DBA” was coined in response to the organic way that SQL Server pops up on servers. Many line-of-business (LOB) apps include some version of SQL, from the free Express Edition all the way up to the Enterprise Edition. These ‘shadow databases’ often go unnoticed for years and can be tricky to deal with when trying to find those hidden-away database servers to ensure that they don’t become a security or technical support risk to the business.
If you already have a software auditing service, such as System Center Configuration Manager (SCCM), then finding SQL Server 2005 installations will be just a matter of running a report. If you don’t have that tooling, then Microsoft has a free tool for you. It always puzzles me, but few people know about or use the free Microsoft Assessment and Planning (MAP) Toolkit. If you follow Microsoft’s deployment best practices for Windows clients, Windows Server, SQL Server, and more, then all upgrade projects should start with MAP. This tool will reach out to your network to discover and audit machines. A database is populated and, you can run a series of reports to identify SQL installations, licensing types, and editions.
Once you have identified all SQL 2005 installations, you can start planning. But we don’t live in a simple world where all things are possible.
There are a number of things that will prevent upgrades from happening. What that in mind, you should still try to balance the real business risks of running outdated and unsupported software in production:
There are three options available if you decide to replace a SQL Server 2005 installation:
Of course, there are other options, such as completely replacing an application, but I’m focusing on upgrade and migration scenarios in this article.
Let’s start with the technical side of things. I’m a not a SQL expert. Instead, I’m the perfect example of an accidental DBA. With that said, there’s tooling to assist, such as the SQL Upgrade Advisor.
Your biggest issue with upgrading to a newer version of SQL Server is licensing. You will need Software Assurance (SA) for SQL Server and the SQL Server CALs if non-processor licensing was purchased. If you don’t have SA already, then you cannot add it; you’ll have to purchase all-new licensing.
You might decide that instead of doing an upgrade of a machine that probably is also running Windows Server 2003/R2, you will deploy a new machine with Windows Server 2012 R2 and SQL Server 2014. If so, check out the SQL Database Migration Wizard.
You can minimize that spending if you are careful with your SQL designs in mid-to-large environments. The first option is to start consolidating your SQL installations. You don’t necessarily need one SQL Server installation for every LOB app. Maybe you can consolidate to many SQL instances on one server/cluster?
If you have live migration of SQL Server, then every host must be licensed for SQL Server. Larger customers that are using virtualization might deploy a virtualization cluster that will have the sole role of hosting SQL machines. This reduces the number of hosts that must be licensed for SQL Server. Talk to your licensing supplier to learn more about how this solution can save you money.
The cost of an Azure virtual machine that runs Microsoft software includes:
For example, I could deploy a D3 virtual machine, which is four cores and 14 GB RAM, in North Europe with the cost of Windows Server and SQL Server Standard included and no CALs required for $682 per month.
Remember, that includes the machine, the software, and no need for any CALs. This is a monthly drip feed instead of a big bang up-front expense. As with the upgrade scenario, I can deploy a smaller number of machines to consolidate the expense of SQL Server.
Note that there would be additional costs for storage, site-to-site networking, Azure backup, and so on.
Microsoft has even done quite a bit of work to simplify the deployment of SQL in Azure virtual machines, which is great news for us non-experts in SQL Server.
This is a migration scenario, so once again, you should look at the SQL Database Migration Wizard, in conjunction with the advice from Microsoft for this scenario.
If you have SA for your on-premises licensing, then talk to your licensing reseller about options for moving your licensing to Azure to reduce the above costs.
I suspect that this option will be the least commonly adopted one for SQL Server 2005-based LOB applications, but it might be good for some. Azure SQL Database is an Azure service that provides you with capacity to run databases in the cloud, without the pain of deploying or upgrading SQL Server ever again. You get a hugely scalable platform that Microsoft supports, and it reduces your workload and business risks. It sounds perfect, right? But unfortunately, the SQL client must be compatible with SQL Serve. For example, I cannot use Azure SQL Database instead of SQL Server for System Center.
So, there you have it. Assuming that you aren’t switching to MySQL, Oracle, or something else, Microsoft gives you more options than ever for replacing obsolete versions of SQL Server. There’s plenty of documentation and tooling to help. My advice is that you start planning now because databases aren’t easy to upgrade or migrate, and changes to them include technology and business risks. Use the tools that are available — for example, try an Azure Replica test failover and do the test upgrades and documentations in the cloud with identical installations before impacting on-premises production systems.
Please share any ideas or advice that you have with us below.