We are officially one week away from the end of support for SQL Server 2008 and 2008 R2 on July 9th, 2019. In a perfect world, everyone would have known this was coming and taken action already, but this is the real world. Maybe a previous upgrade went poorly and now your company prefers to cross their collective fingers and hope for the best. After all, these products have been out for over a decade, so all the big flaws have been fixed, right? Perhaps you can’t get budget approval to upgrade your old (and paid for) socket-based licenses to core-based licences with Software Assurance. Or maybe your team is just too busy with the day-to-day to plan for and execute a major version upgrade.
Unfortunately, no matter how busy you are or how averse your company is to change, you really need to do something. With no more security updates coming from Microsoft, these legacy systems pose a significant risk. The good news is there are a few different solutions available. I’m going to list them below along with the pros and cons of each option.
Option 1 – Purchase extended security updates from Microsoft
You can literally buy yourself time with this option (up to 3 years from the end of support date) to upgrade or migrate your instances while ensuring that your existing workloads are protected.
- Pros
- No changes to your existing instances. You keep on running your applications just like you are today.
- No application code changes required.
- Provides ample time for planning, testing, and executing your upgrade/migration.
- Cons
- Requires active Software Assurance on the instances. If you bought your licenses years ago without SA, this option requires getting that agreement in place and paid for before you can add extended security updates.
- Costs approximately 75% of the on-premise license cost annually. That’s a significant expense for very minimal support.
- “Out of sight, out of mind” risk. This is a short-term band aid solution. After 3 years, there won’t be another option to buy more time. If you choose this option, you will need to get going on that migration plan right away.
Option 2 – Move to Azure to get free* extended security updates
Similar to the option above, this provides 3 years of security updates for SQL Server 2008 and 2008 R2 instances that are migrated to Azure Virtual Machines (IaaS). If your company already has a footprint in Azure or your application would be a good candidate for a “lift & shift” migration, this could be an appealing option.
- Pros
- No requirement for Software Assurance.
- Existing Microsoft licensing can provide discounted rates and/or license mobility (consult your Microsoft licensing specialist for details)
- Minimal changes to your existing instances.
- No application code changes required.
- Provides the same 3 years for planning, testing, and execution of your modernization plan.
- Part of the Azure ecosystem, allowing for more cloud-native service integrations.
- Provides an easy path to Azure SQL Database or Managed Instance.
- Cons
- Security updates are technically free, but the Azure VM is not.
- Complicated infrastructure if your company is not currently using Azure.
- Typically requires the application and database to move together.
- Post-migration performance tuning will likely be required.
Option 3 – Upgrade on-premise instances to a modern version of SQL Server
This is undoubtedly the best option, but also the most complicated.
- Pros
- Regular enhancements, bug fixes, and security updates are provided. In addition, they will continue to be released well into the future. However, that doesn’t mean that you should wait until the new version is nearing end of support to do your next upgrade. You don’t want to find yourself in this position again, do you?
- SQL Server has added numerous enhancements over the past decade. These include significant improvements that can make your application faster and more highly available.
- Cons
- Requires extensive application testing.
- Code may have to be refactored if it is using deprecated features that have been removed from the new version of SQL Server. This is not particularly common, but it does happen. Fortunately, there are excellent tools for analyzing applications and identifying if they are using deprecated syntax and features.
- Performance regression can occur when older queries are migrated to SQL Server 2014 or higher. However, there are workarounds for these regressions, but performance testing is crucial to identify them prior to the upgrade.
Hopefully this will help you to understand your options for what do with that old SQL Server 2008 application that’s about to be unsupported. As always, the biggest thing to remember is to thoroughly plan and test, regardless of the path you take.
Need help? Contact SqlCS and get the assistance of a database consultant with years of experience performing version upgrades and complex migrations.