Overview
When upgrading from a legacy lock integration (e.g., from Legacy SuiteConnect Schlage to Schlage) to the newer SuiteOp-native integration, each physical lock will appear twice in the system once both accounts are connected — once under the old connection and once under the new one. Both entries reference the same physical device, but SuiteOp treats them as separate locks internally. If both are assigned to the same property at the same time, code conflicts will occur and lock behavior becomes highly unreliable.
This guide walks through the correct process for transitioning locks one by one, covers important edge cases, and includes best practices for teams managing the migration.
Before You Begin
Make sure you have the following ready:
A list of all properties and their associated locks that need to be transitioned
Access to the SuiteOp Properties and Devices pages (you'll want two browser tabs open)
Confirmation of which units are vacant at the time of transition (recommended but not strictly required)
A shared spreadsheet or tracker to log each transition with the property name, date, and status
Step-by-Step Transition Process
1. Identify the Legacy and New Lock
Navigate to the property you want to transition. You'll see one lock assigned to the one from the legacy integration.
You can always tell apart a Legacy from a new one is by checking the lock's connection type on the Devices Settings page.
2. Rename the Legacy Lock (Internal Name Only)
On the legacy lock, add an "L" prefix to the internal name to mark it as legacy. For example, rename Front Door to L Front Door.
Important: This will change the public (guest-facing) name, so it’s important not to rename it anything like [OLD LOCK]. The internal name is what Schlage uses and the public name is what guests see.
3. Remove the Legacy Lock from the Property
Unassign the legacy lock from the property. This is the critical order-of-operations step:
Always remove the old lock first, then assign the new one. If you assign the new lock while the old one is still attached, both will try to manage codes on the same physical device simultaneously, causing conflicts. This is the most common source of issues during transitions.
4. Assign the New Lock to the Property
Go to the Devices page, find the new integration lock (it will show as "Not Provisioned" when clicked on), and assign it to the property.
5. Wait for Provisioning to Complete
Once assigned, SuiteOp will automatically provision the lock. Provisioning pushes codes in this specific order:
Backup codes — generated fresh and pushed first so there's always a fallback
Reservation codes — any active guest codes are pushed next to protect the guest experience
User codes — staff and cleaner codes are pushed last
Provisioning typically takes 10–15 minutes. During this time, you may see codes appear with a red status or labeled as "Unknown." This is normal — it means SuiteOp is re-pushing codes that already existed on the lock from the legacy integration.
While provisioning is happening, you can take a note that this one is done and move on to the next lock.
6. Verify Lock Settings on the New Lock
After assigning the new lock, check and configure these settings:
Battery threshold: Default is 30%. Increase to 40–50% for locks that tend to drain quickly.
Remote control: Enable this so your team can remotely unlock the door, and guests can remote unlock once pre-check-in is completed (only if Device visibility is set to Public, more on this below).
Device visibility (Public): Toggle the device to Public so guests can see and use the swipe-to-unlock feature in their portal.
Staff access: Make sure this is enabled if housekeepers or other staff need code access.
7. Verify the Next Morning
Come back the next day and check that all codes show a green/synced status. If one or two codes are still red, press Refresh on those individual codes. This sends a ping to the lock to re-sync.
Edge Cases and Special Scenarios
Locks Shared Across Multiple Properties
Some locks are assigned to more than one property — for example, a unit that can be rented as a full house or as a smaller portion ("small" unit). When transitioning:
If you’re only doing vacant properties (not necessary):
Only remove the legacy lock from properties that are currently vacant.
Leave the legacy lock assigned to any property that is occupied.
Track which properties still need the transition and come back to them when they're vacant.
The legacy lock will continue to function via remote unlock on occupied properties in the meantime.
Legacy locks assigned to specific units will still work.
Building or Common Area Locks
Building entry locks (e.g., a shared front door for a multi-unit building) are often assigned to many properties at once. These require special handling:
Do not transition these during peak check-in hours. Aim for late morning or early afternoon when housekeepers have already entered their first units.
Remove all legacy assignments at once, then assign the new lock to all relevant properties.
Provisioning should always maintain existing guest codes (SuiteOp identifies guest codes on Legacy locks, wipes them, and re-installs new ones) so the transition should be seamless — but timing it well reduces risk.
Archive and Delete Locks
The next morning, you can archive all your legacy devices.
Wait 30-days before deleting all devices.
Just make sure they're no longer assigned to any active property before archiving or deleting a lock.
What "Unknown" Codes Mean
During and shortly after provisioning, you may see codes labeled as Unknown. These are codes that exist on the physical lock but were originally pushed by the legacy integration, not by the new one. SuiteOp displays them as Unknown because this ‘new lock’ does not manage these codes.
Over the course of provisioning, SuiteOp will re-push these codes under its own management. If a code already exists on the lock, SuiteOp will request that the lock delete it first, then re-push it. This process resolves most Unknown codes automatically within 10–15 minutes.
If Unknown codes persist after an hour, try pressing Refresh on individual codes. If this still persists, contact support.
What to Tell Your Team
Share these key points with anyone managing properties during the transition:
Locks labeled with "L" are legacy locks. They may still work for remote unlock, but the codes on them are no longer being actively managed. Do not rely on the codes shown on a legacy lock.
Only the lock assigned to the property matters. If a property has a new integration lock assigned, that's the one managing codes. The legacy one is just waiting to be archived.
Do not re-assign legacy locks to properties. If a legacy lock accidentally gets assigned back to a property, it will cause conflicts. This is why we use the "L" prefix — to make legacy locks easy to identify.
Don't archive legacy locks yet if they're still assigned to any property. Wait until all assignments are cleared before archiving.
When to Archive and When to Delete
Action | When | Why |
Rename to "L" | During transition | Helps identify legacy locks at a glance |
Unassign from property | During transition | Prevents code conflicts with the new lock |
Archive | After all properties are unassigned from the legacy lock | Hides legacy locks from the default view to reduce clutter |
Delete | ~1-2 months after full migration | Deleting too early causes reservations to show "failed" status for codes that are actually working fine on the new lock. Wait until the transition is fully settled. |
Why not delete immediately? If a legacy lock is deleted while reservations still reference it, you'll see false "failed" or "inactive" statuses on codes — even though the new lock is working perfectly. This creates unnecessary confusion and support tickets. Archiving keeps things clean without causing false negatives.
Troubleshooting
Codes are still red after 15+ minutes
Try pressing Refresh on individual codes. If more than a couple are stuck, wait an hour and check again — the lock may be processing a large backlog.
"Lock is full" error
Schlage locks have a ~200 code limit. If you see this error, it means the lock has too many codes (including old Unknown ones). Contact support to help clear unused codes.
Duplicate code error
If SuiteOp tries to push a code that already exists on the lock, it will automatically request a delete-then-re-push. This is handled automatically but may take a few extra minutes.
Best Practices
Transition a manageable batch each day — 15–20 properties at a time is a comfortable pace that will take about 30-minutes per day. You don't have to do them all at once.
Always check your work the next morning by reviewing the locks you transitioned the day before.
Keep a shared tracker with property name, transition date, and status so your team stays aligned.
Don't rush building locks — save complex multi-unit transitions for a calm window in your schedule.
Reach out on Slack if anything looks off — the SuiteOp team can investigate quickly if you flag issues early.