Before You Modernize Physical Security: The Questions I Ask First

I start with outcomes because different stakeholders often enter the same project with completely different objectives. Security may care about coverage and investigations. IT may care about network architecture, cybersecurity, and support. Facilities may care about infrastructure and construction impact. Executives may care about risk, schedule, and long-term scalability.

Before discussing products, everyone needs to understand what success actually means. If the team isn't aligned on the problem, it won't be aligned on the solution. Getting this question answered early — and making sure the answers are shared across groups — prevents a lot of friction later in the project.

Modernization should solve real problems, not simply replace old technology with newer technology. The problems might involve coverage gaps, operator workflow, aging equipment, disconnected systems, difficult investigations, reliability, infrastructure, maintenance, scalability, or integrations.

This question helps establish what the replacement environment must actually improve. Without a clear answer, there's no way to evaluate whether the proposed solution is the right one — or whether the project will deliver anything meaningfully better than what already exists.

This question changes the conversation. Instead of focusing on equipment, it forces stakeholders to think about business and operational risk. The answer might involve reliability, capacity, aging infrastructure, operational limitations, or something specific to the organization's environment.

Understanding the cost or risk of doing nothing is often just as important as understanding the proposed solution. It also helps establish priorities and gives the project team another important factor to consider when developing scope and sequencing.

Before designing anything new, I want to understand what's already in place: data cabling, fiber, network switches, power, cameras, access-control infrastructure, doors and hardware, server infrastructure, and other supporting systems. Reuse can affect cost, schedule, and project complexity in significant ways.

But I don't automatically assume existing infrastructure should be reused. That leads directly into the next question.

This is one of the questions I consider especially important, and it's one that often doesn't get asked clearly enough. If an organization chooses to reuse existing cabling, fiber, switches, door hardware, or other infrastructure, everyone should understand who owns the risk if that existing infrastructure later creates a problem.

Reuse decisions should be deliberate, documented, and understood by the stakeholders involved. “Existing” and “usable” are not always the same thing. Existing infrastructure may be perfectly serviceable, but if it wasn’t installed, tested or documented as part of the new project, the team needs to understand what assumptions are being made about its condition and performance. The decision to reuse it may be the right one — but it should be a conscious decision with clear ownership, not an assumption.

Complex security environments often contain dependencies that aren't obvious from looking at the primary security platform. Potential dependencies can include access control, video, intrusion, intercom, fire alarm interfaces, elevators, parking systems, license plate recognition, visitor management, identity-management systems, mobile applications, public-safety workflows, and other operational systems.

Not every environment has all of these integrations. But the purpose of the question is to uncover whatever dependencies do exist before migration begins. You don't want to discover a critical integration by accidentally breaking it. That kind of discovery mid-project is expensive, disruptive, and entirely avoidable.

Migration strategy should be part of system design, not something figured out at the end. Before designing a cutover plan, the team needs to understand what cannot go offline, what can tolerate a planned outage, whether old and new systems can operate simultaneously, when cutovers can occur, whether overnight or weekend work is possible, and what operational contingencies are required.

The new system matters. So does the path from the old system to the new one. A migration plan that ignores operational constraints isn't a plan — it's a problem waiting to surface at the worst possible time.

Physical security systems ultimately exist to help people monitor, investigate, and respond. So I want to understand the operator's experience: How long does an investigation take? How many systems does an operator have to navigate? How easily can relevant video be found? How are access events investigated? Which alarms provide useful information? Where does unnecessary friction exist?

Operational friction is often a better guide to system requirements than a manufacturer's feature list. A system that looks impressive in a demo but doesn't reduce the friction operators experience every day hasn't actually improved anything.

Everyday operations and major-event operations can place very different demands on a security environment. In stadium and large-venue environments, event day may involve crowd movement, entrances and exits, parking, perimeters, restricted areas, temporary operations, command environments, and public-safety coordination — all at a scale and pace that looks nothing like a typical Tuesday morning.

My experience working in major sports and entertainment environments has reinforced the importance of understanding event-day operations during discovery. Design for the hardest day, not just the average day. A system designed only around ordinary daily operations will be stressed exactly when it needs to perform most reliably.

Technical design is only part of a successful deployment. Construction schedules have to coexist with actual operations. That means understanding major events, occupancy, dark periods, offseason windows, overnight and weekend work availability, restricted work periods, and site access constraints.

A technically perfect deployment plan isn't useful if the building can't operate around it. Scheduling constraints discovered late in a project can compress timelines, force rework, or push critical milestones into periods when the work simply cannot happen.

Discovery Is Cross-Functional

Physical security modernization is rarely just a Security Department project. My discovery process deliberately involves multiple groups, because the decisions made during design affect all of them.

One of the most valuable outcomes of discovery is often identifying where responsibility crosses departmental boundaries. Those boundary questions — who owns this decision, who accepts this risk, who approves this work — are frequently the ones that determine whether a project runs smoothly or stalls.

Products Come Later

I do eventually evaluate architecture, cameras, access control, cloud-managed systems, integrations, and other technologies. That work is important and it requires real expertise. But those decisions should be informed by discovery.

By the time I start seriously discussing products, I want to understand the business problem, the operational environment, the existing infrastructure, the hidden dependencies, the migration constraints, and who owns the major decisions.

Once those questions are answered, the technology conversation becomes much more productive. The right solution becomes clearer. The wrong solutions are easier to rule out. And the project has a foundation that holds up when it encounters the complications that every complex deployment eventually encounters.