Post-upgrade validation tests
Validation tests ensure that your org performs as expected in Identity Engine.
These are the same tests that you performed in a Preview environment before your upgrade. If your Preview environment matches your Production environment (recommended), these tests should yield the same results.
After you upgrade to Identity Engine, policy behavior should be the same as your initial validation tests in Preview.
- Validate that the global session policy correctly evaluates your test users. Your Classic Engine policies migrate with two new default settings. See Okta sign-on policies.
- Validate that the authenticator enrollment policy correctly evaluates your test users. Your Classic Engine policies don't change during migration, but some authenticator behavior does. See MFA enrollment policy.
- Validate that the authentication policy correctly evaluates your test users. Your Classic Engine app sign-on policies migrate with a few conditions. See App sign-on policy migration.
- Validate that self-service password recovery works for your test users. See Password reset and account recovery.
In Identity Engine, you must use Okta Verify to secure your mobile and desktop devices.
If you used Device Trust in Classic Engine, you should have turned off Device Trust for mobile devices and set up Device Trust for Desktop before the upgrade. In Identity Engine, test the authentication policies that let users sign in with Device Trust for Desktop.
If you didn't use Device Trust in Classic Engine, you should have turned off Device Trust for mobile devices before the upgrade. In Identity Engine, set up Device Trust and then test the authentication policies.
See Devices and From Device Trust to Okta FastPass.
Okta SDKs and third-party tools
If you use Okta SDKs or third-party tools, ensure that they work in Identity Engine after you upgrade. Refer to Okta Developer Documentation for Okta deployment models and SDKs and sample apps.
After you upgrade to Identity Engine, sign in as a test user and note the sign-in flow and password recovery behavior. Let your users know about the changes in the sign-in, sign-up, and recovery flows.
They may be prompted for their username first, instead of a username and password. See Sign-In Widget.
During sign-up flows, they may be prompted for optional security methods, depending on your profile enrollment policies.
The password recovery link is only presented on the page for password entry. Users can't reset their password from the username prompt.
Their email messages may contain email message links (including the URL for email magic link). See Email templates.