Owners of mini hotels, guesthouses and homestays with key card locks tend to pause at the same question when they think about changing software: "After the switch, do the locks on the doors and the stack of cards in the drawer all go in the bin?" The locks are paid for and fixed to every door, so it is a fair worry. The short answer:
📌 Old key card locks can stay in use, on one condition: the lock maker provides an SDK, the connection toolkit that lets other software work with its lock system.
- When a hotel switches to DiCloud: the implementation team reuses the lock maker's SDK to make the connection, and old cards stay in use.
- When the lock maker has no connection with DiCloud yet: the implementation team uses the lock maker's SDK to build one. In this case there is a connection fee, quoted before the work starts.
- When the lock maker does not provide an SDK: the connection cannot be made for now. That is why nobody should promise that "every lock brand can be connected".
Points that depend on each case, such as the card encoder at the desk or the cards of in-house guests, are turned into questions in Parts 4 and 5.
This article is for 1–3 star hotels, where one person may run the desk and look after the technical side as well: which tasks involve the lock system, common lock types and what to ask for each, the condition for keeping old locks, questions for the lock maker, in-house guests, a fallback plan and a checklist. It covers key card locks only. Any other equipment in the hotel should be listed and asked about separately before signing.
Part 1: What key card locks do on check-in day
From the front desk, a key card is a very short task: the guest arrives, the receptionist hands over a card, the guest goes upstairs. Behind that short task, three pieces of information have to be right: the room number, when the guest may enter, and when the card stops working. If the management software and the lock software do not work together, the receptionist types these three items twice, on two screens. When the desk is busy, typing twice means two chances to get it wrong.
So when you talk about "connecting key card locks", think in terms of front desk tasks rather than devices. The lock system comes into play at four moments:
- At check-in: issue a card for the right room and the right check-out date.
- When a guest extends: the card in hand must keep working, or be reissued.
- When a guest changes rooms: the new card opens the new room, and the old card no longer opens the old one.
- When a guest loses a card: issue a replacement, and the lost card no longer opens the door.
These four moments are also the four tests to run before the switch. Many people test card issuing for a new guest and stop there, but trouble at the desk often sits in the other three, which happen less often and are easy to forget.
🔑 One line to keep in mind: the question is not "can my lock be connected?" but "do these four desk tasks run on my exact lock model, and who confirms that?"
Part 2: Common lock types and what they mean for a software switch
When you change software, the lock type decides which questions to ask first. The table below is a general way of sorting locks so the owner can ask the right questions. It is not a list of lock types DiCloud has connected, and the article names no lock brand.
| Lock type | How it usually works | What to ask when switching software |
|---|---|---|
| Standalone card lock | No wiring to each door; access rights are written to the card by an encoder at the desk | Does the lock maker have an SDK for this exact model? Can the current encoder be kept? |
| Networked lock on each door | Each door links back to the lock maker's control system, and access rights update over that link | How does the new software work with the lock maker's control system? Who handles the work on that side? |
| Phone or code-based lock | Guests open the door with a phone or a code issued by the lock maker's system | Which system issues the door codes after the switch? Is there an SDK for this? |
| Older locks with limited support | Installed years ago; the installer may have changed | Who still holds the technical documents? Can the lock maker or installer still provide an SDK? |
You do not need deep technical knowledge to sort this out. Go to the desk, walk up to a room, and write down what you see.
What to write down before asking
- Lock maker and model name, usually on the lock body, the encoder or the card software in use.
- The encoder at the desk: photograph the front, the back and the device label.
- The card software in use: name, version, and which computer it runs on.
- Number of doors with key card locks, and whether any area uses a different model. A hotel that upgraded floor by floor may have two lock generations.
- The installer and a contact person; the lock maintenance contract, if any, and its end date.
A single page with these five lines takes the conversation with the lock maker and the implementation team straight to the point, with no back and forth.
Part 3: The condition for old cards to stay in use — the lock maker's SDK
An SDK is a set of tools and documents from the lock maker that lets other software work with its lock system, for example to request a card. When a hotel switches to DiCloud, the implementation team reuses the lock maker's SDK to make the connection when the lock maker provides one, and old cards stay in use. There are three cases:
| Case | What happens | What the hotel does |
|---|---|---|
| Lock maker already connected with DiCloud | The implementation team reuses the SDK to make the connection; old cards stay in use | Confirm that the hotel's exact lock model and encoder generation are covered by the existing connection |
| No connection yet, but the lock maker provides an SDK | The implementation team uses the SDK to build the connection; there is a connection fee, quoted before the work starts | Request the SDK and documents from the lock maker, and get the fee quote before deciding |
| Lock maker does not provide an SDK | The connection cannot be made for now | Know this before signing, then consider the next step |
The connection depends on whether the lock maker provides an SDK, and that decision is outside the software vendor's hands. Until the lock maker answers, the honest answer is "not confirmed", not "it should be fine".
The same goes for how long the connection takes: it depends on the lock maker, the model, and how quickly the documents arrive. This article gives no number of days; ask for your own case once the implementation team has seen the details from Part 2.
💡 Do not leave this until just before the switch. Ask the SDK question before signing for new software. Ask early, and there is time to request documents and receive a fee quote; ask late, and either the date moves or the desk ends up typing in two places.
Part 4: Questions for the lock maker before the switch
Send them by email or message so the answers come back in writing, with the photos from Part 2 attached. Keep it short and polite, and say clearly that the hotel wants to change its management software and keep its lock system. The lock maker has done nothing wrong here; they just need to know exactly what is being asked in order to answer correctly.
For the lock maker or installer
- Do you provide an SDK for the hotel's exact lock model and encoder generation?
- Are there conditions for the SDK or a usage licence, and are there costs on your side?
- Can the encoder currently at the desk be kept?
- Do cards held by in-house guests on the switch day need redoing? What about staff cards and master cards?
- Does someone from the lock maker or installer need to be present on the switch day, and how much notice is needed?
- If the connection is not running on the day, how does the hotel issue temporary cards?
- Does the lock maintenance contract, if any, have a clause related to changing software?
For the DiCloud implementation team
- Is the hotel's lock model already connected? If not, what is the connection fee and what timing should we expect?
- How does the key card connection run? Does a particular computer at the desk need to stay on, and which device plugs in where?
- Who does which part: the implementation team, the lock maker, the hotel?
- When are the four tasks from Part 1 tested, on which rooms, and who confirms they pass?
Keep both sides' answers in one place, along with the device photos. When the connection moves, the person on shift does not have to start asking again from scratch.
Part 5: In-house guests on the switch day
"Old cards stay in use" refers to the card type and the lock system already installed. Whether the cards guests are holding on the switch day need reissuing is a separate question, for the lock maker and the implementation team to confirm. What the hotel can do right now is prepare for both outcomes, so the desk is not caught out whichever answer comes back.
- List the rooms occupied on the switch day: room number, guest name, check-out date, and whether the guest holds several cards. This list is shared with the work of moving in-house guests to the new software.
- Choose a time when few guests pass the desk, away from the busy check-in and check-out hours.
- Prepare a line for the receptionist in case a guest has to be asked to come to the desk: short, polite, saying what the guest needs to do and how long it takes.
- Ask separately about extensions and room changes: a guest received a card before the switch and extends or changes rooms afterwards. How is the card issued?
How to finalise the room-by-room list and gather deposits for the switch day is covered in guesthouses and homestays switching software: in-house guests and deposits. If the hotel still keeps its records in a spreadsheet, see moving data from Excel to software.
Part 6: A fallback plan for the switch day
The key card connection moves once; the old and new software do not run in parallel. The principle is the same as for the OTA channel link in switching hotel software without losing OTA bookings: data goes first, the link goes after, and it moves once in a chosen time slot. Because it moves only once, preparation is what matters. A fallback here means having a way of working ready if something goes wrong. It does not mean keeping two systems running.
Before the move
- Have the lock maker's written answer on how to issue temporary cards if the connection is not running.
- Know who holds the master card and mechanical key, if the lock system has them, and where to get them outside office hours.
- Print the list of occupied rooms and upcoming arrivals, so the desk can still read it on paper.
- Have phone numbers for the lock maker's contact and the implementation team, and know how late they are on duty.
Right after the move
- Pick two vacant rooms in different locations and run all four tasks: issue a card, extend, change rooms, issue a replacement.
- Take the card up to the door. A message on screen saying it worked is not enough; the door has to open.
- Test an old card on its door, following the implementation team's instructions.
- Confirm a pass before checking in the first guest on the new software, and hand the result over to the next shift.
Receptionists also need to learn how to issue cards on the new screen before the switch. This belongs in the check-in and check-out practice session; see front desk training for day one.
Part 7: A key card checklist for the software switch
| Task | Done when | Who |
|---|---|---|
| Record maker, lock model, encoder, number of doors | One information page exists, with device photos | Owner or person on duty |
| Ask the lock maker about the SDK | A written answer: whether it is provided, and on what conditions | Owner, lock maker |
| Ask the implementation team if the model is connected | You know which of the three cases in Part 3 applies | DiCloud implementation team |
| Get the connection fee quote, if no connection exists | The fee is known before the work starts | DiCloud implementation team |
| Clarify the encoder and in-house guests' cards | An answer exists for the hotel's own lock system | Lock maker, implementation team |
| Set the time slot for moving the connection | A quiet slot, with people on duty from both sides | Owner |
| Practise issuing cards on the new screen | Each receptionist can do all four tasks unaided | Front desk |
| Prepare the fallback | A way to issue temporary cards, a known master card holder, a printed room list | Owner |
| Test on vacant rooms after the move | Doors open correctly on all four tasks, results recorded | Front desk, implementation team |
Part 8: What DiCloud does and does not do for key card locks
On key card locks, here is what can be said firmly about DiCloud:
- The implementation team reuses the lock maker's SDK to make the connection when the lock maker provides one, and old cards stay in use.
- If there is no connection yet, the lock maker's SDK is used to build one, with a connection fee quoted before the work starts.
- The connection moves once, with no parallel run.
What DiCloud cannot decide for the hotel: whether the lock maker provides an SDK, and the warranty or repair of the locks themselves, which sit in the agreement between the hotel and the lock maker.
If the hotel is weighing up a software change in general, old software maintenance fees: renew or switch helps set out the sums before you get to key cards.
Want to know if your lock model is already connected?
Send the DiCloud team the lock maker's name, the lock model and a photo of the encoder at the desk. We will check which case applies to that model and quote any connection fee in advance.
Ask the DiCloud team for freeFrequently asked questions
Do you have to scrap old key card locks when switching hotel software?
With DiCloud, the implementation team reuses the lock maker's SDK (its connection toolkit) to make the connection, and old cards stay in use. The condition is that the lock maker provides an SDK for the hotel's exact lock model, so confirm this with the lock maker and the implementation team before signing.
What if the lock maker has no connection with DiCloud yet?
The implementation team uses the lock maker's SDK to build the connection. In this case there is a connection fee, quoted before the work starts. If the lock maker does not provide an SDK, the connection cannot be made for now, so ask this before deciding to switch.
Can the card encoder at the front desk be kept?
There is no general answer yet, because it depends on the lock model. The hotel should write down the lock model and encoder generation and ask the lock maker and the implementation team, with a written answer before signing.
Do in-house guests need new cards on the switch day?
There is no general answer yet, because it depends on the lock model. The hotel should write down the lock model, prepare a list of occupied rooms and check-out dates, and ask the lock maker and the implementation team, with a written answer before signing. It is also worth asking: if a guest extends or changes rooms after the switch, how is the card issued?
Do the old and new software run the lock connection in parallel?
No. The connection is moved once, in a chosen time slot, in the same way as moving the OTA channel link. Before that, test on vacant rooms and prepare a fallback plan following the lock maker's guidance.
What should be prepared before asking the lock maker?
Write down the lock maker, lock model, encoder generation and number of doors with key card locks, and photograph the encoder and its device label. A single page like this helps the lock maker and the implementation team answer correctly for the hotel's own lock system.
Conclusion
Old key card locks do not automatically go when you switch hotel software. If the lock maker provides an SDK, the implementation team reuses it to make the connection and old cards stay in use; if there is no connection yet, one is built, with a fee quoted in advance. What depends on each lock system, such as the encoder and in-house guests' cards, should be asked clearly and answered in writing before signing. One information page, two question lists and four tests on vacant rooms are enough to keep the switch day under control.
DiCloud is part of the DiHotel Solutions Corps ecosystem, a company with more than 20 years of developing hotel software, serving more than 300 accommodation properties in Vietnam and Japan. As cloud AI hotel management software for mini hotels, guesthouses, homestays and 1–3 star hotels, and as online AI hotel management software, DiCloud opens on the front desk computer as well as on a phone.
For 4–5 star hotels, resorts and multi-property chains, DiHotel, the AI hotel management software, is the original platform, and also hotel management software with key card integration alongside other equipment found in larger hotels. A step-by-step guide to switching hotel management software at that scale is on the DiHotel Blog, as is the companion to this article: switching hotel software: reconnecting locks and PBX