The engine sits under every sign-in. Changing it is changing the foundation of your front door.

Every time someone signs in through Okta, an engine decides what happens: which questions to ask, in what order, which proof is enough, and when to let the person in. The Classic Engine does this with one fixed style of flow. The Identity Engine does it with a more adaptable one, where each step can respond to what is known about the person and their situation. Newer Okta capabilities are built on the Identity Engine, which is why organizations move.

Reasons organizations migrate

• Access to newer capabilities: many newer features, especially around stronger sign-in and finer policies, are built for the Identity Engine.
• More precise policies: rules can be tied to applications and conditions with more detail.
• Better sign-in experiences: flows can adapt step by step, including options that reduce reliance on passwords.
• Long-term support: staying on the older engine can mean falling behind as the platform moves forward.
• Consistency: one engine across the organization is easier to explain, test, and secure.

Why it needs care

The engine touches everything. Custom sign-in pages may behave differently. Code that talked to older interfaces may need updates. Policies that looked equivalent may behave slightly differently. Users may see new screens. Support staff must learn new patterns. A migration done in haste can lock people out, break applications, or silently weaken security. A migration done with care is mostly invisible to users and a quiet improvement for administrators.

flowchart LR
    CL["Classic Engine
organization"] --> SV["Survey and plan"]
    SV --> TS["Test in safe place"]
    TS --> ST["Staged rollout"]
    ST --> IE["Identity Engine
organization"]
    IE --> OP["Operate and improve"]
    

Figure 1 shows the journey in five stages. Most of the effort and most of the safety lie in the first three, long before any user sees a change.

What success looks like

A successful migration is one that most users barely notice. Sign-in still works, applications still open, and nobody is locked out. Behind the scenes, policies are cleaner and better documented, administrators understand the new structure, and the organization is ready to adopt newer capabilities without another large project. Write down three or four sentences describing success in your own words, and share them with your sponsor so that everyone judges the project by the same yardstick, not by feelings after the first awkward day.

A small vocabulary unlocks the rest of the guide.

Engine versus version

The word engine here does not mean a software version number. It describes the underlying approach used to run authentication and policies. Both older and newer organizations receive regular updates, but the engine determines which family of capabilities and behaviours your organization uses.

The big ideas in one breath

The older engine handled sign-in as a fairly fixed sequence. The newer engine treats sign-in as a conversation: it asks for a step, looks at the answer and the context, and decides what to ask next. Policies in the newer engine are organized differently, with more separation between rules about how people prove themselves and rules about how applications grant access.

flowchart TD
    subgraph CLS["Classic style"]
      C1["Fixed sequence of steps"] --> C2["Broad policies"]
    end
    subgraph IDE["Identity Engine style"]
      I1["Step-by-step conversation"] --> I2["Detailed policies per application"]
    end
    CLS -.->|"migration"| IDE
    

Figure 2 contrasts the two styles. The migration is the work of carrying your existing intentions from the left style into the right.

Why vocabulary matters in a project

Misunderstandings in migration projects often come from people using the same word differently. One person says policy and means a single rule, another means the whole set. One says migration and means the technical switch, another means the entire project. Agree on a short glossary at the start, publish it where the team can see it, and correct the language gently in meetings. Shared words make plans, status reports, and risk discussions much easier to follow.

Knowing the boundaries of the change keeps the project calm.

Many fears about migration come from not knowing how much will change. The honest answer is that your users, applications, groups, and most directory connections stay where they are. What changes is how sign-in and access decisions are made and configured.

Where the risk really lives

The people and applications are the easy part. The risk lives in the places where behaviour is custom: tailored sign-in pages, scripts that parse page contents, integrations that call older interfaces, and unusual policy combinations built up over the years. A good survey finds these early.

Different surfaces, same goal

Think of the migration as rewriting the same set of house rules in a new rulebook format. The rules you intended remain; the language and structure of the rulebook differ. Your job is to confirm that the new rulebook produces the same decisions where you want sameness, and better decisions where you want improvement.

flowchart LR
    SAME["Stays: users, groups, apps,
directories"] --> ORG["Your organization"]
    CHG["Changes: policy structure,
widget behaviour, flows"] --> ORG
    RISK["Risk lives in custom code,
pages, unusual policies"] --> ORG
    

Figure 3 shows three groups. Your plan should spend the most attention on the third.

Questions to ask your Okta contacts

• Which engine is our organization on today, and what is the supported path forward?
• Are there features we use that behave differently or are unavailable after the move?
• What tools or guidance are provided for planning and checking the upgrade?
• What can be rehearsed in advance, and what can be reversed afterwards?
• Are there dates or support timelines we should plan around?

Write down the answers with the date and the name of the person who gave them. Because details change, a dated answer is more useful than a vague memory.

The most visible difference is the shape of the sign-in journey.

In the older approach, a sign-in generally ran through a set order: collect the username and password, then maybe a second factor, then done. Different situations needed different pages and configurations, and customization often meant editing page behaviour directly.

In the newer approach, sign-in is a series of small steps. At each step, the engine looks at what it knows and decides what to do next. It can ask for a different proof depending on risk, offer choices of authenticator, or skip steps that are not needed. Because steps are modular, the experience can be more personal and often smoother.

Practical effects users and admins may notice

• Authenticator choice: users may be offered options during sign-in and enrollment rather than a fixed single path.
• Passwordless options: some journeys can reduce or remove the password, depending on configuration.
• Recovery: password reset and account unlock follow the new engine’s flow and may include different checks.
• Enrollment: setting up new authenticators is guided differently.
• Error messages and screens: wording and layout may differ from what helpdesk scripts describe.

Why helpdesk readiness matters

The first people to feel any change are your support staff, because users call them. If screenshots, scripts, and guides still describe the old screens, confusion multiplies. Updating support materials before users see anything is one of the cheapest, most effective parts of the plan.

sequenceDiagram
    participant U as User
    participant E as Identity Engine
    participant P as Policy
    U->>E: Starts sign-in
    E->>P: What is required now?
    P-->>E: Step one requirement
    E->>U: Ask for first proof
    U->>E: Provides proof
    E->>P: Evaluate again with new knowledge
    P-->>E: Next requirement or done
    E->>U: Next step or access granted
    

Figure 4 shows the rhythm of the newer engine: ask, answer, re-evaluate. This is why policy design matters even more, since the engine consults it repeatedly during one sign-in.

Walking through a typical journey

Picture a regular employee opening a business application on a laptop at home. Under the older engine, they might see a username and password box, then a prompt on their phone, then the application. Under the newer engine, the first screen may simply ask who they are, then offer the best available way to prove it, perhaps a phone prompt or a security key, and only ask for more if the situation looks unusual. The destination is the same; the path is shorter or longer depending on what the system learns along the way. Documenting a few such journeys with screenshots, before and after, is the best material for training and for testing.

Policies are the heart of the migration, and the structure differs between engines.

In the older engine, a small number of broad policy types governed sign-in and access, and a lot of behaviour was tied together. In the newer engine, rules are separated more cleanly: one set of rules governs how people may authenticate in general, another set governs access to each application, and others cover enrollment and recovery. This separation gives finer control but also means that one old rule may become several new ones.

One old rule, several new rules

Suppose an old policy said, “Require a second factor unless the user is on the office network.” In the new model this intent might be expressed in a rule tied to a specific application or group, with conditions about network, device, and risk, and priorities among rules. Translating means understanding the intent, not copying the words.

Order and priority

Rules in both models are evaluated in order, with the first matching rule applying and a catch-all rule handling everything else. When translating, take extra care with the order. A rule placed too high can swallow cases you meant for a rule beneath it, and a missing catch-all can leave a hole.

Opportunity to simplify

Years of accumulated rules often contain duplicates, exceptions nobody remembers, and rules for applications long retired. The migration is a rare moment to clean house. Remove what has no purpose, merge what overlaps, and write down the reason for each remaining rule.

flowchart TD
    OLD["Old broad policy"] --> INT["Extract intent"]
    INT --> NEW1["Authentication rule"]
    INT --> NEW2["Application access rule"]
    INT --> NEW3["Enrollment rule"]
    INT --> NEW4["Recovery rule"]
    NEW1 --> CHK["Compare behaviour
old versus new"]
    NEW2 --> CHK
    NEW3 --> CHK
    NEW4 --> CHK
    

Figure 5 shows translation as a split. The intent is extracted once, expressed in several places, and checked as a group.

A worked translation in words

Suppose the old rules said: administrators must always use a security key; staff on the office network need only a password; everyone else needs a phone prompt in addition to the password. To translate, list the groups involved, decide which application or sign-in rule each applies to, and order them so that the administrator rule sits first, the office rule second, and the general rule last as the catch-all. Then test one administrator at the office, one regular user at the office, one regular user at home, and one stranger. If the administrator at the office is let in with only a password, the order is wrong. This small exercise shows why intent, order, and negative tests matter.

Users carry their proofs with them. Making sure they still work, and are used well, is central.

An authenticator is the thing a person uses to prove who they are: a secret they know, a device they hold, or a trait they have. Your users have already enrolled authenticators under the older engine. After migration they should be able to keep using them, though the way they are configured, offered, and combined can change.

Questions about authenticators

• Which authenticators are in use today, and how many users rely on each?
• Do all of them continue to work after the move, and in which situations?
• Which weak or outdated ones would you like to phase out?
• Do you want to introduce stronger or passwordless options?
• How will new users enroll, and what will the screens look like?
• What is the fallback if a user loses their device?

An opportunity, handled carefully

Migration is a natural moment to improve authentication, but combining too many changes makes problems hard to diagnose. A good rule is to migrate first with equivalent behaviour, confirm stability, and then introduce improvements in separate, clearly communicated steps.

Plan for lost devices

Every change in authentication increases the chance that someone will be stuck. Make sure recovery paths exist and have been tested, and that helpdesk staff can verify identity safely and quickly. Test the recovery flow as a user would see it, not just as an administrator.

flowchart TD
    A["Inventory authenticators in use"] --> B["Confirm each works after migration"]
    B --> C["Decide what to phase out"]
    C --> D["Plan new options separately"]
    D --> E["Test enrollment and recovery as users"]
    

Figure 6 puts improvements after equivalence. First make sure nobody is worse off, then make them better.

Retiring weak authenticators

Some organizations still rely on authenticators that are easier to attack, such as codes sent by text message or knowledge questions. A migration is a convenient time to measure how many people use them and to plan a gradual retirement: announce the date, offer stronger alternatives, help those who need assistance, and only then switch the old option off. Doing this after migration, as a separate step, keeps the two changes from confusing each other.

The sign-in box is the part of the system every user sees. Custom pages are among the biggest migration risks.

Organizations often customize the sign-in experience: their logo, colours, wording, and sometimes much deeper changes using their own scripts and styles. Plain branding such as logos and colours usually carries across without trouble. Deep customization, especially anything that relies on the structure or behaviour of the older sign-in widget, is more fragile.

Levels of customization

Test every customization

List every place where you changed the sign-in experience. For each, ask whether it depends on how the older widget behaved. Then test it in the new engine in a rehearsal organization. Where it breaks, decide whether to update it, replace it with a supported setting, or remove it.

Embedded sign-in

If your own application embeds the Okta sign-in box, it uses a particular version of the widget and a particular style of flow. The newer engine may need a newer widget version and code that handles multi-step flows. Treat this as a development project with its own testing, not a configuration switch.

flowchart LR
    BR["Branding only"] --> OK1["Low risk"]
    WD["Wording changes"] --> OK2["Review screens"]
    SC["Page scripts"] --> HI1["Retest or replace"]
    FC["Fully custom page"] --> HI2["Redesign for steps"]
    EM["Embedded widget"] --> HI3["Update and test"]
    

Figure 7 shows risk rising with depth of customization. The cheapest path is to move toward supported settings wherever you can.

Accessibility and device variety

Sign-in screens must work for everyone, including people who use screen readers, keyboard navigation, magnification, or older browsers and devices. Test the new screens with these tools and with the variety of devices your people really use, such as shared workstations, tablets, and phones. A flow that is elegant on a new laptop but unusable with a screen reader is not ready, no matter how well the policy rules are written.

Anything you built around Okta may carry assumptions about the old engine.

Over the years, teams build helpers around Okta: scripts that call its interfaces, hooks that run at certain moments, automations that react to events, and connections to other tools. Most of these will keep working, because the interfaces for managing users and groups are stable. But some depend on details of the older flows, and these need attention.

Categories to review

• Management scripts: programs that create, update, or suspend users and groups. Usually unaffected, but test.
• Authentication-related programs: anything that signs users in or checks sessions programmatically. Likely affected.
• Hooks: code that Okta calls at certain moments, such as before a token is issued. Review their inputs and timing.
• Event-driven automation: reactions to log events. Check that the events and fields you rely on still appear as expected.
• Third-party tools: integrations from other vendors that assume particular behaviour.
• Monitoring: dashboards and alerts built on log event patterns, which may change.

Make an inventory with owners

Create a list of every custom item with a named owner, what it does, which Okta interfaces it uses, and how to test it. Items without owners are the ones that break unnoticed. Ask each owner to confirm compatibility, or to retest in the rehearsal organization.

Why monitoring and detections deserve special mention

Security detections often match on specific event types and fields. If the new engine produces different or additional events during sign-in, a detection rule may stop firing, or start firing too often. Compare event output from the two engines for the same journeys, and adjust rules before cutover.

flowchart TD
    INV["Inventory custom items"] --> OWN["Assign owners"]
    OWN --> RT["Retest in rehearsal org"]
    RT --> DEC{"Works as is?"}
    DEC -->|"yes"| KEEP["Keep"]
    DEC -->|"no"| UPD["Update or replace"]
    UPD --> RT
    

Figure 8 shows a loop. Items that fail are fixed and retested until they pass.

Using the migration to reduce customization

Every custom script is something you must maintain through every future change. Ask of each one whether a supported setting now achieves the same result. Many old customizations were workarounds for missing features that now exist. Replacing a workaround with a supported setting shrinks the maintenance burden, lowers risk at the next upgrade, and often improves the user experience. Where a customization is truly needed, document why, who owns it, and how to test it.

Applications connect to Okta in several standard ways. Most keep working; a few need a check.

Applications connect through well-known standards for single sign-on, such as those based on tokens and on signed assertions. Because these standards are stable, many applications continue working without change. The things to check are the details: how applications ask for sign-in, which extra parameters they send, how they handle multi-step flows, and whether they depend on older behaviour.

Application groups by risk

Policy attachment per application

The newer model attaches access rules to each application. During migration, confirm that every application has a rule that matches what it had before, and that none is left with an accidental default that is too open or too strict.

Test with real journeys

For each group, pick representative applications and test full journeys: first sign-in of the day, return visits, step-up for sensitive actions, sign-out, and session timeouts. Include the user types that matter, such as administrators, contractors, and remote workers.

flowchart LR
    APPS["All applications"] --> G1["Standard web"]
    APPS --> G2["Mobile and desktop"]
    APPS --> G3["Embedded sign-in"]
    APPS --> G4["Legacy"]
    APPS --> G5["Machine to machine"]
    G1 --> T["Test representative sample"]
    G2 --> T
    G3 --> T
    G4 --> T
    G5 --> T
    

Figure 9 shows that you do not need to test every application equally. Grouping lets you test thoroughly where behaviour differs and lightly where it is the same.

Sessions and sign-out behaviour

Applications and Okta each keep their own notion of a session, and the way they interact can surprise people. Test how long a user stays signed in, what happens when they close the browser, how sign-out in one application affects others, and when sensitive actions ask for fresh proof. Compare with your benchmark. A small difference in session length may be harmless for one team and a serious complaint for another, so check the expectations of each group.

Users arrive and leave through connections that should keep working throughout.

Your users probably come from a directory or a human resources system and flow out to applications through provisioning connections. These connections are generally independent of the sign-in engine, so they should continue to work. Even so, verify that nothing in the lifecycle chain depends on older sign-in behaviour, such as first-login steps, activation emails, or password setup flows.

Points to verify

• Activation: how new users receive and complete their first sign-in and enrollment.
• Password sync and delegated authentication: if your directory checks passwords, confirm the agent connection works under the new engine.
• Provisioning to applications: create, update, and deactivate operations still flow correctly.
• Lifecycle emails and templates: message wording and links may need review.
• Joiner, mover, leaver processes: rehearse each end to end.

Avoid combining migrations

It is tempting to modernize directories, provisioning, and the engine all at once. Doing so makes problems hard to pin down. Where possible, change one layer at a time and let each settle.

sequenceDiagram
    participant HR as HR system
    participant O as Okta
    participant A as Application
    participant N as New user
    HR->>O: New person record
    O->>A: Provision account
    O->>N: Activation message
    N->>O: First sign-in and enrollment
    O->>A: Access granted
    

Figure 10 reminds us that the engine matters mostly at the point where a human meets the system, the first sign-in and enrollment. Rehearse that step carefully.

Service accounts and automation identities

Not every identity is a person. Programs and integrations use accounts or credentials of their own, and they are easy to forget during a sign-in engine change. List them, record what they do and who owns them, and test that they still authenticate and act as expected in the rehearsal organization. A forgotten automation that quietly stops working may not be noticed for days, then show up as a puzzling failure far from its cause.

You cannot move what you have not counted. A careful survey is the foundation of a calm migration.

The survey produces a complete picture of your current configuration and its dependencies. It is tedious but valuable, and it often reveals forgotten rules, abandoned integrations, and surprising customizations.

Classify as you count

For each item, label it: keep as is, translate, simplify, retire, or investigate. The “retire” and “simplify” labels shrink the work. The “investigate” label creates tasks for owners to answer questions before the migration begins.

Capture current behaviour as evidence

Record how key journeys behave today: which prompts a typical user sees, how long sessions last, which factors are demanded in which situations. This record becomes the benchmark for checking parity after the move.

flowchart TD
    S["Survey everything"] --> L["Label each item"]
    L --> K["Keep"]
    L --> T["Translate"]
    L --> SI["Simplify"]
    L --> R["Retire"]
    L --> I["Investigate"]
    I --> OW["Owner answers before migration"]
    

Figure 11 shows the survey as a sorting exercise. Many items end up retired or simplified, which is a bonus of the project.

Interviewing the people who know

Configuration screens show what exists, not why. Talk with long-serving administrators, application owners, and helpdesk staff. Ask them which rules are special, which exceptions were granted to whom, and which customizations were added after an incident. These conversations uncover reasons that appear in no document, and they turn potential critics of the project into allies who feel heard.

There are several ways to move. Pick the one that fits your risk appetite and your organization.

Okta provides guidance and tools for upgrading, and your account contacts can describe what is available for your organization. The details vary and change, so confirm them. Regardless of mechanism, the approaches differ in shape.

How to choose

• Size and complexity: large, complex organizations lean toward more rehearsal and staging.
• Customization depth: heavy customization favours careful, longer preparation.
• Risk tolerance: the more critical the sign-in, the more caution.
• Regulatory demands: some environments need formal change control and evidence.
• Resources: a parallel build needs people and time.

Whichever approach you choose, the same principles apply: survey first, rehearse in a safe place, move in small steps, and keep a way back.

quadrantChart
    title Approaches by effort and risk control
    x-axis Low effort --> High effort
    y-axis Low risk control --> High risk control
    quadrant-1 Heavy but safe
    quadrant-2 Efficient and safe
    quadrant-3 Quick but risky
    quadrant-4 Heavy and still risky
    Big bang without rehearsal: [0.15, 0.1]
    In-place after rehearsal: [0.4, 0.7]
    Staged by population: [0.6, 0.85]
    Parallel organization: [0.85, 0.8]
    

Figure 12 compares sample approaches. A leap without rehearsal is cheap but dangerous; a rehearsed, staged move offers strong control at moderate effort.

Deciding the order of waves

Order waves by risk and learning value. Start with people who are technically capable and forgiving, then groups with simple needs, then groups with special devices or rules, and leave the most critical or fragile populations until the process is proven. Avoid scheduling a wave just before a major deadline, a holiday peak, or a period when key staff are away. Publish the wave plan so that managers can prepare their teams and know when to expect questions.

A bird’s-eye view shows the environments, the people, and the controls that make the move safe.

flowchart TD
    PROD["Production
Classic Engine"] --> SURV["Survey and benchmarks"]
    SURV --> REH["Rehearsal org
Identity Engine"]
    REH --> TEST["Journeys, apps, recovery tests"]
    TEST --> CMP["Compare with benchmarks"]
    CMP --> OK{"Parity and approval?"}
    OK -->|"no"| FIX["Adjust configuration"]
    FIX --> REH
    OK -->|"yes"| WAVE["Staged production migration"]
    WAVE --> LIVE["Production on Identity Engine"]
    

Figure 13 shows the central idea: nothing reaches production until the rehearsal loop has produced behaviour that matches your benchmarks and your approvers agree.

Roles in the project

• Sponsor: clears obstacles and sets priorities.
• Project lead: runs the plan and keeps everyone informed.
• Identity engineers: translate configuration and run tests.
• Application owners: confirm their applications work.
• Security: confirms policies are at least as strong, and detections still work.
• Helpdesk: prepares for user questions.
• Communications: tells users what is happening and when.

Governance and evidence

For regulated organizations, treat the migration as a formal change. Keep approvals, test evidence, before-and-after configuration records, and the migration log together in one place. When an auditor later asks how you ensured equivalent controls after the move, you can show the benchmarks, the negative tests, the approvals, and the results, instead of reconstructing the story from memory.

A good rehearsal organization is the single most useful tool in the project.

The rehearsal organization lets you try the new engine with a copy of your real configuration, without risking real users. The more it resembles production, the more trustworthy your tests.

What the rehearsal organization needs

• The same policy intentions: translated into the new model.
• Representative test users: covering administrators, regular staff, contractors, remote workers, and people with different authenticators.
• Test applications: one or more of each integration type.
• Network and device conditions: as close to real as practical.
• The same customizations: branding, page scripts, embedded widgets.
• Log collection: so you can compare events with those from production.

Do not use real user data casually

Test with synthetic accounts wherever possible. If real data is needed, protect it as you would in production and follow your privacy rules. Never treat the rehearsal organization as a place where security is optional.

Write a test script, not just a feeling

For every journey, write a short script: starting state, steps, expected result. Run it against the old behaviour to record the benchmark, and against the rehearsal to compare. Keep the scripts; you will rerun them at every stage.

flowchart LR
    CFG["Copy and translate configuration"] --> USR["Create test users"]
    USR --> APP["Connect test applications"]
    APP --> SCR["Run journey scripts"]
    SCR --> LOG["Collect events and screenshots"]
    LOG --> REV["Review differences"]
    

Figure 14 shows the rehearsal pipeline. Screens and events are collected so that differences can be reviewed calmly afterwards, not argued about from memory.

Keeping the rehearsal faithful

A rehearsal organization drifts away from production as people change settings in one place and forget the other. Keep a simple record of every production change during the project and mirror it in the rehearsal. Before each major test run, compare the two configurations and note any differences. A rehearsal that no longer matches production gives false comfort, which is worse than no rehearsal at all.

Two kinds of tests answer two different questions.

Parity tests ask, “Does the new engine do what the old one did?” Improvement tests ask, “Does the new engine do the better thing we want?” Keep them separate. Prove parity first, so that any later difference can be attributed to a deliberate improvement.

Negative tests matter most

It is easy to test that allowed people get in. It is just as important to test that disallowed people stay out. A translation error that opens a door is far more dangerous than one that closes a door, because nobody complains about an open door.

Define pass and fail in advance

Agree beforehand what counts as acceptable. Is a different screen wording acceptable? Is a slightly different order of prompts acceptable? Is any weaker requirement ever acceptable? Writing these rules down prevents arguments under pressure.

flowchart TD
    P["Parity tests"] --> PASS{"All pass?"}
    PASS -->|"no"| FIXC["Fix translation"]
    FIXC --> P
    PASS -->|"yes"| IMP["Improvement tests
one change at a time"]
    IMP --> GO["Ready for staged rollout"]
    

Figure 15 shows the order of testing. Improvements are layered on top of a verified base.

Handling differences you decide to accept

Not every difference is a defect. A slightly different wording or screen layout may be perfectly acceptable. The key is to decide deliberately: record the difference, explain why it is acceptable, name the approver, and update the helpdesk guide. Unrecorded differences have a habit of becoming mysterious problems months later, when nobody remembers that they were intended.

People are part of the system. A well-informed user is a calm user.

Even the smoothest technical migration can feel chaotic if users, managers, and support staff are surprised. Communication is not an extra; it is half the work.

Audiences and what each needs

• Executives: why we are doing it, the risk, the timeline, and the benefit.
• Application owners: what to test, by when, and who to contact.
• Helpdesk: new screens, new flows, common problems, and escalation paths, well before users see anything.
• All users: what will look different, when, and what to do if something goes wrong.
• Administrators: the new console locations and concepts.
• Auditors and compliance: what is changing and how evidence is preserved.

Make messages short and concrete

Say what will be different, with a picture if possible, and name a place to get help. Avoid technical words that users do not use. Send reminders close to the date, and a thank-you afterwards.

Pilot with friendly users

Begin with a group who will tolerate bumps and give honest feedback, such as the IT department and enthusiastic volunteers. Their experience refines the guides and finds problems before the wider population arrives.

gantt
    title Example communication timeline
    dateFormat YYYY-MM-DD
    axisFormat %d %b
    section Leaders and owners
    Briefings and test requests :a1, 2026-11-02, 10d
    section Helpdesk
    Training and updated guides :a2, 2026-11-09, 14d
    section Pilot users
    Pilot notice and feedback :a3, 2026-11-23, 14d
    section All users
    Notice, reminders, support :a4, 2026-12-07, 21d
    

Figure 16 shows an illustrative order. Those who answer questions are informed before those who ask them.

Listening after launch

After each wave, ask users how it went. A short survey, a feedback channel, and conversations with team leads can reveal problems that numbers miss, such as confusing wording or an awkward step on a particular device. Share what you learned and what you changed. People who see that their feedback leads to fixes become patient supporters of the project.

Hope is not a plan. Know exactly how you would step back.

Every change should have a way back, or at least a way to limit damage. How easy rollback is depends on your approach and on what Okta supports for your organization, so ask early and in detail. Some approaches are not easily reversible once complete; you must know which phases are one-way doors and treat them with extra caution.

Questions to answer before cutover

• Which steps are reversible and which are not?
• What is the maximum time we can run in a degraded state?
• Who decides to roll back, and by what signals?
• What is the rollback procedure, and has it been rehearsed?
• Do we have emergency access for administrators if sign-in breaks?
• How will we communicate if we roll back?

Emergency access

Make sure at least a couple of administrator accounts can recover access even if normal flows misbehave, protected carefully and tested. A migration that locks administrators out of their own platform becomes a crisis within minutes.

Go and no-go criteria

Agree beforehand on the signals that mean stop: sign-in failure rate above a threshold, a surge of helpdesk calls, a critical application failing, or a security regression. Review them together at each stage gate.

flowchart TD
    GO["Stage change applied"] --> MON["Monitor signals"]
    MON --> D{"Within limits?"}
    D -->|"yes"| NEXT["Proceed to next stage"]
    D -->|"no"| HOLD["Pause and diagnose"]
    HOLD --> RB{"Fixable quickly?"}
    RB -->|"yes"| GO
    RB -->|"no"| BACK["Roll back and communicate"]
    

Figure 17 shows that decisions are made against agreed limits, not in the heat of the moment.

Communicating during trouble

If something goes wrong, speed and honesty matter more than polish. Prepare templates in advance for a short notice saying what is affected, what users should do, and when the next update will come. Decide who approves messages so that they are not delayed by debate. Users forgive problems far more readily than silence.

A sensible order of work, from first questions to a settled new platform.

Early traps

• Starting translation before the survey is complete.
• Skipping the rehearsal organization to save time.
• Combining the migration with several other large changes.
• Forgetting the helpdesk until the week before.
• Having no emergency administrator access.

flowchart LR
    A["Confirm start"] --> B["Team"]
    B --> C["Survey"]
    C --> D["Clean up"]
    D --> E["Benchmarks"]
    E --> F["Rehearsal org"]
    F --> G["Parity tests"]
    G --> H["Prepare people"]
    H --> I["Pilot and stage"]
    I --> J["Stabilize and improve"]
    

Figure 18 summarizes the roadmap. Surveying, rehearsing, and preparing people all happen before any real user is touched.

Estimating time honestly

Teams commonly underestimate the survey and the testing, and overestimate the technical switch. Add time for waiting on application owners, for rework after failed tests, and for training. Include buffers around holidays and peak business periods. Share the estimate as a range with assumptions, and update it openly as you learn. A realistic plan that slips a little is better than an optimistic plan that collapses.

Three short stories show typical migration moments.

Example one: the rule that opened a door

During parity testing, a team translated an old rule saying contractors must always use a second factor. The new rule was written correctly, but it sat below a broader rule that allowed anyone on the office network to sign in with a password alone. A contractor test account on the office network therefore got in without a second factor, which the old engine would never have allowed. The negative test caught it. The team reordered the rules, added a note explaining why contractors sit above the network rule, and added the test to the permanent script so it would never regress.

Example two: the embedded sign-in box

A customer-facing portal embedded the sign-in box and had been unchanged for years. In the rehearsal organization, the old embedded version failed to complete a sign-in because the new flow had an extra step the page did not know how to show. The portal team scheduled a proper update, tested it, and released it ahead of the production migration, so that on migration day the portal worked on both engines. Nobody outside the project noticed.

Example three: the helpdesk surprise

Technically the pilot went perfectly, yet the helpdesk was flooded with calls. The reason: password reset screens had a different layout and a new verification step, and the helpdesk guide still showed the old pictures. The project team paused the next wave, updated the guide with new screenshots, ran a thirty-minute briefing with support staff, and resumed. Calls fell back to normal within a day. The lesson became a standing rule: helpdesk readiness is a gate, not a courtesy.

flowchart TD
    E1["Rule order mistake"] --> R1["Negative test catches it,
rules reordered"]
    E2["Old embedded widget"] --> R2["Portal updated early,
works on both engines"]
    E3["Outdated helpdesk guide"] --> R3["Pause, update, brief, resume"]
    

Figure 19 summarizes the stories. Each problem was found early or handled calmly because the project had gates, rehearsal, and people who were prepared.

What the stories have in common

In each story, the problem was not exotic. A rule in the wrong order, an old widget, and an outdated guide are ordinary matters. What made the difference was that the team had a process designed to find ordinary problems early: negative tests, a rehearsal organization, and gates that include people as well as technology. Dramatic failures are rare; ordinary oversights are common, and a good process is mostly a net for catching them.

A migration must never leave you less safe than before.

During a change, attackers and mistakes both find opportunities. Treat the migration as a security-sensitive project from the start.

Protect against weakening

• Translate at least as strongly: every old requirement must have an equal or stronger new one, verified by negative tests.
• Review default rules: catch-all rules deserve special attention, as defaults can be looser than your intent.
• Watch temporary exceptions: exceptions made to get through the migration often remain forever. Record each with an owner and an expiry date.
• Protect administrators: require strong authentication for everyone who can change policies during the project.

Protect against social engineering

Attackers exploit confusion. Users who expect new screens may accept suspicious prompts. Remind everyone how real messages from your organization look, how to report anything strange, and that helpdesk will never ask for a password. Be especially careful with recovery flows during the rollout, since attackers may pose as users who “lost their device after the migration”.

Protect evidence and monitoring

Keep logging intact and, where possible, store copies of old and new configurations as evidence. Confirm that detections still work. Set up extra alerts for the migration period, such as spikes in recovery requests, sudden policy changes, and unusual administrator activity.

Credentials and secrets

If any integration credentials need to be rotated or re-created as part of the move, handle them in a secrets store, never in tickets or chat, and remove old ones once they are no longer needed.

flowchart LR
    SEC["Safe migration"] --> A["Equal or stronger rules"]
    SEC --> B["Review defaults"]
    SEC --> C["Time-limited exceptions"]
    SEC --> D["Strong admin sign-in"]
    SEC --> E["Phishing awareness"]
    SEC --> F["Extra monitoring"]
    SEC --> G["Careful secrets"]
    

Figure 20 lists the habits. Most are inexpensive; all are easier to start at the beginning than to retrofit.

Reviewing administrator privileges

Migration projects often grant temporary extra privileges to engineers and contractors. Record each grant, set an end date, and review them at every gate. Afterwards, check the list of administrators against the people who truly need the access. Removing unused privileges is a quiet security gain that the project can deliver almost for free.

Measure the migration as you go, so you know it is working.

Pick a handful of measures before you start, record their baseline under the old engine, and watch them through every stage.

Compare old and new

For the same time of day and population, compare measures before and after each wave. Because mornings are busier than afternoons and Mondays differ from Fridays, compare like with like.

Keep a migration log

Record every change, decision, issue, and fix, with times and names. The log helps the team hand over, helps auditors, and becomes a rich source of lessons learned.

flowchart LR
    BL["Baseline under old engine"] --> CMP["Compare after each wave"]
    LIVE["Live measures"] --> CMP
    CMP --> DEC["Decide: proceed, pause, roll back"]
    DEC --> LOGM["Record in migration log"]
    

Figure 21 shows measures as the basis for decisions. Numbers calm debates and justify the next step.

Setting thresholds sensibly

Choose thresholds from your baseline data. If the sign-in success rate is normally very high, a small drop after a wave deserves attention, while a larger normal variation requires wider tolerance. Define one level that means look into it today and another that means stop the rollout now. Agreeing these in advance keeps decisions calm.

Concrete habits make the testing reliable and repeatable.

Test personas

Create a small set of invented people who represent your real population. Examples: a regular office worker with a phone prompt, a remote worker on a home network, a contractor with limited access, an executive with a security key, an administrator with elevated rights, a new joiner, a person who lost their device, and a user on an older browser. Run each persona through each important journey.

Test conditions

• Network: inside and outside trusted networks.
• Device: managed and unmanaged, desktop and mobile.
• Time: first sign-in of the day and repeat visits within a session.
• Risk: normal and unusual behaviour, where your policies use it.
• State: locked accounts, expired passwords, removed group memberships.

Evidence

Capture screenshots, event records, and results for each test. Store them with the migration log. When someone later asks “did you test the contractor case?”, the answer is a document, not a memory.

Regression after changes

Rerun the full suite whenever configuration changes during the project. Small late edits are the most common source of last-minute surprises.

Dry run of cutover

Practise the actual cutover steps in the rehearsal environment, including timing, checks, and rollback, so that the real event is a familiar routine. Time each step and note who does what.

flowchart TD
    PS["Personas"] --> MX["Journey x condition matrix"]
    MX --> RUN["Run and record evidence"]
    RUN --> DIF["List differences"]
    DIF --> FX["Fix or accept with approval"]
    FX --> RR["Rerun suite"]
    RR --> DRY["Dry run of cutover"]
    

Figure 22 shows the testing routine. The matrix ensures nothing important is forgotten, and the dry run converts the final step into a rehearsed routine.

Testing the unusual but plausible

Include scenarios that are rare but real: someone returning from long leave whose password has expired, a person changing departments and groups, a contractor whose contract ends tomorrow, a user travelling abroad with a new phone, an account that was locked by repeated failures. These cases tend to hit recovery and policy edges where differences between the engines are most likely to appear.

The project ends; the platform continues. Hand over properly.

After the final wave, the platform needs steady care. Write down how the new engine’s policies are structured, who may change them, how changes are reviewed, and how often the setup is examined. Without this, the cleanliness gained during migration slowly disappears.

Hold a retrospective

Within a few weeks of finishing, gather the team and ask what went well, what surprised you, and what you would do differently. Record the answers where the next project team will find them.

Retire leftovers

Remove temporary exceptions, test accounts, and rehearsal artifacts you no longer need. Archive the migration log and evidence under your retention policy.

flowchart TD
    DONE["Migration finished"] --> HAND["Handover documents"]
    HAND --> RUN["Operating rhythm"]
    RUN --> REV["Quarterly policy review"]
    RUN --> REL["Release note review"]
    DONE --> RETRO["Retrospective"]
    DONE --> CLEAN["Retire leftovers"]
    

Figure 23 shows the closing activities that turn a project into a stable service.

Keeping up with a changing platform

Okta continues to add and change features. Assign someone to read release notes regularly, assess what matters for your organization, and bring proposals to the quarterly review. Treat each addition as a small change project with its own rehearsal and communication, using the habits built during this migration.

Migrating brings benefits and costs. Weigh both honestly.

Key trade-offs

• Speed versus safety: faster moves save effort but raise risk.
• Equivalence versus improvement: copying old behaviour is safer; redesigning is more valuable but riskier.
• Clean slate versus continuity: a parallel organization is tidy but means more re-work for users.
• Customization versus supported settings: heavy custom pages give control but cost maintenance at every change.
• Waiting versus acting: waiting is easy now but may mean a bigger, less supported jump later.

quadrantChart
    title Migration activities by effort and value
    x-axis Low effort --> High effort
    y-axis Low value --> High value
    quadrant-1 Plan carefully
    quadrant-2 Do first
    quadrant-3 Skip for now
    quadrant-4 Reconsider
    Survey and cleanup: [0.3, 0.9]
    Rehearsal organization: [0.5, 0.9]
    Helpdesk preparation: [0.25, 0.8]
    Negative tests: [0.3, 0.85]
    Rebuilding all custom pages: [0.85, 0.5]
    Adding every new feature at once: [0.9, 0.3]
    

Figure 24 ranks sample activities. Early groundwork gives the best return; rebuilding everything or adding every feature at once should be questioned.

Deciding when not to migrate yet

There are times when waiting is sensible: a critical business period, a major merger underway, or a shortage of skilled staff. But waiting has a price, because the gap between your configuration and the platform grows. If you delay, use the time productively by surveying, cleaning up, retiring dead rules, and updating custom code so that the eventual move is smaller.

Proven shapes of good practice for each recurring migration problem.

flowchart LR
    DP1["Survey first"] --> OUT["Calm, safe migration"]
    DP2["Rehearsal gate"] --> OUT
    DP3["Parity then improve"] --> OUT
    DP4["Negative tests"] --> OUT
    DP5["Staged waves"] --> OUT
    DP6["Helpdesk gate"] --> OUT
    DP7["Exceptions expire"] --> OUT
    

Figure 25 shows that the patterns support each other. None is difficult alone, but together they turn a risky change into an orderly one.

Habits that look sensible but cause trouble.

flowchart TD
    A1["Big bang"] --> BAD["Lockouts, weakened rules,
angry users"]
    A2["Literal copying"] --> BAD
    A3["Late custom code review"] --> BAD
    A4["Happy path only"] --> BAD
    A5["Surprised helpdesk"] --> BAD
    A6["No break-glass access"] --> BAD
    A7["Early victory"] --> BAD
    

Figure 26 gathers the habits to avoid. Compare your plan against this list before each stage gate.

A short checklist of what to do and what to avoid.

Best practices

• Confirm your upgrade path and timelines with Okta before committing to dates.
• Write down the reason for migrating and the success measures.
• Survey everything and label each item keep, translate, simplify, retire, or investigate.
• Record benchmarks of current behaviour for the key journeys.
• Build a rehearsal organization and require parity there before production.
• Translate intent, not syntax, and check rule order carefully.
• Include negative, recovery, enrollment, and session tests.
• Inventory custom code and embedded sign-in with named owners.
• Train the helpdesk and update guides before each wave.
• Pilot with friendly users, then stage in waves with go and no-go limits.
• Keep protected emergency administrator access.
• Keep every exception time-limited and owned.
• Hold a retrospective and set an operating rhythm.

Common mistakes

• Assuming that because users and applications stay, nothing else changes.
• Leaving catch-all rules unreviewed.
• Forgetting that detections depend on event patterns.
• Changing authenticators, directories, and the engine at the same time.
• Leaving old screenshots in helpdesk guides.
• Relying on memory instead of recorded test evidence.
• Not rehearsing the rollback.
• Treating Okta-specific details as fixed rather than checking current documentation.

flowchart LR
    PL["Plan"] --> SU["Survey"]
    SU --> RE["Rehearse"]
    RE --> PI["Pilot"]
    PI --> WA["Waves"]
    WA --> ST["Stabilize"]
    ST --> IM["Improve"]
    IM --> PL
    

Figure 27 reminds us that the platform keeps evolving. The habits of the migration become the habits of everyday change.

Four fictional companies show the ideas in use. All names and details are invented for teaching.

flowchart LR
    A["Ashgrove
evidence and gates"] --> LESSON["Common thread:
survey, rehearse, stage, prepare people"]
    B["Brightwater
measure real experience"] --> LESSON
    C["Cinder
start with code"] --> LESSON
    D["Dunmore
time around peaks"] --> LESSON
    

Figure 28 shows each company’s emphasis. Their pressures differed, yet each succeeded by surveying first, rehearsing in safety, moving in waves, and preparing the people who would feel the change.

Thirty short answers to common beginner questions. Always confirm specifics in current Okta documentation.

A good migration is mostly preparation, and it is quiet when done well.

You began this guide with no background and now understand how to move an Okta organization from the Classic Engine to the Identity Engine. You know what changes and what stays, how sign-in flows and policy models differ, and where the real risks live: custom pages, embedded sign-in, scripts, detections, and rule order. You know how to survey, label, rehearse, test for parity with negative cases, prepare people, move in waves with gates, and keep a way back.

Treat the work as a loop of planning, surveying, rehearsing, piloting, staging, stabilizing, and improving. Prove equivalence before introducing improvements, keep exceptions short-lived, and keep your helpdesk ahead of your users. Confirm every platform detail, such as upgrade paths, feature differences, and timelines, in current Okta documentation, because details change while the ideas stay steady.