Moving Mercury-Based Access Control to the Cloud Without Replacing Your Panels

If your building runs on Mercury Security controllers, you already own the hardest part of a modern access control system. Mercury's open controller platform sits inside products from many of the largest access brands, which is why thousands of buildings run Mercury panels today. What most of those buildings do not have is cloud management, video tied to door events, or an operator that can act across sites. This guide explains how to add those without pulling a single panel off the wall.

What you already have

A typical Mercury-based installation has four layers, and only one of them needs to change.

Controllers. Mercury's intelligent controllers (the LP series and the newer MP series, among others) sit in a closet or electrical room, hold the access decisions locally, and connect to door hardware. They are built to an open architecture that supports a wide ecosystem of readers, credentials, locking hardware and downstream devices.

Readers and credentials. Card readers, keypads and, increasingly, mobile and biometric readers wired to the controller over Wiegand or OSDP. The credential population (cards, fobs, mobile IDs) lives in whatever software manages the controllers.

Door hardware and wiring. Electric strikes, maglocks, request-to-exit devices, door contacts, and the cabling between them and the panel. This is the expensive, labor-heavy layer, and it is entirely independent of the software brand.

Management software. The server or appliance, usually on premises, where administrators manage people, schedules and reports. This is the layer a cloud migration replaces.

The migration question, then, is narrow: can new software take over the controllers you have, so the readers, locks and wiring stay as they are?

What a cloud move keeps and what it replaces

With a platform that supports Mercury natively, the answer is yes. Alocity's Control Center manages standards-based Mercury hardware directly, so existing Mercury-based sites can move to the cloud without replacing controllers, and existing panels stay in service while each site moves at its own pace. Customers can connect Mercury-based controllers, readers and locking hardware directly to the platform.

• Kept: controllers, readers, locks, request-to-exit devices, door contacts, cabling, and in most cases the credentials themselves.
• Replaced: the on-premises management server and its licensing, the per-site administration model, and the manual export of audit data.
• Added: cloud management of users, policies, schedules and audit logs across every site; video linked to door events; AI that watches cameras and doors together; and an operator that can act on what it sees.

Two things to confirm with any vendor making this claim. First, which controller models and firmware versions they support today. Second, whether the migration keeps the controller's local decision-making, so doors keep working if the internet connection drops. A controller that only forwards requests to the cloud is a downgrade from what you have.

Wiegand to OSDP on the same panel

Many Mercury installations still run readers over Wiegand, a one-way, unencrypted protocol from the 1980s. OSDP (Open Supervised Device Protocol) is the industry standard that replaces it: two-way, supervised, with encryption available between reader and controller. The Security Industry Association and AMAG Technology launched a tiered OSDP training program in September 2026 with a certified badge for completers. As AMAG's Kyle Gordon put it, "All of the leading access, identity and credential companies have adopted OSDP as their primary secure communications protocol" (Security Info Watch, Sept. 23, 2026).

The practical point for a migration is that Mercury controllers support OSDP, so moving readers from Wiegand to OSDP is a reader and configuration change, not a panel change, and it can be done door by door after the cloud migration rather than before it. Readers that support both, such as Alocity's F3D100 video intercom reader with OSDP, RS-485 and Wiegand, let you switch each door when it is convenient.

A reasonable order: migrate the software first, then convert the highest-risk doors (perimeter, cash, server rooms) to OSDP with supervision enabled, then the rest as readers are replaced in the normal cycle.

Phased migration: one site, one door group

The building that loses access control for an afternoon remembers it for years. The migration plan should make that impossible.

1. Inventory. For each site: controller models and firmware, reader types and wiring protocol, door count, credential formats in use, and any integrations (elevator, intrusion, visitor) tied to the current software.
2. Credential export. Export the cardholder database with card numbers and formats. Confirm the new platform reads the same formats so existing cards keep working on day one.
3. Pilot one site. Connect its controllers to the cloud platform while the legacy server still runs. Verify every door, every schedule and every credential, then cut over. Keep the old server available for a defined rollback window.
4. Move by door group. At larger sites, migrate perimeter doors first, then interior groups, so an issue affects a defined set of doors and a defined set of people.
5. Convert readers to OSDP as above, after the software cutover.
6. Retire the legacy server only when every site is live and the audit history has been exported.

Budget the labor honestly. The software migration is hours per site; the OSDP conversion is a reader visit per door; the thing you are not paying for is the panel replacement and rewiring that a proprietary platform would require.

