Upgrades, Migrations and Integrations

Rarely in full, and never without it being planned and agreed. Migrations on critical sites are staged specifically so that only a defined area is affected at any one time, with the rest of the facility operating normally.

What is realistic depends on the type of work. A controller replacement affects only the doors on that panel, and for that period those doors are covered by an agreed arrangement, typically staffing, temporary mechanical means or scheduled access, decided with facility management in advance. A server or software upgrade means the central system is unavailable for the window, but modern controllers continue enforcing access offline from their stored configuration, so doors keep working while the head-end is down. What is lost during that window is central monitoring, live changes and, depending on the platform, event reporting until buffers are uploaded.

Video recording is the case that needs its own answer, since recorders down means footage not captured. Where the site cannot accept that, recording is migrated separately from the management server, or recorders are moved in groups so coverage is never fully interrupted.

The plan states which doors, which cameras and which windows, before the work is booked. If we cannot describe the impact area for a stage, the stage is not planned properly yet.

Usually not. Existing reader wiring is often reusable, and in many cases the readers themselves can stay. Controller replacement is a head-end change at the panel, and the field side, meaning the cable run, the reader, the lock and the door contacts, is frequently unaffected.

The cases where field devices do have to change are specific. A move from Wiegand to OSDP needs readers that support OSDP and wiring appropriate to it, though existing cable is often adequate depending on type and length. A move to a different credential technology means readers capable of the new technology. Readers already at end of life, or damaged, are worth replacing while the panel is open regardless.

The survey answers this before a proposal is written. We identify what can be reused, what has to change and why, and where wiring will not carry the new arrangement. Where new cable runs are required, we specify them and the client’s cabling contractor installs them, since we do not do new cabling.

Cardholder data, credentials, access levels, schedules and configuration migrate with the database and are verified after the move by record counts and by sampling actual records, not by assuming the restore was clean.

Event history is the part that needs a decision. Carrying years of history forward is usually possible, but it may extend the migration window considerably and it may bring forward a database that is already unwieldy. The alternative is to migrate a defined recent period and retain the remainder in an archive database that stays queryable for audit and investigation purposes. Which is right depends on retention obligations and how far back the site is realistically asked to produce records.

That decision is made during planning, not discovered on the night. Where regulatory retention applies, the requirement drives it and the archive arrangement is documented so that a future auditor can be told exactly where older records are and how to reach them.

The honest answer is that the upgrade itself is often the shortest part. The duration is driven by database size, whether intermediate versions are required, how many client workstations need updating, the number of integrations to re-verify, and the amount of post-upgrade testing the facility needs.

A single-version step on a modest database with few integrations may fit a single window. A system several versions behind, with a large event history, elevator and intercom integrations and dozens of workstations, is a phased project measured in scheduled sessions rather than one night.

We do not quote a duration from a version number. The survey and a test-environment rehearsal on a copy of the production database give a measured time for the schema conversion and the upgrade itself, and that measurement is what the window is built from. Rehearsing is also what catches the upgrade that runs for many hours on a large database, which is far better learned on a test machine than at 2am on the live one.

Sometimes, and often not directly. Enterprise security platforms frequently require passing through an intermediate version because the database schema conversion for a particular generation exists only in that release. Skipping it is not a matter of preference, the upgrade will refuse or, worse, complete with data that did not convert correctly.

There are other constraints that come with a long gap. Controller and reader firmware may not be supported by the current release, requiring field hardware to change as part of the project. The operating system or database version may be below the minimum for the new software, pulling in a server migration. Licences may need to be brought current before an upgrade is permitted. Integrations built years ago against an older interface may need to be rebuilt rather than carried across.

This is why a long-deferred upgrade is scoped as a programme rather than a task. The survey establishes the actual path, and the result is a sequence of stages with a realistic order. It is common for the right answer to be a parallel migration onto a new server rather than a chain of in-place upgrades, because the parallel route gives a working rollback at every point.

We stop and revert to the previous working state, using the procedure written and timed before the stage started. That is the entire reason the rollback position is defined in advance and the stage is sized to leave time for it inside the window.

Every stage has an abort trigger agreed beforehand, a named person on the client side who can make that call, and a measured restore duration. Reverting is not treated as a failure of the project. It is the mechanism that lets a live facility be worked on at all, and a stage that reverts cleanly leaves the site exactly where it was that morning.

What follows is a written account of what failed and why, and a revised plan for the next attempt. In most cases the cause is something the test environment did not reproduce, and the fix is identified before the next window is booked.