Replacing legacy access control across multiple locations can become difficult long before the system stops opening doors.

The software may be tied to an aging server. One region may be running a different platform than another. Some offices may still rely on older proximity cards while newer locations use mobile credentials. A controller replacement at one site may require a technician who knows equipment the rest of the company stopped using years ago.

That is usually the point when an IT Director or Head of Security starts thinking about replacement.

Then the harder question shows up: Do we have to rip everything out?

The answer is often no.

A well-planned commercial access control migration starts by separating what is outdated from what is still usable. Readers, controllers, power supplies, cabling, locking hardware, credentials, software, databases, and network architecture all have different lifecycles. Some components may need to go. Others may be worth keeping.

For a company with many locations, that distinction matters. It can change the rollout schedule, the amount of work required at each site, and how much disruption the organization experiences while moving to the new platform.

Can a legacy access control system be replaced without replacing every component?

Yes, depending on the existing equipment and the platform selected for the migration.

Some modern access control platforms can work with parts of an installed system, including certain readers, wiring, power supplies, locking hardware, or controller infrastructure. Whether those components should remain depends on compatibility, physical condition, cybersecurity requirements, supportability, firmware, and the architecture being selected. Brivo also documents migration options for organizations with existing legacy control infrastructure.

That does not mean existing hardware should automatically stay.

Every component should be evaluated for four things:

• Compatibility: Can it communicate correctly with the proposed platform?
• Condition: Is the component physically reliable enough to justify keeping it?
• Supportability: Can the manufacturer or integrator still support and replace it?
• Security: Does retaining it preserve an older communication method, credential technology, or network dependency that the organization is trying to remove?

The goal is not to save every old part. The goal is to avoid replacing good infrastructure simply because it is already installed.

Why legacy access control migrations are different across multiple locations

Replacing access control at one building is a project.

Replacing it at 20, 50, or 140 locations is a program.

The difference is repetition. Every mistake gets repeated if the organization does not establish a standard early.

A multi-site migration has to answer questions such as:

• Which locations should move first?
• Which components are approved for reuse?
• What becomes the standard reader, credential, controller, lock, and network approach?
• Which sites require exceptions?
• Who can create users and change permissions?
• How will local teams request changes?
• What happens when internet connectivity is unavailable?
• How will construction or renovation schedules affect deployment?
• How will the company document each site so future service does not depend on tribal knowledge?

A 2026 Alen Security case study documents this type of program for a national architecture, engineering, and construction firm. At the time the case study was published, Alen had completed 50 of approximately 140 offices as part of a phased Brivo access control rollout aligned to construction and renovation schedules.

The lesson is not that every company should use the same platform or deployment model. It is that the organization needs a repeatable process before the rollout grows.

Step 1: Define why legacy access control is being replaced

Do not begin with hardware.

Begin with the problem.

A replacement project can be triggered by very different issues:

• The software or server is reaching end of support.
• Replacement parts are difficult to obtain.
• Multiple sites use different systems.
• Access changes require local IT involvement.
• Former employees remain active too long.
• Security teams cannot see events across the whole company.
• The current credential technology no longer meets internal security requirements.
• The organization wants mobile credentials.
• Video and access events are difficult to investigate together.
• Remote administration is limited.
• A merger or acquisition created several disconnected systems.
• The business is opening sites faster than the current approach can support.

This matters because the problem should determine the migration plan.

If the issue is an unsupported server, retaining compatible field hardware may make sense. If the issue is an older reader interface or insecure credential technology, keeping every reader could preserve the exact weakness the company wanted to remove.

Step 2: Inventory legacy access control across multiple locations

A legacy access control migration across multiple locations should not begin with assumptions about what is installed.

It should begin with a verified inventory.

For each site, document:

