Hi! The answer is absolutely yes! Take care to understand that the applications, once migrated to Okta, will be used by Okta only meaning your users will need to exist their (or at least have an account). But yes, lets say your current solution today is Azure with 10 apps, you could have a pilot group with accounts in Okta utilize these test applications there, say 1-2 at a time.

Whether an application supports concurrent login from two IdP(s) is probably something that will be up to that app, and may not always be supported. One thing that I like to do is use non-production tenants of these apps whenever possible for testing before migration to the full production environment.

You could request an Okta Preview (non-production) and non production of the app you are integrating with, and this should not interfere with your production workloads at all. Once you are happy with your testing and are ready to migrate, you would simply communicate to your users and schedule the downtime as you move from Azure (or anything else) to Okta.

But ultimately, how you do the above is entirely up to you and how you want to manage the migration. From a technical perspective, using a non-prod environment for both Okta and the app is best, then you can migrate to the prod org. Because even your "prod" org is not in widespread use, you could easily do your testing there as well as you get it ready for the full blown migration. I hope this helps! Please if you have any further questions or concerns ask away below! Thanks!

Thanks Don. One thing I am still unclear: Can we access the applications in parallel? From Okta just for testing purpose and outside Okta to continue to do production work?

​

I understand we need to connect Active Directory to Okta, create test group and add 10-15 users to the test group and then assign applications to them in Okta. The thing I am trying to understand is can these 10-15 test users and other users (non-test) will continue to access applications outside okta? All in parallel?

Thanks

Hi Rollers. The straight answer is that this is not an Okta question. It is the application ( SP ) side that determines how SSO is implemented. If the SSO configuration in your target applications is enabled for everyone when applied, then you will block access to users that are not onboarded to Okta. So you need to look at the apps you are looking to onboard, and check their SSO intructions to determine whether SSO can be enabled as optional, or for a limited set of users or sometimes they allow a 'test' mode. I've just done exactly this for a large customer with a large application estate for a PoC. Found candidates that supported optional SSO ( through a variety of means ) and then onboarded those.

The way I usually handle that is wrap it in some change control processes. Just some basics. Have a change window in place. Make sure you know the backout procedure to unconfigure SSO from the target application. Communicate out to your users that there's a change coming. Have 3 test users ready to go.

Then hit the button on the SP to enforce SSO via Okta.

Have the test users test.

If it works for them, it'll work for everyone. You're now in fix forward mode as SSO is working, but you may have individuals that have an issue that need hand holding.

If it doesn't work, you have the change window to correct it before you need to roll back. If you roll back, use your instructions.

Other things that help.

• Depending on the service, get a dev/test tenant from the vendor and perform the SSO change there first before production.
• Enabling SSO doesn't impact all users immediately. Users with an existing session with the target services will remain logged on and won't see the change until they are next forced to authenticate. So during your change window, most people won't be aware of anything happening so there's no system wide outage you need to consider.

Hope that helps.