Where each version stands
| Version | Status | Support ends | Notes |
|---|---|---|---|
| 5.14 | Current | — | Released 12 May 2026. 5.14.0.1 followed 29 June. Web App replaces Web Client, media component is 64-bit. |
| 5.13 | Supported | — | 5.13.3.x is the mature branch and where I put most production systems today. |
| 5.12 | Supported | — | Upgrades directly to 5.14. |
| 5.11 | Supported | — | The last version that upgrades directly to 5.14, and the required stop for anything older. |
| 5.10 | Out of support | — | Four majors behind 5.14. Needs the two-step route. |
| 5.9 | Out of support | December 2025 | Stopped receiving security patches. Anything still on 5.9 is unpatched. |
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.
- 5.13.x 5.14 Direct The straightforward case. Read the 5.14 known issues first; the Web Client retirement changes operator workflows.
- 5.12.x 5.14 Direct
- 5.11.x 5.14 Direct The oldest version with a direct route. If you are on 5.11 and planning to wait, note that 5.15 will put you outside the window.
- 5.10.x latest 5.11 5.14 Two step
- 5.9.x latest 5.11 5.14 Two step
- 5.8.x latest 5.11 5.14 Two step
The single fact that decides a Security Center migration is this: no part of the system can be more than three major versions apart from any other part. Genetec enforces it, and it applies per component rather than to the system as a whole.
That is why the first question is never “what version is the Directory on”. It is “what is the oldest thing anywhere in this deployment”. A Security Desk workstation in a guard house that nobody has logged into since 2021 sets your upgrade route just as firmly as the main server does.
Reading the route table
If everything you own is on 5.11 or newer, you have a direct route to 5.14 and the work is a normal maintenance window. If anything is on 5.10 or older, you are running two upgrades, and they should not share a weekend. Go to the latest 5.11, let the system run, confirm the archives are readable and the doors behave, then go to 5.14.
The temptation on a two-step route is to compress it. Resist that. The reason the intermediate version exists is that the schema and the component contracts changed more than once, and each hop is a separate set of things that can go wrong. Running them back to back means that when something breaks you cannot tell which hop caused it.
The platform underneath decides more than the VMS version does
A Security Center upgrade is also a Windows and SQL decision, and this is where I see the most expensive mistakes. Current shipping releases of the major VMS platforms still list operating systems and database versions that Microsoft has stopped supporting. Supported by the VMS and supported by Microsoft stopped meaning the same thing some time ago.
Two dates to hold in your head. Windows Server 2016 reaches end of support on 12 January 2027, and SQL Server 2016 already passed its date in July 2026. If you are planning a VMS upgrade onto either of them because the compatibility matrix permits it, you are scheduling the same outage twice.
What actually breaks
In rough order of how often I see it: camera trust after a host or certificate change, federation links where the other end is on a version you do not control, and SDK integrations written against an API surface that has moved. What these have in common is that none of them fail during the upgrade. They fail the next time somebody needs them, which is usually the next time somebody needs footage.
The 5.14 release adds one more to that list. Web Client is gone, replaced by Web App, and the migration is automatic. The software handles it fine. What it does not handle is every operator runbook, training deck, and standard operating procedure that names Web Client by the old name. Budget documentation time.
If you are still on 5.9
Security Center 5.9 stopped receiving security patches in December 2025. It is not a version that needs planning so much as a version that needs a date. The route is 5.9 to the latest 5.11 to 5.14, the platform underneath almost certainly needs replacing at the same time, and the hardware may not survive the trip. Treat it as a project rather than a maintenance window, and read the end of life write-up for what that actually involves.
The plan
- 01
Inventory every component, not just the Directory
Record the exact build of the Directory, every Archiver, every Access Manager, the Media Router, all Security Desk and Config Tool workstations, every SDK integration, and both ends of any federation. The three-version rule applies per component, so the oldest thing on the list sets your route, not the main server.
- 02
Fix the platform underneath before touching the VMS
Check the Windows Server build and the SQL Server version against the target release's supported matrix. Do not deploy onto the bottom of the matrix just because the matrix allows it. Server 2016 goes out of support on 12 January 2027 and SQL Server 2016 already has, so a VMS upgrade onto either is a migration you will repeat within a year.
- 03
Take a restorable backup and prove it restores
Directory database, Archiver configuration, and the certificate store. A backup you have not restored is a hypothesis. Restore it to a non-production host and open Config Tool against it before you touch the live system.
- 04
Run the intermediate hop if your route needs one
Anything on 5.8, 5.9, or 5.10 upgrades to the latest 5.11 first, then to 5.14. Let the system run on 5.11 long enough to confirm the archives are readable and the doors behave. Both hops in one window is where people get hurt.
- 05
Upgrade the Directory, then the roles, then the clients
Order matters. The Directory carries the schema change. Roles reconnect to it afterwards. Clients last, because a Security Desk that is newer than the Directory will refuse the connection.
- 06
Re-verify the things that silently break
Camera trust after a host change, federated links in both directions, SDK integrations against the new API surface, custom Mission Control workflows, scheduled reports, and any operator runbook that names Web Client by its old name.
- 07
Hold a rollback point until you have a full recording cycle
Do not decommission the previous environment until archives have written, aged, and been retrieved across at least one full retention boundary. The failure you are looking for is not on day one.
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.
- Exact build number for the Directory, every Archiver, and every Access Manager, written down
- Oldest component version identified. That is what sets your route, not the Directory.
- Windows Server version and patch level on every VMS host
- SQL Server version and edition, including whether it is Express and near a size ceiling
- Licence file located and current, with the reactivation contact known
- Every SDK integration and third-party plugin listed with its vendor and supported version
- Federation partners identified, and whoever runs the other end contacted
- Directory database backed up and test-restored to a non-production host
- Certificate store exported, with private keys, and the export verified
- Archiver configuration exported separately from the database
- Release notes and known issues for the exact target build read end to end
- Target build's supported OS and SQL matrix confirmed against what you actually run
- Rollback plan written, with a named decision point and a time to call it
- Storage headroom confirmed. Schema upgrades need working space.
- Maintenance window agreed with whoever monitors the alarms, in writing
- Directory upgraded first, and confirmed healthy before anything else moves
- Roles brought up one at a time, each verified before the next
- Clients upgraded last
- Camera trust re-established and live video confirmed on a sample per Archiver
- Door hardware exercised: grant, deny, REX, forced, held
- Playback tested against archives written before the upgrade, not just after
- Federated links verified in both directions
- SDK integrations exercised, not just observed as connected
- Scheduled reports and Mission Control workflows run once and checked
- Operator documentation updated where it names retired components
- Previous environment held, not decommissioned, through one full retention cycle
Questions that come up
Can I upgrade straight from 5.9 to 5.14?
No. Genetec enforces a rule that no part of Security Center can be more than three major versions apart, and 5.9 is five majors behind 5.14. You upgrade to the latest 5.11 release first, confirm the system is healthy, then upgrade to 5.14.
Which versions upgrade directly to 5.14?
5.11, 5.12, and 5.13 all have a direct route. 5.8, 5.9, and 5.10 require the two-step path through 5.11.
Is 5.14 the version I should be on right now?
For most production systems, no, not yet. 5.13.3.x is the mature branch. 5.14 is a platform release with the Web Client retirement, a 64-bit media component, and the HID VertX end-of-life notice, which means more surface area and more upgrade considerations. My clock on a major version starts at 30 to 60 days post-GA, and 5.14.0.1 only shipped at the end of June.
What breaks most often on a Security Center upgrade?
Three things, in order. Camera trust after a host or certificate change. Federated links, because the other end is on a version you do not control. And SDK integrations written against an API surface that moved. None of them fail loudly during the upgrade; they fail the next time somebody needs them.
Does the three-version rule apply to workstations too?
Yes. It applies per component. A Security Desk workstation that nobody has touched in four years can be the thing that sets your whole migration route, which is why the inventory step covers clients and not just servers.
References
- Upgrading Security Center from 5.8, 5.9, or 5.10 to 5.14Genetec TechDocstechdocs.genetec.com
- Pre-upgrade checklist for upgrading from an earlier major version of Security CenterGenetec TechDocstechdocs.genetec.com
- Product compatibility with Security Center, 5.10 to 5.14 compatibility matricesGenetec TechDocstechdocs.genetec.com
- Genetec product releasesGenetecgenetec.com
Outbound links open in a new tab. Source-pinned. If a vendor moves a doc, this block gets updated.