• Access control software and version
• Controller manufacturer and model
• Reader manufacturer and model
• Reader-to-controller communication method
• Credential type
• Locking hardware
• Door position switches
• Required egress-release components
• Power supplies and backup batteries
• Panel locations
• Network connectivity
• Cellular connectivity, if used
• Cabling type and condition
• Fire-alarm interfaces where required
• Video integrations
• Identity or HR integrations
• Number of active cardholders
• Local administrative roles

Photos matter. So do labels.

A spreadsheet saying “card reader at front door” is far less useful than a site record that identifies the reader model, controller, cable type, lock, power supply, and panel location.

Good documentation turns future migration decisions into engineering decisions instead of guesses.

Step 3: Decide what can stay and what should go

Once the inventory exists, the organization can classify components in the legacy access control system.

A simple structure works well:

This is where an experienced access control integrator adds real value.

Compatibility is not always obvious from a photo or model number. Firmware, panel versions, reader configuration, credential technology, licensing, and platform support can change the answer.

Reader communication deserves special attention. The Security Industry Association’s Open Supervised Device Protocol, or OSDP, supports bidirectional communication and Secure Channel encryption when properly implemented. An organization may decide that retaining a reader only makes sense if the reader and controller support the communication method required by the new design.

Step 4: Set the access control standard for multiple locations

Multi-site standardization does not mean every location must be physically identical.

A warehouse loading entrance, an executive office, a storefront, and a server room can require different hardware.

The standard should define the approved patterns.

For example:

• Standard cloud, on-premises, or hybrid architecture
• Approved controller families
• Approved reader technologies
• Credential policy
• Preferred reader communication protocol
• Network and firewall requirements
• Logging requirements
• Administrative roles
• Door monitoring requirements
• Video integration approach
• Naming conventions
• Documentation standards
• Backup power expectations
• Remote support process
• Site acceptance testing

This gives the company consistency without forcing the wrong hardware onto a door simply because it appears in a corporate standard.

Step 5: Choose pilot sites carefully

The first migration should teach the organization something.

That is why the first site is rarely the largest or most politically sensitive location.

For multi-site migrations, a phased approach can reduce operational risk. Starting with representative pilot locations gives the project team a chance to validate standards, identify site exceptions, and apply lessons before moving into larger or more complicated facilities.

A useful pilot site should be representative enough to test the standard but controlled enough that adjustments are manageable.

During the pilot, test:

• Credential enrollment
• Permission groups
• Reader behavior
• Door schedules
• Alarm events
• Offline behavior
• Mobile credentials, if used
• Video associations, if used
• Remote administration
• Identity provisioning, if used
• Service procedures
• Documentation process
• Training requirements

The point is not to prove that the new platform works in a lab. The point is to prove that the entire operating model works in a real location.

Step 6: Plan for parallel operation when needed

Some migrations happen during a single shutdown window.

Others require old and new systems to coexist temporarily.

If a company cannot move every site at once, the migration plan should define how credentials, permissions, and administration will work during the overlap period.

Questions include:

• Will users carry two credentials temporarily?
• Can one credential work across both environments?
• Will administrators manage two systems during the transition?
• How will offboarding be handled across both?
• Which system is the source of truth?
• How will access logs be retained?

This is one reason migration planning has to include IT and operations early. A technically successful panel replacement can still create a poor employee experience if credential and identity workflows are not planned.

Step 7: Protect life safety while changing the system

Access control does not override egress requirements.

The 2024 International Building Code includes specific provisions for access-controlled and electrically locked egress doors. UL also publishes guidance on access and egress locking configurations, including sensor release, delayed egress, request-to-exit arrangements, panic hardware, and other locking conditions.

Life-safety and code note: Electronic access control should be designed around safe, code-compliant egress. Requirements vary by opening, occupancy, lock type, fire rating, locally adopted code, and the Authority Having Jurisdiction. A migration assessment can identify issues that require coordination, but it is not a substitute for final code review or approval.

That becomes especially relevant in legacy buildings where the existing door was modified years ago and documentation is incomplete.

A migration may uncover door hardware that should be corrected even if it technically “works” today.

