C-CURE 9000 migration planning

A C-CURE 9000 upgrade is three migrations wearing one project name: the application, the Windows and SQL platform underneath it, and the firmware on the panels in the field. Each has its own failure mode. Running them in one window means that when a door stops behaving, you cannot tell which of the three caused it.

One honest caveat before anything else

Software House publishes its upgrade paths through the support portal against your licence, rather than openly the way Genetec does. That means you cannot plan this project from a web search, including this page. What follows is the sequencing and the failure modes, which do not change. The specific route from your exact build to your target has to come from the vendor, in writing, before the project gets a date.

I am flagging that rather than filling the gap with a version table I cannot source, because a migration plan built on a guessed upgrade path is worse than no plan.

The platform usually sets the timing

C-CURE 9000 requires a current Windows Server and SQL Server, and those carry hard dates that arrive whether or not you have an application reason to move. Windows Server 2016 ends on 12 January 2027 and SQL Server 2016 ended in July 2026. On most sites one of those lands before any feature you actually want, which means the platform migration is the real project and the application upgrade rides along with it.

That is a useful reframing when asking for budget. “We need to upgrade the access control software” is a discretionary request. “The server holding our access control audit trail stops receiving security patches in January” is not.

The field layer is the part that gets forgotten

The head-end is visible and has a maintenance contract. The iSTAR controllers and Mercury boards in the ceiling are neither, and they have their own firmware compatibility matrix against the application version. A head-end upgrade that leaves panels on incompatible firmware is how a site discovers it has lost doors.

Inventory the panel layer as a separate exercise: every controller with its model and firmware, every Mercury board with its part number, and the reader communication mode per door. While you are in there, check whether any OSDP reader is still sitting in install mode, because that is the single most common finding I see and it has nothing to do with the migration.

Decide the Mercury board question deliberately

If the estate is on EP or LP series boards, the MP series supersedes them. The MP boards keep the EP and LP footprint and interface, which makes a retrofit a board swap rather than a rip-out, and they bring TLS 1.3, secure boot, and FIPS 140-3 validation that the older boards do not have.

The decision worth making now is whether the panel refresh happens with this migration or as its own programme. There is a real argument for either. What there is no argument for is deciding by default, because doing it later means opening every enclosure a second time.

Test a door, not a database

The verification that matters on an access control migration is not that the application starts. It is a full cycle on a representative opening: valid credential grants, invalid denies, request-to-exit releases, forced door alarms, door held alarms, and every one of those reaching the operator position rather than just landing in a log.

Document how each opening type behaves before the window so you have something to compare against. “It seems fine” is not a test result when the thing being tested is egress.

If Genetec is in the picture

Where C-CURE handles access and Genetec handles video, the integration between them has its own version compatibility. Neither migration can be planned in isolation. Work out the supported combination of both platform versions first, then sequence so you are never running an unsupported pair, even briefly. The Security Center route has its own three-version constraint that may end up dictating the order of both projects.