SQL Server 2016 went out of support on 14 July 2026. If you’re still on it, you’re running a business-critical database with no security patches.
You’re not unusual. Plenty of businesses are still on 2014 or 2012, and in most cases nothing has gone wrong — which is exactly why it keeps getting deferred.
We plan, rehearse and carry out SQL Server upgrades and migrations so they’re dull. ☎
Where you probably are
| Version | Extended support ended / ends |
|---|---|
| SQL Server 2012 | 12 July 2022 — unsupported |
| SQL Server 2014 | 9 July 2024 — unsupported |
| SQL Server 2016 | 14 July 2026 — unsupported |
| SQL Server 2017 | 12 October 2027 |
| SQL Server 2019 | 8 January 2030 |
Out of support means no security updates. For anyone with Cyber Essentials, ISO 27001, a cyber insurance policy or a client security questionnaire, that’s not just a technical problem — it’s the thing that fails the audit.
There are options short of upgrading immediately, including Extended Security Updates and moving to Azure, where extended updates come at no extra cost. We’ll tell you which applies and what it costs.
Don’t know which version you’re on? That’s a two-minute phone call, not a project.
The four jobs people call migration
Version upgrades. 2012, 2014 or 2016 onto a current version. The work is rarely the upgrade itself — it’s the application sitting on top, deprecated syntax, compatibility levels, and the reports nobody has run since 2019.
Server moves. New hardware, a new host, a datacentre change, or off a server that’s out of warranty. Usually an opportunity to fix the storage and memory configuration somebody guessed at years ago.
Consolidation. Several instances, often on several servers, often licensed separately. Bringing them together can cut licensing cost substantially and usually improves what you can monitor and back up properly.
Cloud. Azure SQL Database, Azure SQL Managed Instance, or SQL Server on an Azure VM — three different answers with different costs and different amounts of change. →Azure SQL and cloud
Most real projects are two or three of these at once.
Migrating into SQL Server
The other direction, and a good share of what we do.
- From Microsoft Access, keeping the Access front end and moving the data → Access migration and upgrades
- From MySQL, where a system has outgrown it or the business has standardised on Microsoft → MySQL
- From spreadsheets, where a business-critical process is living in a shared workbook
- From a system nobody supports any more, where the data matters and the application doesn’t → legacy software rescue
How we keep a migration dull
[IMG-2] — Left-aligned. Real evidence: a row-count reconciliation, a cutover runsheet with times against tasks, or a rehearsal log. Redacted. This block is the argument; the artefact is the proof.
Alt: SQL Server migration cutover plan and reconciliation
Upgrades are a necessary part of any system, and they’re also one of the riskiest maintenance procedures you’ll do. They introduce bugs, cause performance changes and take systems down unexpectedly — when they’re not planned properly.
So we plan, test and rehearse the conversion before the real thing.
- Assessment first. What’s on the server, what depends on it, what talks to it, and what breaks. Jobs, linked servers, SSIS packages, reports and the applications you’d forgotten were pointed at it.
- Rehearsal on a copy. The migration is done at least once before the night it matters, and timed, so the window you’re quoted is one we’ve measured.
- Performance validated, not assumed. A newer version can change execution plans. We capture a baseline before and compare after, rather than discovering it on the Monday.
- Cutover agreed in advance, with a cut-off time for calling it off.
- A written rollback plan, and the old system kept intact until you’re satisfied.
- Counts and totals reconciled afterwards, signed off by someone on your side who knows what the numbers should say.
- We’re still here the week after → SQL Server support and consultancy
Before you commit to anything
If you’re not sure whether you need an upgrade, a tune-up or nothing at all, start with an assessment rather than a project.
Slow systems in particular often don’t need migrating — they need the queries and indexes sorting, which is cheaper and quicker → SQL Server performance tuning
Related case studies
D&M Packaging: quality management, supplier control and production planning
A specialist packaging manufacturer needed its quality management system to handle root cause analysis, supplier non-conformance and complaint investigations properly, alongside capacity planning and shift rotas. Development runs continuously rather than in annual releases, so changes land while they're still relevant.
View case study →Dearson Winyard International: case management, reporting and a client portal
An immigration and right-to-work consultancy runs on documentation, deadlines and client visibility. Ongoing development and support keeps the case management system, management dashboards and client portal working, with staff onboarded in a day and issues resolved before they hold up a case.
View case study →Lilleker Engineering: replacing a legacy job costing system, built around how the business runs
A Rotherham fabrication business needed to get off an ageing job costing system without losing the way it works. The replacement covers jobs, materials, purchase orders, enquiries and invoicing, and most of its best features came out of what users found during testing.
View case study →
Which version are you on?
Tell us the SQL Server version, what sits on top of it and when you can take an outage. We'll tell you what the upgrade involves, what it costs and whether it needs doing yet.
Send us the details → SQL Server Health Check →