Migration overview

The content of this article is specific to Kisi Standard customers looking to upgrade to Organizations. The SSO/SCIM functionality is a premium add-on. Please contact Kisi Support to learn more.

Kisi Organizations (our enterprise solution) extends Single Sign-On (SSO) and the System for Cross-domain Identity Management (SCIM) to your doors and allows you to manage unlimited locations with streamlined billing — all from one dashboard.

This guide will walk you through the migration process from Kisi Standard to Kisi Organizations. If you want more information on Kisi Organizations or how to upgrade your account, please contact Kisi Support. 

Migration overview

The 2 week migration period is only applicable to existing Kisi Standard accounts in Production, looking to upgrade to Organizations. Customers starting with Kisi Organizations will not need this migration.

The migration process usually takes 2 weeks for customers transitioning from Kisi Standard to Organizations. For the duration of these 2 weeks, you will have access to both Kisi Organizations and Kisi Standard (old Place account).

During this time, your users will have to switch to Organizations' logins and re-login to the new account. For the transition period, both Kisi Organizations and Kisi Standard logins will work for unlocks (during this transition period, both environments will be running in parallel).

Some of the settings, e.g. hardware settings, are shared between these two environments, and some exist independently. The latter includes access shares - if a user has access to a door through one of the places (legacy or organization), but not the other, the user will still be able to unlock that door. Therefore if you need to remove the access for that user during the transition period, you should remove the access in both places. We recommend not to change any other settings in the old place, as it might be confusing to keep track of what exactly applies. 

Entities that are not going to be migrated:

• Event webhooks and user import integrations.
• Empty groups.

Please be aware of the following:

• Any changes to the settings/access/etc that are done for the legacy place after the migration will not be reflected in the organization.
• All group memberships are created with a basic role. That means group admins need to be assigned manually by organization administrators/owners. There are no other roles rather than the Organization Owner, Organization Administrator, Manager, Group Administrator, and Basic.
• All Time Restrictions (for places, locks and groups) will stay the same.
• Events from the last 6 months will be exported and will be accessible in the Reports section of your new Organization after the migration is fully completed.
• During the transition period, while you have access to both accounts, the events will only be created in the Organization account.

FAQ 

SSO Setup

• What is my domain name?
  • It is your domain name, so you can choose any if it fits the format (letters a to z, numbers 0 to 9, and the hyphen (-) character). 

• Will it eventually sign @company.com users into our organization? It asks for our domain right now, and I guarantee you users will guess “company.com” 50% of the time, but it’s “company”. The proper domain that I wish I’d used is “company.com"
  • No dots allowed in the domain name.

• What capabilities does a “Team Manager” have and what roles are there in total?
  • There are only 4 roles:
    • Org Owner - can do everything
    • Org Admin - can do everything but create new Org Admins
    • Team Administrator - can add and remove users from the group that they manage, and basic users
• What are Teams?
  • In general, the Groups (they are called Teams in Organizations) are the same thing as Groups in your old account. 

Credentials

• Does a card need to be removed from the old organization before it can be added to the new one?
• Cards will be auto-transferred to the organization.
• Can multiple company SSO's be supported?
• At the moment there can be one SSO integration per organization only.

Identity Provider Integrations

• I am using ADFS (not Azure ADFS), I didn’t see instructions in the documentation for it.  I assume that it shouldn’t be a problem, since it’s a SAML 2.0 IdP.  Are there any issues with ADFS on-prem?
• We haven’t worked with ADFS yet, and unfortunately we’ve seen that there might be discrepancies between IdPs that claim to be SAML standard. We are currently working on making it easier for us to be flexible and be able to accommodate more SSO IdPs. We will update you as soon as we’re done. 

Directory Integrations

• Should I remove the Google provisioning integration from the old organization before I add the new one?
  
  • • It’s not necessary to remove the integration, however we recommend to do it anyway. As both of the accounts are still functioning, there is a risk of creating discrepancies between the old and new places. For example, if you change restrictions only in one place, the imported users might get more access rights through another place. That’s the reason we recommend to keep the old place in the same state as it was at the moment of the migration.  
• Not all the users in our Kisi are in our Google directory. How are they getting passwords set? Will they still have access? 
• Non-SSO users can be added as normal through their email address. Users will need 'Password Flow' enabled in order to sign-in to Kisi without SSO. 
• Do I need to remove the Google provisioning integration from the old organization before I add the new one?
• It’s not necessary to remove the integration, however we recommend to do it anyway. As both of the accounts are still functioning, there is a risk of creating discrepancies between the old and new places. For example, if you change restrictions only in one place, the imported users might get more access rights through another place. That’s the reason we recommend keeping the old place in the same state as it was at the moment of the migration.
• We have the integrations setup with Azure for our 6 current places – and I think they are working. How do we get things setup so other administrators can see the integrations? Right now, only I can. There needs to be some sort of role that we can put our small group of administrators into (there are currently 3 of us).
• You as an owner can appoint organization administrators. They will be able to see all the integrations and will have the same rights as you but won’t be able to appoint new administrators.The administrators from your previous places have been migrated as group administrators, that is they can only manage the users within that group and can’t manage hardware and change global settings.

Other Integrations

• We have the Schlage wireless locks in our office. It says that event webhooks will not be migrated. What can we do?
• Webhooks are not affecting wireless locks.

Kisi Standard vs Organizations Accounts

I’ve logged into Kisi on my iPhone with the SSO login. I did notice that one of my other sites did not appear although I am granted access at the same email address. How do users who have access to multiple companies manage the logins or access on their device?

1. Organizations account is considered as a separate account even if the email is the same. You will have to logout and login to another account if you want to use the app, to use a card access for one of the places.
1. Check past logins for the user to make sure they are logged in to their SSO account.

Billing

• How are users counted? I have a bunch of disabled and service accounts in AD that won’t be provisioned in Kisi.  Is it only those accounts that are provisioned in Kisi and how is user provisioning handled in the SSO scenario?
• After the migration, all of your existing users will be added to your organization automatically. Otherwise, you can assign the Kisi app to users in your SSO provider. The moment they log in they become Kisi users and will be reflected in your bill.