How to Phase a Commercial Security System Retrofit

A full commercial security replacement can exceed the available capital budget and create unacceptable disruption. Stretching the work across several years can also create fragmented platforms, temporary gaps and legacy equipment that never retires.

Facilities and capital-planning leaders need a controlled sequence. Begin with a verified service and asset baseline, choose the target architecture, map technical and operational dependencies, stabilize urgent risks, prove one representative pattern, then deploy repeatable waves through evidence-based gates. Each phase should deliver a usable security outcome and leave the property in a known, supportable state. This method fits a broader commercial security system strategy and turns the renewal triggers in a security-system lifecycle plan into executable work.

1. Define the outcome before dividing the budget

Phasing should follow the target operating model. A budget split alone can produce a collection of purchases with incompatible assumptions.

Write a short future-state definition that answers:

• which sites, buildings and security services are in scope;
• which events the organization must detect, verify, investigate and respond to;
• which team owns identities, credentials, video, alarms, privacy, cybersecurity and maintenance;
• what continues locally during loss of network, cloud, server or power;
• which systems exchange events, video, identities or commands;
• how long evidence, configuration and audit records remain available;
• which accessibility and life-safety reviews apply to controlled openings;
• what availability and recovery objectives each service needs; and
• which legacy functions must be retired by a defined date.

Convert the outcome into measurable requirements. “Improve video” offers little direction. “Retrieve an identifiable entrance sequence for an incident reported within the approved discovery period” gives the designer an evidence objective, retention input and acceptance test.

Keep three records separate:

1. Business requirements: the outcomes operations and risk owners need.
2. Technical architecture: the platforms, interfaces, networks and resilience that deliver them.
3. Phase plan: the order, entry criteria, work, tests and exit evidence.

This separation helps leadership change a schedule or budget without silently changing the security outcome.

2. Build a baseline that can survive procurement

Survey the installed system before fixing the scope. Drawings, database exports and service invoices each reveal part of the estate. Reconcile them with physical inspection and operator interviews.

Record at least:

• asset ID, location, manufacturer, model, version, serial number and function;
• condition, fault history, warranty and support dates;
• camera view, door function, alarm zone or intercom route served;
• power, UPS, panel, server, storage, network and licence dependencies;
• cable type, path and observed capacity where it can be verified;
• administrator, operator, vendor and remote-support access;
• integrations, data owner, export method and retention rule;
• critical spare and replacement availability;
• current service contract and response commitment; and
• known deficiency, risk owner and temporary control.

Use a confidence field for every record. “Physically verified,” “platform export,” “drawing only” and “unknown” tell estimators how much uncertainty remains. Make investigation an explicit project activity where the baseline is weak.

The Canadian Centre for Cyber Security’s July 2026 guidance on obsolete products recommends centralized inventories that track product, version, location, business owner and vendor support status. It also recommends assessing data migration, integrations and operational impacts early. The publication covers IT and operational technology broadly, so a physical-security retrofit must add door, video, alarm, intercom and response dependencies.

Produce four baseline outputs before the first solicitation:

1. verified asset and service register;
2. current architecture and data-flow diagram;
3. deficiency, supportability and risk register; and
4. list of assumptions bidders must validate or price separately.

3. Prioritize risk and unlock dependencies

A simple oldest-first sequence can spend capital while leaving the largest operational risk in place. Score each candidate work package on two axes: security or operational consequence and dependency value.

Consequence questions include:

• What happens if this service fails during operating hours or an incident?
• Does the component receive current security fixes and vendor support?
• Can operators detect failure promptly?
• Is a spare, manual process or alternate route available?
• Does the current system meet the approved evidence or access objective?

Dependency questions include:

• Does this network, server, identity source or licence support several later phases?
• Will replacing it twice create avoidable labour or downtime?
• Does a new platform need this component before a pilot can run?
• Can the organization preserve service while old and new components coexist?
• Does the work require a seasonal shutdown, tenant vacancy or construction window?

Use the result to place work into four groups:

Group	Typical decision
High consequence, high dependency	Fund early and treat as a governed foundation phase
High consequence, lower dependency	Correct promptly through a focused risk-reduction package
Lower consequence, high dependency	Coordinate early enough to avoid blocking future waves
Lower consequence, lower dependency	Monitor, bundle with efficient later work or defer with an owner

The Cyber Centre recommends prioritizing exposed or critical obsolete products and using temporary risk-reduction measures only when necessary. It also recommends planning replacement before support ends. Apply that reasoning to connected cameras, recorders, access controllers, intercoms and management servers, then include physical function and service continuity in the decision.

4. Use a phase-gate roadmap

Each phase needs entry criteria, a defined outcome and exit evidence. The Government of Canada’s current Directive on the Management of Projects and Programmes requires project gates to define decisions, evidence, assessment criteria and governance. It also calls for stakeholder input on operational readiness or deployment decisions. The directive governs federal departments, while its evidence-based gating model provides a useful structure for a commercial retrofit.

