top of page

Cutover checklist - users and groups

So you’re in the middle of a migration project. Let’s say you already have 100% of your data migrated from Google Drive to e.g. Egnyte and are now focusing on keeping the data in sync. Its time to think about how to flip the final switch.

As an IT admin, you need to think about all the processes and workflows your business follows. The new cloud or better yet, cloud collaboration platform needs to tightly fit to what you have already in place. All this to keep any perturbances and downtime at a minimum.

User and Group Migration

Now that the data is in place, have you thought about how users will access the new cloud platform? Ideally you want the user accounts to automatically be created on the new repository. Yes, there are export/import features available most of the time, but those allow you to perform a single import and require you to then manually maintain the user base on many systems. You can do this for ten users, but what about one hundred, a thousand? This is not scalable.

I have experienced myself how manual user management can lead to a terrible outcome. Nevermind issues like name changes (someone getting married for instance), but internal team switches, onboarding and offboarding of users, permission management can quickly become a pain. You may already have an email server, a sales tool, an AD setup for devices, a business communicator, etc. etc. and now there is another system to handle.

Do it manually and you’ll experience users complaining they can’t log in or have never been notified about their new access, just because someone’s name is spelled with a double 'G' after all, or the french accent goes the other way, or even worse, the new system does not allow for special characters in names. Been there … fixed that.

Consider introducing an IDP (Identity Provider), MS ADFS can function as an IDP, Okta is on the market for long and works awesomely, Ping Identity as well, and there are many more. There are plenty of solutions out there, do your research, take your time.

Which ever you settle upon, it should have SCIM compatibility (pretty much standard these days), and should support SAML 2.0. SCIM is an industry standard protocol that allows for user and group creation and management. It will keep your service in sync in terms of user-group affiliation and user status. Deactivate your user once, never worry about any other systems. John Smith decided to switch teams? Sure, put him in the appropriate group in your IDP and be certain all the right access and permissions are granted automatically. This is how SCIM works (when configured correctly).

Now, some cloud collaboration platform providers may not support SCIM. Those may use their own public API endpoints to provision and manage users or may have some ready made inhouse integrations available for this purpose. In those cases, it may be beneficial to consult an expert and potentially develop a custom integration. We at can help with that.

SAML 2.0 is there to authenticate users in the third party system. This is true SSO (Single Sign On), you control who gets access to any service. Do not confuse this with something like LDAP authentication. In the latter, the user needs to type in their password just like anyone else, every time. They only have the benefit of using the same password for every service. In the case of LDAP this would be their AD (Active Directory) password. With true SAML 2.0 based SSO, the user establishes a session and enjoys being already authenticated in every service they use. If properly configured with MS Seamless SSO, this can happen at login to their machine, making the process even easier for the user.

Now that you know the concepts behind SCIM and SAML 2.0, you can go ahead and configure it with the new cloud provider. This will create all the necessary parts for the next step, which is permissions migration. Remember, all the relevant users and groups need to be in place for any permissions to be granted to them.

Minor best practice advice: Provision the users as inactive first, or use any other means of keeping the users from accessing the new platform too soon. You do NOT, I repeat, you do NOT want to have users working on the same dataset in two different places. You can cut over in chunks, but every cut in cut over needs to be a clean cut. Thank me later.


Ready to make first step?

More from

Never miss an update

Thanks for submitting!

bottom of page