How to Plan a Multi-Site Access Control Migration in Ontario

Replacing access control across several Ontario facilities is an identity, door-hardware, network, and operating-model project. Treating it as a panel swap usually transfers old problems into a newer interface.

The safest migration creates a verified baseline, defines the future control model, proves it at a representative site, and moves in repeatable waves.

Build a Door-Level Source of Truth

Start with a physical survey. For every controlled opening, record:

• unique door ID, building, floor, and room relationship;
• public, staff, service, high-security, or emergency use;
• door and frame material, handing, hinges, closer, latch, and exit hardware;
• lock type, fail-safe or fail-secure behaviour, and local power;
• reader, request-to-exit, position switch, intercom, and operator type;
• fire-alarm or life-safety interface;
• cable path, panel, port, network endpoint, and UPS source;
• current schedule, access groups, alarms, and known exceptions;
• accessibility function and power-door interaction;
• photographs and observed deficiencies.

Compare the survey with database exports, drawings, and panel labels. Differences become migration work—not assumptions.

Clean Identity and Privilege Data First

Do not import every legacy badge because it exists. Establish authoritative sources for employees, contractors, tenants, visitors, and service accounts. Then define:

1. who creates an identity;
2. who approves access;
3. when access begins and expires;
4. how transfers and leaves are handled;
5. who reviews high-risk privileges;
6. how lost credentials and emergency revocation work.

Use role-based access groups tied to job or tenancy need. Direct person-to-door grants should be rare, time-limited, documented exceptions. A migration is the best opportunity to remove duplicate people, inactive cards, shared credentials, and access groups nobody owns.

Define the Future Architecture

Make explicit decisions about hosting, identity integration, field-panel autonomy, and resilience. The design should answer:

• What continues to work if the WAN or cloud service is unavailable?
• Where are credentials and door schedules cached?
• How are controllers authenticated and updated?
• Which network zone contains panels and management servers?
• How are administrative actions logged?
• How are backups restored and tested?
• Which team owns cybersecurity patching after warranty?

Least privilege should apply to systems as well as people. NIST describes zero trust as removing implicit trust based only on network location and requiring explicit, risk-informed access decisions; see NIST SP 800-207. A physical-access platform does not need to be branded “zero trust” to benefit from isolated networks, strong administrator authentication, limited service paths, and continuous logging.

Coordinate Accessibility and Life Safety

Electronic security cannot be designed independently of the door. Ontario’s current Building Code accessibility overview identifies barrier-free paths, entrances, doorway widths, and power door operators among the relevant requirements for new construction and extensive renovations. Review the Ontario accessibility guidance, then have the project’s qualified building, fire, and accessibility professionals confirm the requirements for each opening.

The door schedule should document how credential readers, automatic operators, locking, fire alarm, emergency release, and exit hardware interact in normal, power-failure, fire-alarm, and lockdown states. Test those states physically; do not accept a diagram as proof.

Plan Coexistence

Most enterprise migrations need old and new systems to operate at the same time. Create a coexistence matrix covering:

Topic	Decision to document
Credentials	One credential, dual technology, or temporary reissue
Alarm monitoring	Which console owns each door during each wave
Video integration	Which event source calls the camera view
Visitor management	Which system provisions and expires access
Reporting	Where investigators retrieve authoritative history
Time	How all platforms remain synchronized
Support	Who receives a fault before and after cutover

Give every door a clear moment of ownership transfer. Avoid a prolonged state where operators must guess which platform controls the opening.

Prove the Pattern at a Pilot Site

Select a pilot that represents common hardware and workflows but is not the highest-consequence facility. The pilot should include public and staff doors, an accessible entrance, at least one integration, after-hours scheduling, and remote support.

Acceptance tests should cover valid, invalid, expired, lost, and anti-passback credentials; forced and held doors; request-to-exit; fire-alarm release; power loss; controller isolation; network recovery; operator permissions; audit logs; visitor expiry; and emergency procedures.

Record measured results and revise the standard design before the next wave.

Cut Over in Repeatable Waves

For each site, use the same gated sequence:

1. approved survey and deficiency list;
2. final door and network design;
3. cleaned users and access groups;
4. staged equipment and configuration;
5. communications to local teams;
6. backup and rollback checkpoint;
7. controlled cutover window;
8. door-by-door test evidence;
9. operator sign-off and hypercare;
10. legacy decommission and secure data disposition.

Track success with operational measures: unresolved door faults, access requests outside the new role model, alarm acknowledgement, credential activation time, unauthorized privilege findings, and repeat service calls. A successful migration produces a maintainable control system and a clearer governance model—not merely newer readers.