There is no data migration needed unless you're consolidating tenants. If not, here is what i've done for something similar in the past:

• Ensure all users exist in the new Okta org, lets say Okta Org 1 for this example
• Break API integration in Okta Org 2 for the O365 tenant (if using). This does NOT affect SSO but will affect provisioning, etc. We deselect the deactivate account checkbox as a safety. This is the equivalent of breaking dirsync and Microsoft has some timelines that need to be adhered to. NOTE - All objects will appear as cloud objects in the O365 tenant.
• Once API integration is broken and the appropriate amount of time has passed, move the O365 app from WS-FED to SWA in Okta Org 2. Note - this will break SSO.
• In Okta Org 1, create a new O365 app, configuring WS-FED and API integration as needed.
• Add users to the new app, etc.

These steps are high level but should be a good place to start. LMK if this helps.

@Rocky (Customer)​ Here are steps I outlined in an older post :

Here were steps we followed (hopefully this will help others):

* 4-5 days before migration, disable dirsync in the tenant via PS and remove the API config for the O365 app in Okta

* Verify the above is complete by running the following commands. NOTES - it must return disabled, not pending disabled

(Get-MSOLCompanyInformation).DirectorySynchronizationStatus

(Get-MsolCompanyInformation | select DisplayName,DirectorySynchronizationEnabled,DirSyncServiceAccount,LastDirSyncTime)

* Once the above is verified, test that you can manually change objects in the O365 tenant.