Step 8: Include cybersecurity requirements in the migration standard

A physical access control system is also an IT system.

Controllers communicate. Administrators sign in. APIs connect systems. Cloud services store configuration and events. Remote support may be available. Readers exchange credential data with controllers.

The network architecture alone does not determine whether a system is secure.

NIST’s Zero Trust Architecture guidance emphasizes authentication, authorization, identity, device state, and protection of resources rather than granting trust based only on network location.

For an access control migration, IT should review:

• Administrator authentication
• Multifactor authentication options
• Role-based permissions
• Encryption
• Reader communication
• Logging
• Vendor remote access
• API security
• Firmware and software update process
• Vulnerability response
• Backup and recovery
• Network requirements
• Cloud or cellular connectivity
• Data retention

If a system can operate through outbound encrypted connections and avoid unnecessary inbound firewall rules, that may reduce local network coordination. It does not remove the need for cyber review.

Step 9: Decide how doors should behave during a connectivity outage

Cloud management does not mean a door should stop working when the internet does.

The exact behavior depends on the selected platform and controller architecture.

Many cloud-managed access control designs keep essential door decisions at the local controller so doors can continue operating during a temporary internet outage. The exact offline behavior, local storage limits, synchronization rules, and dependencies vary by platform and should be verified during design.

Before selecting a system, ask:

• Which credentials continue to work offline?
• Can schedules continue locally?
• How are events stored?
• What changes cannot be delivered until connectivity returns?
• What happens after a controller reboot?
• How is time maintained?
• Is a secondary connection needed at certain locations?

Those questions are especially important for distributed facilities where local IT support may be limited.

Step 10: Build the rollout around business operations

A security upgrade should not create an operational crisis.

Some sites can be migrated during normal hours. Others need an evening, weekend, planned shutdown, construction window, or phased door-by-door schedule.

Alen completed a full security upgrade for a domestic food manufacturer during a planned two-week holiday shutdown, allowing both facilities to reopen on the new environment without extending the shutdown. The case study documents the access control, video, and burglar alarm migration.

The right rollout window depends on the business.

A retail location may need overnight work. A manufacturing plant may have planned maintenance periods. An office under renovation may have a natural construction milestone. A warehouse may require coordination around loading operations.

The migration should fit the operating calendar rather than forcing operations to fit the technology.

What should a completed access control migration leave behind across multiple locations?

The result should be more than new equipment.

A strong migration leaves the company with:

• A documented access control standard
• Accurate site records
• Clear administrative ownership
• A defined credential process
• A repeatable installation process
• A service process
• An exception process
• Tested outage behavior
• Current as-built documentation
• A plan for remaining legacy sites

That is how the organization avoids rebuilding the same fragmented environment five years later.

Frequently asked questions about legacy access control migration

Do we have to replace every reader when changing access control platforms?

Not always. Reader reuse depends on model, communication method, credential technology, condition, and support within the proposed platform. A field inventory and compatibility review should happen before the replacement scope is finalized.

Can existing access control wiring be reused?

Often, but it should be inspected. Cable type, condition, topology, distance, interference, and the requirements of the new equipment all matter.

Can old and new access control systems run at the same time?

Yes, some phased migrations require parallel operation. The organization should define credential, offboarding, administration, and audit procedures during the overlap period.

Should every location use exactly the same access control hardware?

No. A multi-site standard should define approved architectures and component families while allowing site-specific exceptions where the physical opening or business use requires them.

How long does a multi-site access control migration take?

There is no universal schedule. The number of locations, site conditions, construction schedules, hardware availability, integrations, permitting, testing, and operating constraints all affect timing.

Planning a legacy access control replacement?

You do not need to decide what stays and what goes before speaking with an integrator.

That is part of the assessment.

Alen Security can review your existing environment, identify what may be worth retaining, document the gaps, and help build a phased migration plan that fits the way your locations actually operate.

Talk with Alen Security about your access control migration.