Somewhere in the office, or on a virtual machine nobody has logged into for a while, there’s a database server holding the data your accounts, bookings or stock system depends on. If it runs SQL Server 2014, Microsoft’s lifecycle page puts the end of extended support in July, and the awkward thing about that date is that nothing visible happens when it arrives. The application keeps working and the backups keep running, while the risk builds quietly.
What happens on the day, and what doesn’t
Microsoft’s lifecycle page for SQL Server 2014 lists mainstream support as ending on 9 July 2019 and extended support as ending on 9 July 2024. The page labels its times as Pacific Time, and the first year of Extended Security Updates starts on 10 July, so the exact moment depends on which time zone you’re standing in. We’d treat the week as the deadline rather than the hour. Service Pack 3, the last service pack the page lists, has the same end date, so being fully patched on it doesn’t buy you extra time.
Microsoft’s end of support options page puts the difference plainly: extended support includes only security updates, and end of support means servicing and support are no longer available. After that, a security flaw discovered later has no official fix waiting for it unless you’ve arranged one. How much that matters depends on who can reach the server. One that only your application server talks to is a different proposition from one that’s exposed to the internet or shared with other systems, and it’s worth checking what your own policies and your customers’ contracts say about unsupported software, because they can settle the question before any technical argument does.
Ask the application supplier first
Before you compare routes, find out which version and service pack you’re running, which application depends on it, where the server lives and which version of Windows Server sits underneath. None of that needs a database specialist. The question that carries the most weight is which SQL Server versions your application supplier supports, and on which Windows versions. Get the answer in writing, because every route below depends on it.
It’s worth pressing, because SQL Server can keep a database behaving like an older version through its compatibility setting, and Microsoft states that when a database stays at the same compatibility level as the legacy system, existing applications are protected from functional and performance changes. An application, it says, needs full recertification only when it needs features tied to a newer setting. That’s a good argument to put to a supplier, but it’s their certification and support you’re relying on, so treat it as the start of a test plan, not as permission. Microsoft’s Data Migration Assistant can flag compatibility problems ahead of a move, and the Query Tuning Assistant can help if raising the compatibility setting makes some queries slower.
Upgrading to a supported version
An upgrade takes you into a supported lifecycle again, and it’s the route that gives you the most control over features and scalability, because you manage both the hardware and the software. Microsoft’s overview table, which it labels an approximation, has extended support for the 2016, 2017, 2019 and 2022 releases ending in 2026, 2027, 2030 and 2033. That argues for going as new as your supplier allows, because 2016 or 2017 would put you back in this conversation within a few years. If your supplier does support a newer version, an upgrade is what we’d aim for, and the other routes below are for when it doesn’t yet.
The costs are real, and Microsoft’s page is straightforward about them. It calls this the biggest up-front investment with the most ongoing management, mentions possible downtime depending on your strategy, and notes an inherent risk in an in-place upgrade. If the Windows Server underneath is itself unsupported you may need to upgrade that too, because newer SQL Server versions may not support it. Building a new server beside the old one can be the more prudent route, though it costs more. Whichever way you go, make sure you have a restore you’ve tried before anything changes, which is what our backup strategy guide is about.
Where Azure fits
Microsoft lists three Azure destinations, and they behave differently. SQL Managed Instance is a managed service that closely resembles an on-premises SQL Server instance without the hardware and patching worries. It’s versionless, so there’s no version to upgrade to or from in the same way. The trade-offs are some Transact-SQL differences and unsupported features, a price that can be higher than a single database, no guarantee over the exact maintenance time, and a connection to your network that needs either ExpressRoute or a VPN Gateway.
SQL Server on an Azure virtual machine is the nearest thing to moving the server as it is. You can keep SQL Server 2014 and get Extended Security Updates for up to three years at no additional charge above the cost of running the Azure service, as Microsoft’s ESU page puts it for workloads moved to Azure. That applies even without Software Assurance when you migrate as-is, though you can upgrade during the move instead. Either way you still look after SQL Server and the operating system yourself, and you have to fit the machine into your networking and Active Directory setup.
The third option, Azure SQL Database, moves one database at a time rather than a whole instance, and its feature set is less complete than Managed Instance or SQL Server. For a packaged line-of-business application we’d expect Managed Instance and an Azure virtual machine to be the realistic candidates, subject to what your supplier supports. And if the application stays in your office while its database goes to Azure, the link between them, the sign-in arrangements and the speed all need thinking through first.
Paying for Extended Security Updates
If you can’t move yet, Extended Security Updates (ESUs) are Microsoft’s way of buying time, for up to three years. The three ESU years run from 10 July 2024 and end in July 2025, July 2026 and July 2027. The ESUs themselves are, in Microsoft’s words, made available only if needed, once a flaw is rated Critical by the Microsoft Security Response Center, so there’s no regular schedule. They don’t include new features, functional improvements or customer-requested fixes. A non-security bug won’t be fixed either. ESUs also don’t include technical support: that comes from a separate contract such as Software Assurance or Premier or Unified Support, or an Azure Support plan if you host in Azure.
To qualify on your own premises or a hosted environment, you need Software Assurance under an Enterprise Agreement, Enterprise Agreement Subscription, Server and Cloud Enrollment or Enrollment for Education Solutions. The alternative is to connect the instance to Azure Arc, a Microsoft service that lets Azure manage servers outside Azure, and switch on a pay-as-you-go billing option. Connecting is free. From there there are two ways to pay, and Microsoft’s page sets them out like this.
| ESU plan | ESU subscription | |
|---|---|---|
| Where you buy it | Volume licensing | Microsoft Azure |
| Arc connection needed | No, connected or not | Yes |
| How it’s charged | Each year bought separately, paid in full and priced differently | Billed hourly, continuous until you cancel |
| Ending it | Not set out on the page beyond the yearly purchase | Cancel at any time; ends automatically when you move to Azure or upgrade |
| Patches | Manual installation | Automatic or manual installation |
On timing, you can sign up for the 2014 subscription before or after 10 July. Sign up first and the hourly charges start at midnight on 10 July. Sign up later and the next bill includes a charge back to 10 July. Charges are worked out per machine on its cores, with a minimum of four cores in the cases Microsoft sets out, and different rules for failover rights and unlimited virtualization.
On price, Microsoft’s ESU page gives no figure for SQL Server 2014 and points to a separate pricing page. Microsoft’s general overview says ESUs are approximately 75% of the on-premises licence cost annually, but that’s a general statement and not a 2014 price, so ask for a current quote. We’d treat ESUs as a bridge with a known end, not a place to live.
Buying time without standing still
Whichever route you choose, the server may spend months in between, and some sensible precautions don’t depend on Microsoft at all. They’re our recommendations rather than Microsoft’s. Keep the server off the open internet, limit who can reach it and sign in to it, and watch it more closely than its neighbours. That’s also where keeping everything else patched matters more, because the operating system and the systems around the database can still be updated while the database itself waits for a decision. Our continuing support page describes how ongoing care for systems like this is arranged. Our data work is specialist consultancy to help you decide and plan, and it doesn’t extend to running your database day to day.
Which of these routes your application can take usually comes down to two things, what the supplier will support and what your licensing paperwork allows. If you’d like a hand gathering both, or want to talk through what a move would mean for your server and network, drop us a line through our contact page.