A practical roadmap can use six phases:

Phase	Outcome	Exit evidence
0. Discover and stabilize	Known baseline and urgent risk controls	Verified register, architecture, priority risks, temporary controls and approved target state
1. Prepare foundations	Capacity and governance ready for migration	Network, power, identity, server, storage, cybersecurity and administration acceptance
2. Prove the pattern	Representative solution works in real operations	Pilot results, defect closure, operator sign-off and updated standard design
3. Deploy waves	Repeatable sites or zones moved safely	Wave-by-wave functional evidence, recovery proof and current records
4. Integrate and optimize	Required workflows operate across systems	Event, evidence, alarm and reporting scenarios pass end to end
5. Retire and close	Legacy risk, access and cost removed	Data handled, credentials revoked, assets sanitized, contracts closed and benefits reviewed

Give every gate an explicit decision: proceed, proceed with approved conditions, hold for correction or re-plan. Name the authority who makes that decision. A progress meeting becomes a gate only when evidence and authority are present.

5. Prepare foundations once

Foundation work can reduce repeated disruption across later waves. Confirm capacity against the approved target architecture:

• network segmentation, switch ports, bandwidth and Power over Ethernet;
• server, cloud, database, storage and retention resources;
• equipment-room power, UPS, cooling and physical protection;
• identity source, credential format, naming and role ownership;
• secure administrator access, logging, certificates and time synchronization;
• remote support path and approval process;
• drawings, configuration backup and recovery tooling; and
• monitoring, service desk and after-hours escalation.

Interoperability requirements need exact functions. ONVIF explains that its profiles define feature sets for conformant IP physical-security products, including access-control and video profiles. ONVIF also places product selection, system design, cybersecurity and local requirements with manufacturers, architects and integrators. Require the exact profile, client, device, firmware and function, then test the intended pairing.

For access-control readers and panels, the Security Industry Association describes OSDP as an open communications standard for panels and peripheral devices. The page identifies bidirectional communication, device supervision and Secure Channel among its capabilities, and notes that OSDP became IEC 60839-11-5:2020. Confirm the installed cable, panel, reader, configuration and verified product support before treating a protocol name as proof of retrofit compatibility.

Create an interface contract for every temporary or permanent connection:

• source and destination system;
• exact information or command exchanged;
• authoritative record and event owner;
• authentication and encryption method;
• time synchronization requirement;
• normal, delayed, duplicate and lost-event behaviour;
• monitoring and support owner; and
• test case and retirement date.

6. Select a representative pilot

The pilot should answer the most expensive uncertainties before a broad rollout. Choose an area that includes common hardware, actual operator workflows, a typical network path and at least one meaningful integration. Keep the business consequence manageable and prepare an achievable recovery path.

Define pilot hypotheses. Examples include:

• existing cable can support the approved reader protocol;
• new cameras record reliably through the production network design;
• operators can correlate an access event with the correct video;
• the credential migration process preserves approved access and removes stale privileges;
• the alarm path reaches the correct responder with usable instructions; and
• the proposed maintenance window fits the facility’s operations.

Set a minimum observation period based on the workflow. A five-minute demonstration cannot show shift changes, after-hours schedules, retention, recurring health alerts or operator adoption.

Capture defects in four categories:

1. design or architecture;
2. product or configuration;
3. installation quality; and
4. process, training or ownership.

Update the standard design, bill of materials, labour assumptions, test plan and communication package before releasing the next wave. The pilot earns its value when its findings change the rollout.

7. Design coexistence as a temporary operating state

During a phased retrofit, operators may face two video platforms, credential databases, alarm consoles or maintenance contracts. Give every object one authoritative owner at every point in time.

Create a coexistence schedule covering:

Topic	Required decision
Door or alarm point	Which platform controls, displays and reports it during the wave?
Credential	Which source creates, changes, revokes and expires access?
Video	Where do live view, playback, export and retention occur?
Incident	Which system holds the authoritative event and case reference?
Operator	Which console and instruction applies to each zone?
Health	Who receives and owns a failure in old and new systems?
Time	How are clock accuracy and time zone verified across platforms?
Support	Which provider responds, and how is responsibility transferred?

Give temporary compatibility an end date and removal test. Long overlap adds licence cost, duplicate administration and investigative ambiguity. Track the conditions required to retire each old function so the final phase remains funded and visible.

8. Package procurement around outcomes and gates

A multi-year retrofit can use one programme contract, several competitive packages or a hybrid. The choice should follow market capacity, interface risk, internal governance and the need for consistent standards.

Every package should state:

• business outcome, sites and system boundaries;
• verified quantities and bidder-validation responsibilities;
• required standards, profiles and exact functions;
• existing assets to reuse, test, isolate, move or retire;
• design, submittal and change-control requirements;
• maintenance windows and continuity constraints;
• pilot and wave entry criteria;
• acceptance scenarios and evidence format;
• critical defect definitions and payment hold points;
• warranty, software support and lifecycle disclosures;
• configuration, drawings, credentials, licences and training deliverables;
• data migration, preservation, sanitization and disposal duties; and
• responsibility for temporary interfaces and their removal.

Manufacturer warranty and lifecycle details deserve separate fields. Axis currently publishes a five-year hardware warranty for most eligible products, subject to product, shipment, purchaser and policy terms. Its AXIS OS lifecycle guide says the manufacturer generally provides five years of operating-system support from product discontinuation and directs buyers to each product page for exact dates. These are manufacturer-specific examples. Require every bidder to supply exact terms and dated evidence for every proposed material component.

Keep allowances controlled. Define what condition activates an allowance, who verifies it, which rate applies and what evidence closes it. Use unit rates for uncertain but repeatable field conditions such as cable replacement, lift access or door repair.

9. Test normal operation, failure and recovery

Accept each wave through scenarios connected to the business requirement. Device counts and online icons provide supporting evidence only.

Test relevant scenarios such as:

1. valid, denied, expired and revoked credentials;
2. forced, held and normally closed doors;
3. video live view, recording, playback, export and time accuracy;
4. intrusion alarm activation, verification, dispatch and restoration;
5. intercom call, routing, release and fallback;
6. operator roles, administrator roles and audit records;
7. network, server, cloud and power interruption;
8. local operation during loss of upstream service;
9. backup restoration or rollback to the approved checkpoint;
10. privacy masks, retention and evidence permissions; and
11. accessible opening and approved life-safety interactions where applicable.

Each test record should contain the requirement, precondition, action, expected result, observed result, evidence, tester, date, defect owner and retest result. Use representative lighting, traffic, schedules and user roles.

Set stop conditions for the cutover. Examples include loss of a critical entrance, incorrect credential grants, missing alarm delivery, unrecoverable configuration, excessive recording gaps or loss of authoritative history. The response may be rollback, controlled isolation, temporary procedure or approved continuation with a time-limited correction. Define the authority before the maintenance window begins.

10. Retire the legacy system completely

Retirement is a funded project phase. Identify stored video, access history, identities, encryption keys, certificates, administrator accounts, cloud tenants, cellular services, licences, monitoring accounts and vendor access before disconnecting equipment.

The Cyber Centre’s obsolete-product guidance recommends backing up required data, sanitizing or destroying storage media, revoking credentials, removing assets from access lists and monitoring, updating inventories and verifying retirement. Apply the organization’s legal, privacy, records and environmental requirements to the final method.

Close the phase with:

• approved data retention, transfer or destruction records;
• revoked user, service, vendor and remote-access credentials;
• removed firewall rules, VPNs and temporary integrations;
• cancelled subscriptions, cellular lines and support agreements;
• recovered spares, licences and reusable components;
• updated drawings, asset register and recovery documentation;
• proof that operators use the new authoritative system; and
• post-retirement monitoring for missed dependencies.

An old server left online for “just in case” preserves cost and exposure. Define the approved historical evidence process and remove the live dependency.

11. Measure whether each phase improved the service

Track measures that support a release decision:

• percentage of in-scope assets physically verified;
• unsupported assets remaining by critical service;
• critical defects open at each gate;
• pilot and wave test pass rate;
• rollback or recovery test result;
• recording, door and alarm health exceptions;
• operator training and competency completion;
• planned versus actual outage and labour;
• temporary interfaces and exceptions past expiry; and
• assets and accounts awaiting secure retirement.

Review benefits at each gate. If a phase delivered equipment while the target response, evidence or availability outcome remains unproven, leadership needs that fact before releasing more capital.

Questions to ask vendors and integrators

1. Which baseline quantities have you physically verified, and which remain assumptions?
2. What target architecture and operating model guide your phase sequence?
3. Which dependencies must be completed before the pilot and each wave?
4. Which legacy and new functions will coexist, and who owns each during transition?
5. Which exact standards profiles, versions, devices and client functions support each interoperability claim?
6. What are the dated warranty, end-of-sale, software-support and hardware-support terms for each proposed product?
7. Which pilot uncertainties will be tested, and how will findings change the standard design?
8. What entry criteria, acceptance evidence and decision authority apply to every gate?
9. What conditions stop a cutover, and how is the prior service recovered?
10. How will credentials, video, configuration and audit history be migrated or preserved?
11. Which temporary licences, interfaces, accounts and network rules will be removed after each wave?
12. What evidence proves that the legacy platform has been securely retired?

A well-phased retrofit gives leaders a usable improvement at every step while preserving a clear path to the final architecture. Securitron Canada can help facilities teams translate a mixed installed estate into a surveyed baseline, dependency map, pilot, wave plan and acceptance programme.