Authentication and identity are the most important aspects of a successful Office 365 migration in my not so humble opinion. There are many articles discussing the merits of pass-through authentication (PTA), ADFS and password hash sync (PHS) so I'll give you the cliff's notes version.
Chances are if you don't have ADFS in your environment you won't need to introduce it. The default choice is PTA with password hash sync, and seamless SSO enabled. This provides the benefits of PTA (such as enforcing password policies at the time of sign-in) but provides a fail-safe in case of PTA being unavailable.
Keep in mind the failover from PTA to password hash sync is not automatic so please deploy more than one PTA agent (preferably from a different physical location) :) If you prefer that Microsoft doesn't hold hashed versions of your user's passwords, you can skip that part if you are comfortable with your PTA deployment.
Your migration may have been technically perfect, however, if someone from the board or management team has an extended period without email on their phone it may cause some un-needed attention toward the project you're leading. The phrase it "should" just work gets thrown around a lot during a hybrid scenario; however, in my experience, very few customers have a consistent environment. That consistent environment would be MDM managed devices with the same application to access email. Using Intune as your MDM with Company Portal allows for the automatic configuration of email accounts, along with the application of App Protection policies (check out our blog post here). Unfortunately, reality is that there will be users out there using different versions of the built-in active sync client on Android and iOS and others using the Outlook application and these factors will impact how the user's device behaves on the cutover date. No amount of emails will sufficiently cover the range of different mail applications and initial configuration. A common problem is the exchange server successfully redirects the client to the new server (Office 365). Still, at the time of setting up their profile the user set it up manually and their "username" is in DOMAIN\username format, not their UPN so they attempt to authenticate against O365 services but fail. So close!
Other assorted foibles
Send As and Send on Behalf are not the same thing. Read this to save yourself a lot of headaches which you only discover later in the deployment.
Also, read this about free/busy sharing. Just because your delegate mailbox permissions work it doesn't mean free/busy will work. How often do IT guys actually book a meeting room this way? Your users will notice if you are part way through a migration and the resource mailboxes aren't in the same organisation, and the free/busy doesn't work!
Have you tested seamless SSO on all of your browsers? I've had to configure chrome to allow autologon.microsoftazuread-sso.com to the Kerberos delegation and authentication whitelist using their ADMX templates which in itself wasn't straight forward.
What's your network latency like to Office 365? Being connected to a good IX which peers directly with Microsoft means online mode is actually usable in certain circumstances. Check out MegaIX!
Have you trained or provided resources to your helpdesk ahead of time so that they can create remote mailboxes correctly?
Have you thought about conditional access and MFA? Don't wait until there's an incident before deploying MFA or conditional access policies. (And yes, test them properly).
About the Author
Chris joined Data Lync as a Director and shareholder in August 2018 after his business was acquired.
Chris brings experience from a range of sectors including finance, aged care, and professional services organisations.