50-60% of on-premises Microsoft workloads are running on 2008 versions, despite the fact that mainstream support ended in 2014.
Now Extended Support for Windows Server 2008 is expiring on July 9, 2019 and Windows SQL Server 2008 is expiring on January 14, 2020. So what are your options? Let’s go through them quickly.
Option 1: Do Nothing
If your team has no choice but to stay on-premises running Windows SQL 2008, expect to pay a lot more for support. End of support from Microsoft means:
- No new upgrades
- No new security updates
- You’re exposed to cyber attacks
- There’s a compliance risk (most compliance frameworks require regular patching schedules)
- You’ll pay extremely high rates for additional support if you stay on-premises (30% support fee vs. 70% support fee)
For these reasons, this is not a true option for most companies.
Option 2: Side-by-Side Migration On-Premises (to 2012 or later versions)
If you want to stay on-premises, you can upgrade SQL by building secondary machine(s) with the new version and migrating your database onto that new server. By preparing the target server separately, you have the option to rollback to your current version if things go wrong, plus most companies choose to upgrade OS and other packages at the same time. For a more complete overview of all upgrade options, see Microsoft’s documentation.
However, since this is a very manual process (the data itself can be migrated automatically, but server-level objects are always trickier) and may require additional physical hardware purchases to maintain two versions simultaneously. Therefore, it’s a good opportunity to evaluate cloud-based options. The same amount of effort could be applied to migrating databases to the cloud, often for lower upfront costs. Let’s dig into a few of those options now.
Option 3: Migrate to AWS EC2
Another option is that you can bring your Windows SQL server licenses to AWS EC2 dedicated infrastructure and upgrade to a supported version once migrated. AWS provides many tools to help you make this upgrade once on AWS.
The benefits of this option are that you get:
- Familiar administration experience
- Full control over the environment
- All SQL Server features available
- Lower TCO for SQL workloads
Of course, there are many reasons why you’d want to migrate to AWS that have nothing to do with SQL Server — more flexibility, scalability, resiliency, etc. But the SQL 2008 end of support may serve as the extra incentive to make the move now rather than later.
Don’t have an existing AWS environment? See AWS’ official reference architecture for running SQL on EC2.
Option 4: Migrate to Amazon RDS SQL Server
If you’re planning on migrating to AWS, putting your SQL Server on an EC2 instance is not your only option — you can use Amazon’s managed database service, AWS Relational Database Service (RDS) which has a SQL Server flavor.
When you run on Amazon RDS, you no longer have to manage backups, snapshots, or patching, and even more appealingly, it automatically upgrades your version, so you’ll never face a “end of support” deadline ever again. In EC2, you have to manage all of this by yourself.
RDS provides push-button scaling — so there’s no need to terminate an instance and rebuild it, you can just press a button and scale up. You can enjoy high availability through multi-AZ and don’t have to configure always-on availability groups.
Of course, there are some drawbacks. A second deployment of RDS SQL Server means a second license, and its associated costs. So bear that in mind as you’re calculating the cost of this solution. You’re also not exposed to the operating system, so any legacy deployments might be a little more difficult on RDS. If you’re using something like SSIS, it wouldn’t be possible to use RDS.
Thinking of migrating to Amazon RDS? View AWS’ official documentation for migrating to Amazon RDS.
Option 5: Refactor on Amazon Aurora
If you’re ready to go all-in on AWS, consider refactoring your database on Amazon Aurora. It would mean changing to a PostgreSQL or MySQL engine. But the benefits of Amazon Aurora are significant:
- Open source and flexible
- Licensing fees are way cheaper
- SQL Server backups that once took 5-6 hours daily now happen continuously on Aurora
- Less than an hour to restore from backup (SQL Server deployments take much longer)
- Six copies of your database across three different AZs automatically
- Easy to test disaster recovery
- Aurora is optimized for multiple, concurrent read requests to the database
- Multi-AZ Aurora read-replicas eliminate the need for additional licenses of SQL Server
- Aurora has been proven to cost about 70% less than on-prem SQL server deployments
At Logicworks, we’ve actually helped multiple companies move legacy databases to Aurora. One of our clients had a large SQL implementation that leveraged a lot of SSIS, which they decided would be hard to replicate on RDS. Ultimately, they felt that the upfront work required to migrate to Aurora MySQL was well worth the advantages of Aurora.
Learn more about migrating from SQL to Aurora MySQL in AWS’ official documentation.
Option 6: Migrate to Microsoft Azure
Microsoft is offering an additional three years of support if you migrate your SQL Server database to Microsoft Azure. That means it will expire in 2022 instead of this year. This is a great option for people who can’t upgrade everything before the end of support timeline. It also requires no application code change and (probably) zero downtime.
Azure has a great managed database solution without the need for multiple licenses. You can also have SSIS implementations, even with a managed instance deployment, through Azure Data Factory.
To learn more about your options for migrating to Azure and get a cost estimate, read Microsoft’s guide.
If you’re running SQL 2008, it’s smart to start planning now. Whether you migrate to AWS or Azure, the cloud offers lower costs — and more importantly, the potential for never having to worry about Microsoft’s support deadlines again.