Office 365 SSO external DNS redirect

Your custom application must be registered with Azure AD as a Custom Application as per the process flow on this online guide. There are a couple of options to integrate your custom application - you can do password-based or federation-based.

If your app will support SAML-based authentication then you would use federation-based which isn't covered in the above guide, but has some more detail on MSDN in a couple of places.

Note that you must be subscribed to the Basic or Premium Azure AD tiers to access this feature.

Based on the information you have provided, here's the best scenarios to proceed to proceed with.

User Authentication: there are 3 models that you can work with in here, which are:

1. Users in Office 365 (Cloud Accounts): user management will happen entirely in the cloud. You can create users, disable, reset passwords and configure all setup using the Office 365 portal, you don't need a local AD for this, obviously this option won't work with your environment since you already have a local AD with Exchange and you want to keep user management controlled locally in AD.
2. Users in AD, with one way sync to Office 365 (Semi-Federated Accounts): this module will allow you to create accounts and do the entire user management on your in-premises AD servers, you will install and a tool called "DirSync" or the newer version "ADD Sync" to create a copy of the users from your local AD to the cloud, the tools have the option to also synchronize the user account passwords from local AD to the cloud, which will allow your users to login to local resources in the domain and to Office 365 using the same user credentials, creating a semi-SSO experience, users will need to provide their username and password when accessing resources on Office 365 and user authentication/verification will happen on the cloud side. the requirements for this module is to install the previously mentioned tools in any server in your local network, no need for ADFS or ADFS Proxy, you should go with this option since it's the easiest to implement and support.
3. Users in AD, with two way sync with Office 365 (Full-Federated Accounts): this is the most advanced option of the three, this option utilizes all the setup from the previous option "Users in AD with one way sync to Office 365" plus it adds the ability to force user authentication/verification will happen on your local AD servers using ADFS and ADFS proxy server, you will need to have a deployment of ADFS/ADFS proxy and AAD Sync either on your local network or on an Azure hybrid network, you will get a full SSO experience with this option as users in the domain will be able to access the Office 365 without the need to provide a username and password, I wouldn't recommend going with this option since installing, configuring and supporting it is an IT horror story.

You have tons of information to read here for further referencing: https://blogs.office.com/2014/05/13/choosing-a-sign-in-model-for-office-365/

Email migration: since you have Exchange 2010 in the network, here are the supported way to migrate your emails:

1. Cutover email migration: using the Office 365 portal, you create a migration batch job, the job will search for the user mailboxes using Exchange Autodiscover, it will access the user mailboxes on the local Exchange server and start copying the mailbox content to the cloud, al this can happen while the user is still using the mailbox on the local server. Once all the emails have copied successfully to the cloud, you will stop the migration batch and change the DNS records so new emails/Autodiscover point to the cloud mail server instead of the one in the local network, users will need to be reconfigured in order to access the new server, and you may remove the user mailboxes from the local server since it's not being used anymore. I personally prefer that you use this option.
2. Bulk Export/Import .pst files on behalf of users: you will use a tool to export the user mailboxes into a .pst files, you can save those files to a disk and send it to Microsoft for importing, or you save the .pst files into a local folder and then import them to Office 365 your self using a migration wizard from Office 365, I wouldn't bother with this option unless you have relatively small mail box sizes.
3. Ask your users to perform the .pst import/export: in a perfect world, you may ask your user to export their mailboxes into a .pst file, save the files locally on their machines, configure Outlook to work with the new mailbox on the cloud, import the .pst file from their machines to the new mailbox, I'd avoid this option at all costs because... well... end users.

You can find further information for the email migration here: https://support.office.com/en-us/article/Ways-to-migrate-multiple-email-accounts-to-Office-365-0a4913fe-60fb-498f-9155-a86516418842

If you select option 2 for the authentication and option 1 for the emails, you won't need ADFS or a certificate to complete the migration, end users will only be effected during the final stages of the cutover migration.

Hope this helps.

EDIT:

Your migration steps should be easy, follow these tips:

1. Add all the accepted domains to the Office 365 portal and verify them.
2. User the Microsoft IDFix tool to insure that your local accounts formatting and data are compatible with the Office 365.
3. Create the ADFS integration (I still would go with DirSync only because you can install it anywhere and you don't need hardware for it, it would still run the same as ADFS without the SSO auto-login, but seems ADFS is a requirement in your case)
4. Create a federation trust between your local mail server and Office 365.
5. (Optional) Redirect incoming email to the cloud first for better antivirus/spam handling.
6. Assign licenses to your users whom you want to move to Office 365.
7. Start moving the users for each department as you see fit.
8. Once all the user accounts have been moved to the cloud, remove the federation trust between Office 365 and your local mail server, keep ADFS or DirSync though you will always need those to be present.
9. Remove the local mail server as you see fit, Virtualize and keep it turned off you have the option.