Switching Management Platforms: Keeping Access Intact Through a System Change

Every few years, buildings change the software that runs their doors. A management company standardizes on a new platform; a new facilities lead arrives with a system they trust; a lease requires integration with the tenant’s own tools. The hardware on the doors is unchanged; everything above it gets replaced — and somewhere in that gap between the doors and the software, people lose access for a week.

Platform migration is a predictable event that almost nobody plans for, and the difference between a smooth switch and a chaotic one is decided before the switch begins: by knowing what actually lives in the old system, what must be rebuilt, and in what order.

What lives where — the three layers

Access systems are usually described as one thing and behave as three. Getting the layers straight is the first step of any migration:

The migration sequence that avoids lockouts

1. Inventory before the switch: the user list is the asset. Export every credential the old system holds: names, doors, methods, dates, special permissions. The export’s completeness decides the migration’s success far more than the new software’s elegance — and the moment to discover gaps is during preparation, not during the switch week.
2. Decide the credential strategy, not just the platform. Three options exist, with very different costs: carry the same physical methods forward (cards keep working, fingerprints need re-enrollment on some architectures), reissue all credentials fresh (most disruptive but cleanest for security-sensitive sites), or stage it by population (staff first, residents after, all with a real cutover date). The right answer depends on site conditions; the essential point is that it’s chosen before the migration starts, deliberately.
3. Run the parallel period. During the overlap, the old system stays authoritative while the new system is populated and tested — but it must be tests with real consequences: sample credentials on each door type, each method, each building area. The parallel period ends when a door-by-door walkthrough says it ends, not when the calendar says so.
4. Cut over per door, if the architecture allows. Where locks can hold their own credential lists, migration can proceed door by door rather than all at once: populate a door, verify it, move to the next. For large buildings this converts a single high-risk morning into a managed sequence — and any failure affects one door, not the building.
5. Tell the humans, twice, with dates. The technical migration can be flawless and still fail if a resident arrives with a dead card nobody warned them about. Two communications, booked and sent: one a week before (what changes, what people must do) and one on the day (what to do if the door doesn’t recognize you). The second message needs a phone number, and someone briefed to answer it.

The five things that break in every migration

• Forgotten special credentials. The cleaner with weekday access, the contractor’s window, the spare for the building’s own staff. General users make the export; exceptions fall through the gaps. Every exception list needs an actual owner and an actual line in the plan.
• The wrong architecture assumption. Whether credentials live on doors or in the cloud doesn’t just affect the migration—it defines what’s even possible. This is the first question for the new platform’s documentation, and for hardware already installed: on our models, each version’s documented architecture (standalone vs app vs platform-managed) tells you exactly what such a migration touches.
• The device update no one scheduled. New management software sometimes needs lock-side configuration changes or firmware actions. Those are physical-visit tasks on larger sites — and they need scheduling before the cutover, because discovering them during it means every affected door is a queue.
• The parallel period that never ends. A dual-system state that lingers indefinitely is an access-audit problem — two lists, neither authoritative. Set the end date of the overlap before it begins, and hold it.
• The rollback plan nobody wrote. If the new system fails on day one, what happens? The migration plan should say: which credentials still work, whether the old system can be re-enabled, and who decides. Even a thin rollback answer converts a catastrophe into an inconvenience.

Creating a migration-ready building

The building that suffers least from platform migration is the one specified with migration in mind, which is mostly about discipline at the original purchase:

• Document the architecture per model. Standalone, app-managed, cloud-platform: know which each lock on your site is. Our product documentation states the available versions per model precisely so this inventory is central and exact — and a building that knows its own answers runs migrations as a checklist; one that doesn’t runs them as archaeology.
• Keep credential management in exactly one place. Buildings that let exceptions accumulate across tools, spreadsheets and personal phones have no single system to migrate; they have a reconstruction project. The migration is the reporting requirement, not the problem.
• Standardize families, accept version spread. Ideally, one lock family per door type. In practice, buildings accumulate versions; what matters is that each door’s documented architecture is known, because version spread is manageable only when it’s mapped.

For operators changing systems across multiple properties, this is the same discipline at portfolio scale — and the same reason our room-door positioning and property-type mapping exist as separate documented lines: portfolios migrate more smoothly when every unit’s hardware answers the same questions.

For distributors and integrators: the migration is the sale

For anyone supplying into this sector, platform migration is one of the most underrated sales contexts in the business. Property owners don’t buy new locks because they’re new — they buy them when a migration forces the question, or when they realize a future one would be painful. A supplier who can discuss the three layers, the parallel period, and the documented architecture of each model is offering exactly what the buyer actually needs in that moment: a partner for the change, not a box.

Common questions

Will residents’ existing cards and codes work with the new system?

It depends entirely on the credential and the architecture — some affordances carry across platforms, others must be re-issued. Rather than promising generically, the honest answer belongs to the specific models’ documentation and the migration plan’s chosen strategy. The plan should say plainly what people must physically do on cutover day; a migration that keeps that sentence vague guarantees a confused first week.

What if some doors are on a different platform entirely?

Then you have a parallel migration, one per platform — same sequence, run per system, with the cutover dates coordinated. The buildings that do this manageably are the ones that mapped their door inventory beforehand; the ones that suffer are those that assumed “all the doors work the same way” and found out on cutover morning.

How much downtime should we plan for?

None, if the migration follows the sequence above — the parallel period, door-by-door cutover, and pre-scheduled device work exist precisely so doors never stop working. If a plan requires doors to be offline, the honest question is why: architecture choices, not the concept of migration, create downtime. That question is worth asking of the migration team, in writing, before any date is set.