Record your Classic Engine experience

To verify that your org works the same in Identity Engine as it did in Classic Engine, accurately record all Classic Engine behavior before you upgrade.

Document your policies

Document your Classic Engine policies first. Create at least one test user for each policy.

  1. Record the settings of your Okta sign-on policies.

  2. Sign in to your Okta org with a test user account, and validate that the Okta sign-on policy correctly evaluates the sign-in flow.

  3. Record the settings of your MFA enrollment policies.

  4. Enroll in an MFA factor with a test user account, and validate that the policy correctly evaluates your selection.

  5. Record the settings of your app sign-on policies.

  6. Sign in to your apps with a test user account, and verify that the policies correctly control the access.

  7. Record the settings of your self-service password recovery policy.

  8. Attempt to recover your password with a test user account, and verify that the policy controls the flow.

Prepare your devices

If you actively use Device Trust already, follow these steps:

  1. Turn off Device Trust for mobile devices in your Classic Engine org.

  2. Set up Device Trust for desktop in your Classic Engine org.

  3. Create a runbook of how to reintegrate your MDM vendor.

  4. Create and test app sign-on policies to ensure that test users can sign in with Device Trust for desktop.

If you don't currently use Device Trust for mobile or desktop, you don't need to configure anything in Classic Engine.

Record your Sign-In Widget customizations

Record your Sign-In Widget customizations so that you can recreate them after the upgrade. This is useful if you enabled Self-Service Registration (SSR) in Classic Engine.

Okta-hosted Sign-In Widget with no custom domain

This is the most common sign-in experience model. You don't have any customizations that you need to record.

Okta-hosted Sign-In Widget with custom domain

If you use the Okta-hosted Sign-In Widget with a custom domain, your sign-in page may be customized with cascading styles and JavaScript. Review JavaScript for deprecated capabilities or functionality that may be impacted. See Upgrade your Sign-In Widget.

  1. Create an upgrade runbook. Document all styling changes:

    • Reordering or visual changes that extend beyond the core branding options

    • JavaScript wrap/extensions to the Sign-In Widget (App context, view detection)

    • Overriding default flow changes

  2. Optional. If you don't have a Preview environment, use tenant provisioning to create an Identity Engine sandbox (you can also do this through the Developer Sign-Up page). Copy your Okta-hosted Sign-In Widget to the sandbox.

Embedded Sign-In Widget

If your org embeds the Sign-In Widget into an application with the registration feature enabled, you can't upgrade to Identity Engine with it. Upgrade to version 5.11.0 of the Sign-In Widget and then enable the interaction code as your grant type.

If you don't know where you Sign-In Widget is embedded, you can search with the CORS filter.

  1. In the Admin Console, go to SecurityAPI.

  2. In the Trusted Origins tab, select the CORS filter.

  3. Review the Origin URLs column to determine where your Sign-In Widget is hosted (there can be multiple instances).

Next steps

Schedule your upgrade

Test the upgrade in Identity Engine