Where each version stands
| Version | Status | Support ends | Notes |
|---|---|---|---|
| SQL Server 2022 | Current | 12 January 2032 | The target for a new build. Mainstream support runs to January 2027, extended to 2032. |
| SQL Server 2019 | Supported | 8 January 2030 | Mainstream ended January 2025. Still a reasonable landing spot with a long extended runway. |
| SQL Server 2017 | Support ending | 12 October 2027 | Just over a year left. Do not migrate onto this. |
| SQL Server 2016 | Out of support | 14 July 2026 | Already past, and still listed in current VMS support matrices. This is the one to find. |
Supported upgrade routes
Read this before you plan anything else. A route that is not supported is not a route, and finding that out mid-window is how a maintenance weekend turns into a restore from backup.
- SQL 2016 SQL 2022 Direct In-place upgrade is supported. Whether your security platform supports 2022 is the separate question that actually decides it.
- SQL 2016 SQL 2019 Direct The conservative choice when the application matrix has not caught up to 2022.
- SQL 2017 SQL 2022 Direct
- SQL Express (any) SQL Standard Direct Edition upgrade, not a version upgrade. Needed once the database approaches the Express size ceiling.
This is the one I would look at this week.
SQL Server 2016 reached end of support on 14 July 2026. It is already past. Meanwhile the current shipping releases of both major VMS platforms still list SQL Server 2016 among their supported versions.
Read that again. The database floor for current VMS releases is a product that stopped receiving security updates over a year ago.
That is not a reason to panic and it is not a vendor scandal. Support matrices lag. But it does mean two things. If you are standing up a new system this year, do not deploy on the bottom of the support matrix just because the matrix allows it. And if you are quoting a client an upgrade to current supported versions, be specific about which ones, because supported by the application and supported by Microsoft have stopped meaning the same thing.
Check the edition before the version
On security platforms the database is usually installed silently by the application installer, and it frequently lands on Express. Express has a hard per-database size ceiling and a memory cap. A system that has been logging card reads, alarms, and health events for eight years grows into that ceiling, and the failure mode is not graceful: the database stops accepting writes.
Query the edition and the current size today, whether or not you are planning a migration. It is a two-minute check that occasionally turns up an outage you have not had yet.
The application decides, not you
The target version is set by whatever the security platform supports, not by what Microsoft recommends. Confirm the exact application build against the exact SQL version before committing to anything. For Genetec specifically, that check belongs in the same conversation as the Security Center upgrade route, because doing the database and the VMS in separate windows is usually the right call and doing them in the wrong order is not.
Orphaned users, every time
The most common post-migration failure on a security database has nothing to do with performance or compatibility. The database restores fine, the application cannot authenticate, and it presents as something far more serious than it is.
What happened is that the logins did not map. Database users carry a SID that has to match a server login, and a restore to a different instance breaks that link. Script the logins out with their SIDs before you start and the problem does not occur. Discover it at 1 a.m. and you will spend an hour convinced the migration destroyed the database.
Compatibility level is a decision, not a default
An upgraded database keeps the compatibility level it had. Sometimes that is correct, because the application requires it. Sometimes it is the reason you see none of the performance improvement you just paid a maintenance window for. Either way, set it on purpose and write down why.
The same discipline applies to the host underneath. If SQL shares a box with the application, the Windows Server lifecycle and this one need sequencing together, and separating the database onto its own host during the migration is often worth the extra work.
The plan
- 01
Find out which SQL version and edition is actually running
Not what the deployment document says. Query it. On a security platform the database is often installed silently by the application installer, and the version it chose years ago is not the version anybody remembers picking.
- 02
Check the edition, not just the version
SQL Express has a hard database size ceiling and a memory cap. A security platform that has been logging events for eight years grows into it, and the failure mode is that the database stops accepting writes. Check current size against the ceiling before you plan anything else.
- 03
Confirm the application supports the target version
This is the gate. The VMS or access platform decides what you can land on. Confirm the exact application build against the exact SQL version, and be aware that the matrix may still list versions Microsoft has retired.
- 04
Decide in-place versus side-by-side
In-place is faster and keeps the instance name and connection strings intact, which matters because a security application often has the connection embedded in places nobody documented. Side-by-side gives you a clean instance and a real rollback, at the cost of finding every connection string.
- 05
Back up, restore somewhere else, and open the application against it
A backup that has not been restored is a hypothesis. Restore to a non-production instance and point a test application install at it. On a VMS this proves the archive index survived, which is the thing you actually care about.
- 06
Run the upgrade, then rebuild what the upgrade does not carry
SQL Agent jobs, maintenance plans, linked servers, logins as distinct from users, and the backup schedule. Orphaned users after a restore are the most common post-migration failure, and they present as the application simply refusing to authenticate.
- 07
Set the compatibility level deliberately
An upgraded database keeps its old compatibility level. Leaving it there is sometimes correct if the application requires it, and sometimes the reason you see none of the performance benefit. Decide it on purpose and record the reason.
Pre-flight checklist
Print it, or hand it to whoever is doing the work. Every line is something I have seen bite a real migration.
- SQL version, edition, and service pack, queried rather than assumed
- Current database size against the Express ceiling, if Express
- Local or remote instance, and which applications share it
- Recovery model, and whether transaction logs are actually being backed up
- Application's supported SQL matrix for the target application version
- Service account the instance runs as, and what it has rights to
- Full backup plus transaction log backup, test-restored to a separate instance
- Test application install pointed at the restored copy and opened successfully
- SQL Agent jobs, maintenance plans, and linked servers exported
- Logins scripted out, including SIDs, so users do not orphan
- Connection strings located everywhere they exist, including registry and config files
- Disk headroom confirmed for the upgrade and for growth
- Rollback plan with a decision point and a restore time estimate
- Express edition hitting its size ceiling mid-migration
- Orphaned users after a restore, presenting as authentication failure
- Compatibility level silently carried forward from the old version
- Collation mismatch between the old instance and a new one
- TLS enforcement on the new instance rejecting an older application client
- Applications sharing the instance that nobody remembered were there
- Application connects, and archive or event history from before the move is retrievable
- Orphaned users checked for explicitly, not assumed absent
- SQL Agent jobs re-created and each one run once
- Backup schedule re-established and its first run verified as restorable
- Compatibility level set deliberately and recorded
- Old instance retained until one full retention cycle has passed
Questions that come up
Our VMS support matrix still lists SQL Server 2016. Is that safe?
No. SQL Server 2016 reached end of support on 14 July 2026, so it receives no security updates. A vendor listing it means the vendor will support their software running on it. It does not mean Microsoft is patching it. Those are different statements and only one of them is about your risk.
SQL 2019 or SQL 2022?
2022 if your application supports it, because extended support runs to 2032. 2019 is the conservative choice when the application matrix has not caught up, and it still gives you until 2030. Do not land on 2017, it has about a year left.
How do I know if I am on Express and about to hit the ceiling?
Query the edition and the current database size. Express has a hard per-database size limit and a memory cap. A security platform logging events for years grows into it, and the failure mode is that writes stop. This is worth checking today even if you are not planning a migration.
In-place or side-by-side?
In-place is faster and keeps the instance name, which matters because security applications embed connection strings in places nobody documented. Side-by-side gives a clean instance and a genuine rollback. If you have the window and can find every connection string, side-by-side is safer.
What breaks most often?
Orphaned users after a restore. The database comes across, the logins do not map, and the application simply cannot authenticate. It looks like a much bigger failure than it is. Script the logins with their SIDs beforehand and it does not happen.
References
- SQL Server 2016 lifecycleMicrosoft Learnlearn.microsoft.com
- SQL Server end of support overviewMicrosoft Learnlearn.microsoft.com
- SQL Server 2017 lifecycleMicrosoft Learnlearn.microsoft.com
Outbound links open in a new tab. Source-pinned. If a vendor moves a doc, this block gets updated.