Keep the hardware, upgrade the brain

Once the controllers report to the cloud, the panel is no longer the ceiling of what the system can do. The same door events can now be joined to video and acted on.

Video. Every access event is linked with synchronized video in a unified platform (Access Control), and that video can come from the cameras already installed. Alocity's AiVR edge recorder connects to virtually any ONVIF or RTSP IP camera and runs NVIDIA-powered inference locally, so a "door forced" event on a Mercury panel arrives with the clip and a search across every camera on site.

Operator. A copilot reacts when asked; an operator acts before you ask. With doors and cameras in one system, rules like "if a perimeter door is held open after hours and a person is detected, lock the interior doors and notify the site lead with the clip" run without a person watching. Control Center records every command, event, approval and operator action, and high-risk actions can require human approval while routine workflows run automatically.

That is the case for open hardware in one sentence: the controllers you bought in 2018 can run software designed in 2026, and the next upgrade is a software change too.

Cyber posture: the gap the survey found

Mercury Security's 2026 Trends in Access Controllers Report, a global survey of 561 physical security and cybersecurity professionals, found that 32% identified cybersecurity features as missing from their current controller systems, up from 21% in 2025. The same survey found 74% say cybersecurity and IT coordination have become more complex, 69% call interoperability a critical procurement factor, 82% say backward and forward compatibility matters, and 56% cite cloud connectivity as a purchase factor while only 41% say their controllers are cloud-enabled (Security Info Watch, Sept. 29, 2026).

A cloud migration is the moment to close that gap, because the controller's network configuration is being touched anyway. The checklist:

• Controllers on current firmware, with the vendor's security advisories reviewed.
• Encrypted controller-to-cloud communication, and an understanding of what the controller does if the link drops.
• OSDP with Secure Channel on the doors that matter most.
• Controllers on a segmented network, not the guest Wi-Fi VLAN.
• Role-based access to the management platform, with the audit log reviewed on a schedule.
• A documented process for revoking credentials and administrator accounts the day someone leaves.

Mercury's own survey language is the useful summary: organizations want to modernize gradually while preserving existing investments. A phased cloud migration is exactly that.

Integrator checklist

For dealers and integrators scoping a Mercury-to-cloud project, these are the questions that decide the quote.

1. Which Mercury controller models and firmware are on site, and does the target platform support each one?
2. What credential formats are in use, and will they import unchanged?
3. Which readers are Wiegand, which are OSDP, and which doors should convert first?
4. What integrations (elevator, intrusion, visitor, HR directory) depend on the legacy server?
5. Does the site have cameras worth keeping, and are they ONVIF or RTSP?
6. What is the rollback plan for the pilot site, and how long does the legacy server stay available?
7. Who owns roles, schedules and audit review after cutover?

For integrators that already install and service Mercury, the migration is a software project on hardware they know, and a new software and AI platform to bring into existing Mercury conversations. See how Alocity works with partners and the supported access controllers.

Frequently asked questions

Can Mercury access control panels be moved to the cloud without replacing them?

Yes, with a platform that manages Mercury controllers natively. The panels, readers, locks and wiring stay; the on-premises management software is replaced by cloud management. Confirm model and firmware support with the vendor.

Which Mercury controllers are supported?

Support varies by platform. Ask the vendor for its current list of supported LP and MP series controllers and firmware versions, and have them verify your inventory before quoting.

Will existing cards and fobs keep working?

In most migrations, yes, provided the new platform supports the same card formats. Export the cardholder database and test a sample of credentials at the pilot site before cutover.

What is the difference between OSDP and Wiegand?

Wiegand is a one-way, unencrypted reader protocol. OSDP is two-way and supervised, with encryption available between reader and controller. Mercury controllers support OSDP, so the switch is a reader change rather than a panel change.

Do doors keep working if the internet goes down?

With a controller that keeps access decisions local, yes: the panel continues to grant or deny access from its stored rules and syncs events when the connection returns. Ask any vendor to demonstrate offline behavior.

How long does a migration take?

The software cutover is typically hours per site after a pilot. Reader conversions to OSDP add a visit per door and can follow the normal replacement cycle. A proprietary rip-and-replace is measured in weeks per site and includes rewiring.

What does adding video and AI require?

An edge recorder that works with existing ONVIF or RTSP cameras and a platform that links door events to clips. No camera replacement is required for cameras that meet those standards.

See Aimee in action

Running Mercury panels today? Book a live Aimee demo and bring your controller inventory. We will show the migration on hardware like yours.