The next item on our list is identity. We've talked already about the different identity types and how they integrate to Office 365 services. Let's now look at some of the steps you need to take to ensure that you're planning your identity solution properly. 

If you're creating a net new tenant without any kind of on-premises integration, say if you're migrating your email and data from another service provider, you'll need to start out by creating a list of all the users, security groups, distribution groups, contacts, service accounts, and admin accounts in your existing environment. Once you have this list created, you can use it to recreate all these objects in Office 365, including creating your groups and populating them correctly. 

Know that there are some scenarios where you'll have an existing active directory with all your users and groups in it, but you might not be planning to integrate this AD with Office 365. This often happens during a divestiture, where you might need to take a subset of users within a company and separate their identities into a unique Office 365 tenant. In this case, these users might still maintain access to your on-premises infrastructure throughout the migration, but their ultimate identity in Office 365 is going to be a cloud identity. In this case, the same principle applies. 

Take the time to perform a proper discovery of your user and group objects that will need to be created in Office 365. The best way to go about this is to use PowerShell to run an export of the various identities and attributes that you need to recreate in Office 365. Cloud identities will not have any specific on-premises infrastructure requirements, no servers required to synchronize or manage identities. Just know, however, that you'll need to always be managing these identities in the Azure AD or the Office 365 admin portal. Any on-premises identity will not be linked to the cloud identity, and users might need to maintain separate usernames and passwords. However, if you plan to configure hybrid identities, where your users are being synchronized from your local active directory into Office 365, you'll need to plan a little bit differently. Hybrid identities, whether using managed or federated authentication, AAD Connect or ADFS, are still going to need to be synchronized from your existing active directory into Azure Active Directory. This means that your source of authority for identity creation and changes is going to be your on-premises directory. This also means that you won't need to create your users or groups in Office 365. Instead, the AAD Connect server will create copies of your identities in your Office 365 directory and keep them in sync afterwards. 

So, you don't have to start out by making a list of all your identity objects that need to be created, although you will still need to have a list of active users that you might want to migrate in order to plan out your migration batches later. Hybrid identities require a minimum of an AAD Connect server to be installed on premises to manage synchronization of your identities to Azure AD. This server is meant to be treated like an appliance. It can be installed on a domain controller or a dedicated member server and needs to be maintained correctly to ensure that it is able to maintain synchronization indefinitely. Synchronized identities with AAD Connect are probably the most common identity type used in Office 365. As Microsoft continues to add features to the AAD Connect server, including things like pass-through authentication and seamless single sign-on, AAD Connect is fast replacing ADFS as the authentication mechanism of choice, as well. 

Since ADFS requires installing four additional servers in the on-premises environment, more and more companies are choosing the far simpler management and authentication experience provided by AAD Connect.