PSAP study materials
PSAP study resources

Consolidating Two Legacy PACS Across a 14-Building Campus

PSAP · Put your knowledge to work in context.

All case studies

Consolidating Two Legacy PACS Across a 14-Building Campus

A university campus has 14 buildings and 240 access-controlled doors. Two departments independently bought PACS over eight years: 150 doors on Vendor A with three older panels, one of which is end-of-support, and 90 doors on Vendor B with six panels. Readers are 125 kHz prox using Wiegand wiring; controllers sit on the general campus LAN; four panels have no UPS; and the two head-end servers are in the same basement room with no generator. The campus has 3,500 cardholders, peak 1,800 transactions per hour at class change, and a 15-minute maximum tolerable outage for dorm exterior doors. IT will provide a segmented security VLAN and PoE switches but will not permit inbound vendor remote access. The university wants one PACS within 18 months and no rip-and-replace of all readers.

1. Evaluate centralized versus distributed PACS architecture and recommend controller placement for this campus.

Read the worked answer

For 240 doors, use a distributed architecture with intelligent controllers at each building, not one centralized controller room. Controllers should make local grant/deny decisions and cache cardholder data so a network or head-end outage does not unlock dorm exterior doors. Cluster doors by building and by risk, with separate controllers for life-safety egress and high-security areas. Keep Wiegand only where readers cannot be replaced in phase one, but plan OSDP or reader upgrade because Wiegand is limited and unmonitored. Put controllers on the security VLAN, not the general campus LAN, and power them from PoE or UPS-backed circuits. The 1,800 transactions per hour at class change is modest for distributed panels, but the design should still avoid a single uplink per building. Because IT will not permit inbound vendor remote access, specify an outbound management path or a jump host with MFA. Document offline behavior and test it.

2. Design redundancy and failover for the head-end, network, and power, and explain what the 15-minute outage target should drive.

Read the worked answer

Redundancy needs to address head-end, network, and power separately. Place two head-end servers in different buildings on separate power feeds, with one as active and one as standby; replicate the database and test failover. Put the PACS server room on generator or UPS, and add UPS to the four panels that lack it, prioritizing dorm exterior doors with the 15-minute tolerable outage. Provide diverse network paths from each building to the head-end where feasible; if not, rely on controller offline mode and local caching. Do not put both head-end servers in the same basement. For remote support, require a vendor jump host with MFA, unique accounts, session logging, and no direct internet exposure. Define recovery time and recovery point objectives, back up configurations, and test restoration. The 15-minute outage target should be validated by a controlled test, not assumed.

3. Recommend a migration sequence that avoids dual badging chaos and protects daily campus operations.

Read the worked answer

Migrate in waves by building and risk, not by vendor label. First inventory every door, reader, panel, and cardholder; purge duplicates and stale credentials; standardize door names and time zones. Pilot one building with mixed Vendor A and Vendor B doors and a small user group; validate reader behavior, offline mode, and alarm handling. Use a dual-credential period or a reader that supports both old and new credentials so people are not locked out. Convert cardholders in batches, with a cutover date per building, and keep the old system read-only for audit until the wave is stable. Replace the end-of-support panel first because it is the largest support risk. Do not rip out working readers unless they block security requirements; instead, phase reader upgrades to OSDP or secure credentials. Communicate to 3,500 cardholders, train guards, and define rollback if a wave fails. Measure badge exceptions and help-desk calls before expanding.