SmartThings' lock-code migration beta is open, and testers report PIN failures

SmartThings opened its lock-code migration beta on October 7, 2026, after inviting sign-ups on August 28. A SmartThings employee told the first batch of testers to open Smart Lock Guest Access on the Life tab, where a pop-up offers to start the transfer now or later. In the three weeks since, owners have reported codes that did not carry over, a new six-digit minimum and locks where the app can no longer add PINs after the move. None of these reports says an existing code stopped opening the door. SmartThings has not posted in its official thread since October 8, and it has not given a date for the rollout to everyone that it still plans for "later this year." If guest PINs are how a cleaner, carer or dog walker gets in while you are out, postpone the transfer, because the reported failures would leave you unable to add, change or revoke their code from the app.

The transfer moves code management out of the standalone Smart Lock Guest Access service and into each lock's device card, where, by SmartThings' design, every code becomes a user with a PIN credential. Two conditions from SmartThings shape the decision. The transfer applies to every eligible lock in the location at once, so you cannot try it on a spare door first. The beta also requires the standard SmartThings lock driver. SmartThings says codes created under a custom driver "will likely not migrate successfully" and suggests switching to the stock driver and creating new codes before the transfer. One tester, who maintains a community Schlage driver, points out that many Schlage owners run such drivers for lock settings the stock driver lacks, which puts them in exactly the group SmartThings will not vouch for.

What owners have reported since October 7

Every report Matterhome found through October 27 comes from SmartThings' community forum or GitHub and involves a Schlage or Kwikset lock. Each one that names its protocol is Z-Wave:

• A tester's Schlage lock, whose codes had been created under a community driver, migrated with no users or credentials at all. The PINs stayed on the lock, but SmartThings no longer tracked them, and the tester warned that adding a new code from the app could overwrite one of them.
• On October 26, the owner of a Schlage FE599 on the stock driver said all five code names carried over, but attempts to add a four- or six-digit PIN through SmartThings' Advanced Web App never returned a result and the app's Manage Users screen timed out. Working off-site, the owner could not tell whether either PIN reached the lock.
• Owners of the FE599, a Kwikset SmartCode 912 and a Schlage BE469 report that the app now asks for at least six digits. FE599 owners say their lock takes only four-digit codes, so the app cannot add any code to it. SmartThings has not explained the change, and not every report ties it to the transfer.
• The BE469 owner could not add or remove codes in the app after the transfer. Reverting the transfer took a community developer's beta driver and excluding and re-adding the lock, which, the developer warned, deletes the code names SmartThings stores but leaves the PINs on the lock. SmartThings has not documented a way to undo the transfer, or said whether the prompt has reached people who never signed up for the beta.

Two GitHub issues remain open with no linked fix. The tester who reported the empty transfer above filed both against SmartThings' beta Z-Wave lock driver on September 14, three weeks before the beta opened. One reports that a migrated Z-Wave lock falls back to the old code path after its driver is switched away and back; an October 10 comment adds a case where a PIN was written to the lock while the app reported a timeout. The other says a Schlage lock's code scan can stop at its first occupied code. Matterhome has not reproduced any of these problems, and a handful of forum posts cannot show how common they are. They do show the specific ways a transfer can leave a working door code unmanaged.

Matter lock owners have less to go on. SmartThings lists supported Matter locks among the eligible devices and says Matter door locks already use the user and credential model that this transfer brings to Zigbee and Z-Wave locks. Nobody has posted a result for a Matter lock in the official thread, so the reports above neither implicate one nor clear one. Because SmartThings says the transfer covers every eligible lock in the location, a supported Matter lock in Smart Lock Guest Access should move with your Z-Wave or Zigbee locks.

Before you press Transfer

Choosing "later" on the pop-up leaves a tip card in Smart Lock Guest Access with a Transfer button, so postponing keeps the option open. When you do go ahead, write down every active PIN name and the person or routine that depends on it, and keep a key or another way in. Check which driver each lock uses before you start. If a lock runs a community driver, leave it there for now: SmartThings' switch-and-re-create route covers only codes added after the switch, and the tester who switched found the older PINs left on the lock untracked, where a new code from the app can overwrite one. After the transfer, compare the user list on each lock card with your notes, add a test PIN while someone is home, and avoid switching that lock's driver again. If the app times out, try the test PIN at the keypad before retrying: in the October 10 GitHub case, a PIN the app reported as timed out was still written to the lock, where SmartThings did not track it. If the app cannot add a PIN to a migrated lock, report it in the official thread with your phone's operating system, app version, lock model and protocol, which is the information SmartThings asked testers to supply. Open a SmartThings support ticket as well, since no staff member has replied in that thread since October 8.

What changes for integrations

SmartThings is retiring its legacy lockCodes capability in favor of separate lockUsers and lockCredentials capabilities, and extending that model from Matter locks to Zigbee and Z-Wave locks so developers can address them through the same API shape. Existing apps, Rules or services that read lockCodes must be updated before the old services shut down. After a lock migrates, lockCodes commands are no longer processed; integrations should check the lockCodes.migrated attribute and switch to the new capabilities. SmartThings says the deprecation timeline and per-device rollout schedule will come in a follow-up announcement.

Access features still depend on the lock. SmartThings scopes the transition to PIN credentials, and each lock reports the credential types it actually supports. Time-limited schedules depend on the lock exposing SmartThings' lockSchedules capability. Remote lock and unlock commands are unchanged.

Until SmartThings answers the October 26 FE599 report and publishes its follow-up rollout announcement, leave the codes your household depends on in Smart Lock Guest Access.