This Series is authored by Ruchir Parikh.

Welcome back to our “Demystifying Upgrading to OIE Series”!. 

If you missed the first episode, you can access it here.

In this series of 4 episodes, we will take a fictitious company and walk through the steps of the Okta Identity Engine (OIE) upgrade, offering tips and tricks along the way.

In this second episode, we will review the upgrade process in more detail and look into what can happen when the eligibility process is run on your org, and what you might have to deal with. We will also recommend best practices for the upgrade.

It’s Upgrade time, or is it really?

When you launch the in-app Okta Classic to OIE upgrade self-service tool (that we introduced in Episode #1), the utility will first run a set of eligibility checks on your Org. There are four types of issues, also called ‘blockers’ that might be discovered during the eligibility process, which are organized into four buckets: consent required, customer configuration required, customer feature required & Okta assistance required.

Okta highly recommends that customers configure the same blockers that exist on their Production tenant in an Okta Preview environment on Okta Classic and upgrade to OIE first to ensure there are no unexpected issues post-OIE upgrade in Production. 

Let’s learn a little bit more about these four categories.

Consent Required. Blockers in this bucket do not require customers to make any configuration changes to upgrade. However, end-users, administrators, customizations, and/or third-party tools linked to Okta may experience a change in experience or stop working post-OIE upgrade. 

Customer Configuration Required. Blockers in this bucket require customers to make configuration changes to their tenant before they can schedule their OIE upgrade.

Customer Feature Required. Blockers in this bucket require customers to enable or disable a feature in your tenant before the tenant can schedule the OIE upgrade. The features in this bucket can be self-service either via the OIE upgrade tooling to disable features or by enabling a feature in the Okta Admin Console (Settings → Features).

Okta Assistance Required. Blockers in this bucket require customers to contact their Okta account team or Okta Support to enable or disable a feature. Once Okta has enabled or disabled the feature, the tenant will be eligible to schedule the OIE upgrade.

Example of a simple “Consent Required” blocker

Preparing for the Upgrade 

Okta highly recommends that customers configure the same blockers that exist on their Production tenant in an Okta Preview environment on Okta Classic to ensure there are no unexpected issues post-OIE upgrade in Production. 

Next, we also recommend that customers test all their use cases in Okta Preview Classic before upgrading their Okta Production environment. Configuring your Okta Preview Classic environment to be as close to how it is in Okta Production will ensure customers can catch any issues in Okta Preview versus having to discover them in Production, resulting in possible downtime and rolling back to Okta Classic. 

Once you have both Preview and Production ready, some configurations need to be copied between preview and Production, you can see the details in Appendix 1 of this post.

Before upgrading your orgs, there are a couple of best practices you might want to follow, First, review the Feature Changes documentation that outlines the difference between Okta Classic and OIE. Second, you will need a test plan based on the critical use cases currently configured in Okta Classic. You can find a generic test plan in Okta’s documentation that you can customize to best fit your needs.

Now, you are pretty much ready to upgrade!

Before we execute the upgrade, here are a few more considerations:

1. This might sound obvious, but learn & understand OIE fundamentals! Here are pointers to a set of valuable resources:
   1. Watch replays of our OIE Upgrade Webinars/Meetups on our YouTube Playlist
   2. Access the OIE Upgrade Hub
2. Based on our experience, there are a few common blockers, we are discussing these in the context of Atko HytekSys in the Appendix 2 of this blog
3. If you have deployed Device Trust in Okta Classic… don’t start the upgrade right now and watch Episode #3, there are a lot of new exciting features and capabilities that we call “Device Context” in OIE
4. Similarly, if you have performed customization of your tenant, please watch episode #4, we cover common customizations, still in the context of our example Akto HytekSys.

Upgrading to your Orgs to OIE

Now that you understand the process and have done the preparation work, you can run the OIE upgrade checklist!

From our experience, a typical checklist is outlined below:

Finally, informing your end-users is a good idea, even if the impact to them is minimal: you might want to create a End-user/company-wide communication plan for the OIE upgrade. The OIE upgrade does not require downtime and should be fairly transparent to end-users during and after the upgrade. However, communicating a change window company-wide may be prudent to prevent overwhelming internal HelpDesk teams. 

One step closer…

Resolving the blockers and understanding the consent is a key step in your upgrade journey, Atko HytekSys is now well positioned to upgrade! For most organizations, these two episodes should cover almost all you need to upgrade to OIE.

In the next 2 episodes, we will cover two additional common topics: device trust and customizations.

Contributors:

Brent Arrington 

Dimitri Volkmann