Understanding how the sprawl happened helps you avoid recreating it after the cleanup.

The usual causes

• Mergers and acquisitions. Each acquired company brings its own directory, sign-in service, and policies.
• Departmental independence. A business unit buys a tool that includes its own login system, and nobody tells the central team.
• Technology generations. Older applications use directories from the past, newer ones use cloud services, and the middle never gets migrated.
• Product bundles. Some business applications ship with a built-in identity system that quietly becomes a second source of users.
• Customer and workforce split. Customers and employees were given separate systems, sometimes by design and sometimes by accident.
• Regional or regulatory choices. A country office set up its own system to satisfy a local rule that may no longer apply.

What the sprawl costs

• User friction. Multiple passwords, multiple prompts, and confusion about which account to use.
• Security gaps. Inconsistent factor requirements, forgotten accounts, and no single place to end access when someone leaves.
• Operational cost. Several platforms to patch, license, monitor, and staff.
• Audit pain. Evidence must be gathered from many sources, each in a different format.
• Slow change. Introducing a new policy means negotiating with every system’s owner.

A short list of terms appears in every consolidation discussion. Knowing them keeps meetings productive.

Words about the Okta side

An Okta organization is your tenant. A universal directory is Okta’s internal store of users and groups. An identity provider in Okta’s own vocabulary means an external system that Okta trusts to authenticate certain users, used for federation. Routing rules decide which identity provider a user should be sent to, based on conditions such as email domain or network. An integration is a configured connection between Okta and an application.

flowchart LR
    OLD["Old identity providers"] --> CO["Coexistence period"]
    CO --> NEW["Okta as the single front door"]
    CO --> DEC["Decommissioning of old systems"]
    NEW --> APPS["Applications reconnected one by one"]
    

“Consolidate” can mean several quite different end states. Choosing one early shapes everything that follows.

Possible end states

• Full replacement. Every application and user moves to Okta, and old providers are shut down. This is the cleanest outcome and the hardest journey.
• Hub and spoke. Okta becomes the central hub. Some old providers remain as sources of identities, such as a directory, but applications trust only Okta.
• Federated coexistence. Okta sits in front of some applications while other providers continue serving theirs, linked by trust relationships. This is a stepping stone or a deliberate permanent compromise.
• Selective consolidation. Only certain populations, such as employees, move, while others, such as customers, stay separate on purpose.

Choosing among them

Ask what is driving the project: cost, security, user experience, or integration after an acquisition. A security-driven project aims for full replacement of weak systems. A merger-driven project often begins with coexistence, because the businesses must work together before they can fully merge. An application that cannot be changed may force a permanent exception. Be honest about these limits before promising a full shutdown date.

Defining done

Write a plain definition of success: a number of applications moved, a number of providers shut down, a percentage of sign-ins through Okta, and a date. Without it, the project drifts, and the last ten percent consumes half the time.

flowchart TD
    GOAL["Project goal"] --> Q1{"Can all apps and users move?"}
    Q1 -- "Yes" --> FULL["Full replacement"]
    Q1 -- "Mostly" --> HUB["Hub and spoke: some sources remain"]
    Q1 -- "Not yet" --> FED["Federated coexistence as a stepping stone"]
    Q1 -- "By design not all" --> SEL["Selective consolidation"]
    

A consolidation project competes for money and attention. A clear case keeps it funded when it gets hard.

Benefits worth stating

• Security. One place to apply strong authentication, end access, and detect abuse.
• Experience. One account, one portal, fewer prompts, fewer password resets.
• Operations. Fewer platforms to run, and faster onboarding and offboarding.
• Compliance. A single source of evidence for access reviews and audits.
• Agility. New applications and acquisitions can connect to a standard front door.
• Cost. Retiring old licenses, servers, and support contracts, balanced against the cost of the new platform and the migration itself.

Costs to include honestly

• Licenses for Okta and for any additional features needed.
• People: project team, application owners, help desk, and communications.
• Application changes, especially for old or vendor-controlled software.
• Running two systems in parallel for months.
• Testing, training, and user support during the transition.
• Risk costs: the chance of outages during cutovers.

Measurable goals

flowchart LR
    BEN["Benefits: security, experience, operations, compliance, agility"] --> CASE["Business case"]
    COST["Costs: licenses, people, app changes, parallel running, risk"] --> CASE
    CASE --> GOALS["Measurable goals and finish line"]
    GOALS --> SPON["Executive sponsor and funding"]
    

You cannot consolidate what you have not found. Discovery is slower than expected and always turns up surprises.

Where to look

• Central records. The configuration management database, architecture diagrams, and license lists.
• Network and logs. Sign-in traffic reveals which systems applications actually contact.
• Finance. Invoices for identity products, certificates, and domain names.
• Application owners. Ask each owner how their users sign in and where accounts come from.
• Cloud accounts. Sign-in services created inside cloud platforms for specific projects.
• Acquired companies. Their documentation is often incomplete, so interview their administrators.
• Built-in identity stores. Applications with their own user tables are hidden identity providers.

What to record for each provider

flowchart TD
    D1["Architecture records and license lists"] --> INV["Provider inventory"]
    D2["Network and sign-in logs"] --> INV
    D3["Finance records"] --> INV
    D4["Interviews with application owners"] --> INV
    D5["Acquired company documentation"] --> INV
    D6["Applications with their own user tables"] --> INV
    INV --> PROF["One profile per provider"]
    

Applications are the real units of migration. Each one has to be examined, scheduled, and moved.

Classify every application

• Modern protocol. Supports SAML or OpenID Connect. Usually straightforward to reconnect.
• Older federation protocol. Uses WS-Federation or a legacy variant. Often supported, with extra care.
• Directory-bound. Authenticates directly against a directory using LDAP or Kerberos. Needs a bridge or redesign.
• Header-based or proxy-based. Relies on a gateway that injects identity. Needs an access gateway integration.
• Local accounts. Keeps its own passwords. Needs a plan to move to federation or to synchronize.
• Custom or in-house. Owned by internal teams, who must change code or configuration.
• Vendor software with restrictions. Cannot be changed except by the vendor.

Capture the critical facts

For each application record the business owner, technical contact, number of users, sensitivity, availability expectations, current integration method, certificate expiry dates, who provisions accounts, and any scheduled upgrades or retirements. Applications scheduled for retirement should not be migrated at all; moving them wastes effort.

Rank and group

Score applications by effort and importance. Group those that share a pattern, such as all applications using the same protocol with the same vendor, and migrate them in batches with a shared playbook.

quadrantChart
    title "Application migration priority"
    x-axis "Low effort" --> "High effort"
    y-axis "Low importance" --> "High importance"
    quadrant-1 "Plan carefully"
    quadrant-2 "Do early"
    quadrant-3 "Batch or retire"
    quadrant-4 "Schedule last"
    "Modern SaaS app": [0.15, 0.6]
    "Collaboration suite": [0.25, 0.9]
    "Internal portal": [0.4, 0.55]
    "Directory-bound legacy": [0.85, 0.65]
    "Vendor-locked system": [0.9, 0.4]
    "Rarely used tool": [0.3, 0.1]
    

People are the other half of the migration. Their accounts, groups, passwords, and second factors all have to find a new home.

Accounts and populations

Count accounts in each provider, separate active from stale, and note the type of each: employee, contractor, partner, customer, service account, shared account, administrator. Stale accounts are an opportunity: do not migrate what should be deleted. Cleaning before moving shrinks the project and removes risk.

Overlaps between providers

The same person often exists in several providers, with different usernames, email addresses, or spellings of their name. Estimate how many people appear more than once and by which attributes they could be matched. This number drives the effort of identity matching later.

Groups and roles

Each provider has its own groups, many with unclear purposes. List them, find owners, and record which applications depend on which groups. Groups nobody can explain are candidates for retirement, but only after confirming that no application relies on them.

Credentials and factors

• How are passwords stored, and can they be moved? Many systems cannot export usable passwords.
• Which second factors are in use? Some factor types are tied to the old system and cannot be exported.
• Are there certificates, smart cards, or hardware keys that can be reused?
• What recovery methods exist, and are they strong enough to carry forward?

flowchart TD
    A["Accounts in all providers"] --> CL["Remove stale and duplicate accounts"]
    CL --> TY["Classify: employee, contractor, partner, customer, service, admin"]
    TY --> OV["Estimate overlaps between providers"]
    OV --> GR["Map groups and dependent applications"]
    GR --> CF["Assess credentials and factors for portability"]
    

Before moving anything, decide what the finished Okta estate should look like. Moving into a poorly designed target only relocates the mess.

Key design decisions

• Organization layout. One organization for the workforce is the simplest. Separate organizations may be justified for customers, for legally distinct entities, or for strict data separation. Keep the number small.
• Sources of truth. Decide which system owns each kind of identity: the human resources system for employees, a sponsor process for contractors, a customer registration flow for customers.
• Directory strategy. Decide whether existing directories remain as sources, are synchronized into Okta, or are retired.
• Naming and attributes. Standard usernames, email formats, and attribute definitions.
• Group model. A clear, documented set of groups tied to roles and applications.
• Policy tiers. A small set of sign-in policies by sensitivity, rather than copying every old rule.
• Authentication methods. Which factors are allowed, and which are the target, such as phishing-resistant ones.
• Administration model. Roles, delegation, and change control.
• Environments. A preview organization for testing, and how configuration is promoted.

Design for the end, not for the transition

Temporary bridges and special cases needed during migration should be clearly marked as temporary, with removal dates. Do not let temporary exceptions become the permanent design.

flowchart TD
    HR["HR system: employees"] --> OKT["Okta workforce organization"]
    SPN["Sponsor process: contractors"] --> OKT
    DIR["Retained directories, synchronized"] --> OKT
    OKT --> POL["Policy tiers"]
    OKT --> GRP["Standard groups"]
    OKT --> APPS["Applications"]
    CUST["Customer registration"] --> OKC["Separate customer organization, if needed"]
    

There are three broad ways to move: all at once, in phases, or by gradually strangling the old system. Each trades speed against risk.

Big bang

Everything moves over a single weekend. It is quick and avoids a long coexistence period. It also concentrates risk: if anything goes wrong, everything is affected at once, and the help desk is overwhelmed. It is realistic only for small estates with few applications and strong testing.

Phased by population or application

Groups of users or applications move in waves, with lessons from each wave improving the next. Risk is spread and contained. The cost is a long period during which two systems run side by side, with all the extra complexity that brings. This is the most common approach.

Strangler pattern

Okta is placed in front, and the old provider is gradually starved of work. New applications connect only to Okta. Existing applications are reconnected as they are touched for other reasons. The old system shrinks until it can be switched off. It is gentle and sustainable but may take years if nobody drives the final steps.

gantt
    title Phased migration compared with big bang
    dateFormat YYYY-MM-DD
    section Big bang
    Preparation :a1, 2026-01-05, 90d
    Single cutover weekend :milestone, a2, 2026-04-05, 0d
    section Phased
    Preparation :b1, 2026-01-05, 60d
    Wave one pilot :b2, after b1, 30d
    Wave two :b3, after b2, 45d
    Wave three :b4, after b3, 45d
    Wave four and decommission :b5, after b4, 60d
    

For months, Okta and the old providers must live together. Coexistence is where most of the real engineering happens.

Okta as the hub

A common approach is to make Okta the single front door immediately, even for users whose accounts still live in an old provider. Okta can trust an external identity provider to authenticate certain users, using a federation protocol. A user visits an application, is sent to Okta, and Okta in turn sends them to their old provider to prove who they are. The application sees only Okta. Later, when the user’s account moves to Okta, the extra hop disappears and the application does not need to change again.

Why this helps

• Applications change once. Each application is reconnected to Okta a single time, rather than twice.
• Users see one entry point and a consistent portal sooner.
• Policies begin to apply centrally to access after sign-in, even before credentials move.
• The old provider shrinks gradually as users are moved, without disturbing applications.

Limits to understand

• Authentication strength is limited by the old provider while the user is still routed to it.
• Two sign-in experiences may appear during the transition.
• Attributes from the old provider may differ from what applications expect, requiring mapping.
• Sessions exist in both systems, which complicates sign-out.
• The old provider remains a critical dependency and a point of failure.

sequenceDiagram
    participant U as "User"
    participant A as "Application"
    participant O as "Okta"
    participant P as "Old provider"
    U->>A: "Open application"
    A->>O: "Redirect for sign-in"
    O->>O: "Decide which provider authenticates this user"
    O->>P: "Redirect user to old provider"
    P->>U: "Prompt for credentials"
    U->>P: "Provide credentials"
    P->>O: "Assertion that the user is authenticated"
    O->>A: "Assertion from Okta"
    A->>U: "Signed in"
    

When several providers are connected, Okta needs a reliable way to decide where each person should sign in.

Routing rules

Okta lets you define rules that choose the identity provider based on conditions. Typical conditions are the user’s email domain, the network they are connecting from, the application they are trying to reach, or an attribute in a previous step. Rules are evaluated in order, and the first matching rule decides. A final default rule sends everyone else to Okta’s own authentication.

Common routing designs

• By domain. Staff with one email domain are sent to provider A, and staff with another domain to provider B. Simple and common after acquisitions.
• By population label. A migration flag, held in the user’s record, decides who has moved. Moved users authenticate in Okta, unmoved users go to the old provider.
• By network. Users on the corporate network may be routed differently from users outside, though this is fragile.
• By application. Certain sensitive applications always require Okta’s stronger authentication.

Careful points

• Rule order matters. Document it and test changes in a preview organization.
• Avoid loops, where two providers send users back to each other.
• Make sure users with shared or ambiguous usernames resolve correctly.
• Provide an escape route for administrators, so a routing mistake cannot lock everyone out.
• Treat the routing configuration as high-risk change, reviewed by a second person.

flowchart TD
    START["User identifies themselves"] --> R1{"Rule 1: administrator group"}
    R1 -- "Match" --> OKA["Authenticate in Okta with strongest policy"]
    R1 -- "No" --> R2{"Rule 2: migration flag set"}
    R2 -- "Match" --> OKB["Authenticate in Okta"]
    R2 -- "No" --> R3{"Rule 3: email domain of acquired company"}
    R3 -- "Match" --> PB["Send to provider B"]
    R3 -- "No" --> R4{"Rule 4: legacy employee domain"}
    R4 -- "Match" --> PA["Send to provider A"]
    R4 -- "No" --> DEF["Default: Okta authentication"]
    

When the same person exists in several providers, you must decide which records are really the same human, and which record wins.

Matching signals

• Strong identifiers. Employee number, national identifier where lawful, or a unique ID from the human resources system.
• Medium identifiers. Verified email address, date of birth combined with name.
• Weak identifiers. Name alone, phone number, or manager. Useful only to support a decision, never to make one.

The matching process

Dangers

Wrongly merging two different people can give one person access to another’s data, which is a serious breach. Wrongly keeping duplicates leaves orphan accounts that nobody manages. Prefer caution: automate only on strong identifiers, and review everything else.

flowchart LR
    A["Record in provider A"] --> N["Normalize"]
    B["Record in provider B"] --> N
    C["Record in HR system"] --> N
    N --> M{"Strong key matches?"}
    M -- "Yes" --> G["Golden record in Okta"]
    M -- "Maybe" --> R["Human review"]
    R --> G
    M -- "No" --> S["Separate identities"]
    G --> X["Cross-reference to every source account"]
    

Each provider describes people differently. Applications depend on those descriptions, so changing them quietly breaks things.

The differences you will find

• Different names for the same field, such as department, division, and cost center.
• Different formats, such as dates, phone numbers, and country codes.
• Different meanings, such as a status field that means active in one system and not-locked in another.
• Different completeness, with some systems rich in data and others sparse.
• Different username formats, which applications may use as account keys.

Designing the target profile

Define a standard profile with clear definitions, formats, and owners for each attribute. Mark which attributes are authoritative from the human resources system and which are managed elsewhere. Keep the standard small. Attributes added because someone might one day need them accumulate and rot.

Protecting applications

Many applications use an attribute, often the email address or username, as the unique key for each account. If the key changes at cutover, the application sees a new person and creates an empty account, losing the user’s data. For each application, identify which attribute is the key and make sure Okta sends exactly the same value. Okta lets you transform attributes on the way out, so the application can continue to see the identifiers it knows even if the underlying standard has changed.

flowchart LR
    SA["Provider A attributes"] --> MAP["Mapping and transformation"]
    SB["Provider B attributes"] --> MAP
    HRA["HR authoritative attributes"] --> MAP
    MAP --> STD["Standard Okta profile"]
    STD --> OUT["Per-application outgoing attributes"]
    OUT --> APP1["App 1 expects email as key"]
    OUT --> APP2["App 2 expects employee number as key"]
    

Groups tell applications who may do what. A careless merge of groups can silently grant or remove access for thousands of people.

The group problem

Over the years, groups accumulate with names like “Finance-Users”, “FIN_Access”, and “finance team”. Two may mean the same thing, or look the same but carry different permissions. Some are used by applications to decide roles. Others are leftovers. Without care, consolidating them can give people more access than intended, or remove access they need.

A safe approach

• Inventory. List every group with its members, owner, and the applications that use it.
• Classify. Mark each as business role, application role, technical, or obsolete.
• Design a standard model. Prefer groups based on roles and attributes, with clear naming and owners.
• Map old to new. A table links each old group to the new group or groups that replace it.
• Prefer rules over manual membership where attributes reliably determine membership.
• Compare effective access. Before and after migration, compare what each person could reach, and investigate differences.
• Recertify. Ask owners to confirm memberships of sensitive groups.

Roles inside applications

Some applications read group names from the sign-in assertion to assign internal roles. If the group names change, roles change. Keep the outgoing group values the same until each application is separately updated.

flowchart TD
    OG["Old groups from all providers"] --> CL["Classify and find owners"]
    CL --> MP["Mapping table old to new"]
    MP --> NG["Standard Okta groups"]
    NG --> CMP["Compare effective access before and after"]
    CMP --> OK{"Differences explained?"}
    OK -- "Yes" --> GO["Proceed"]
    OK -- "No" --> FIX["Investigate and correct mapping"]
    

Passwords are the most awkward thing to move. Often the best move is to avoid moving them at all.

Why passwords are hard

Passwords are stored as irreversible scrambled values. Different systems scramble them differently, and many do not let you export them. Even where export is possible, the format may not match what the new system can verify. And a password stored in an old, weaker format may be exactly what you hoped to retire.

Options

• Import compatible hashes. If the old system’s stored form can be verified by Okta, users keep their passwords. This is quick when possible, but check which formats are supported.
• Delegated authentication. Okta passes the password to the old directory to verify during sign-in. Users keep their password until a later step replaces it. This keeps the old directory alive and in the sign-in path.
• Just-in-time migration. On first sign-in through Okta, the password is checked against the old system and, if correct, stored in Okta. Over time, active users migrate themselves. Inactive users remain behind.
• Forced reset. Users create a new password in Okta, verified by a strong method. Clean, but disruptive, and the reset process must resist social engineering.
• Move to passwordless. Enroll users in phishing-resistant factors and reduce passwords to a fallback. A migration is a good moment to do this.

flowchart TD
    Q1{"Can old password hashes be imported?"} -- "Yes" --> IMP["Import hashes, then encourage change"]
    Q1 -- "No" --> Q2{"Can the old system stay online for a while?"}
    Q2 -- "Yes" --> Q3{"Prefer gradual move?"}
    Q3 -- "Yes" --> JIT["Just-in-time migration at first sign-in"]
    Q3 -- "No" --> DEL["Delegated authentication during transition"]
    Q2 -- "No" --> RST["Forced reset with strong verification"]
    IMP --> PWL["Move users toward passwordless over time"]
    JIT --> PWL
    DEL --> PWL
    RST --> PWL
    

Second factors are tied to the system that issued them. In most cases people must enroll again in Okta, and this is your chance to improve.

What can move and what cannot

• Authenticator apps with shared secrets. The shared secret lives in the old system. Some migrations can transfer it, but this is complex and requires care, so most teams re-enroll.
• Push notification apps. Tied to the vendor’s app and server. Users must enroll in the new app.
• Hardware keys and passkeys. Credentials are registered per service, so users usually register them again in Okta, though they keep the same physical key.
• SMS and voice. Phone numbers can be copied, but these methods are weak and ideally should not be carried forward.
• Certificates and smart cards. Can often be reused if the same certificate authority is trusted.

Re-enrollment done well

• Make enrollment a guided, pleasant experience with clear instructions and short videos.
• Verify identity strongly before enrollment, since an attacker who enrolls first owns the account.
• Schedule enrollment in waves with reminders, not all at once.
• Allow old and new factors to coexist for a short, defined period.
• Offer in-person or video help for those who struggle.
• Use the moment to move people to stronger factors than they had before.
• Track enrollment rates and chase the stragglers early.

sequenceDiagram
    participant U as "User"
    participant H as "Helper or verification step"
    participant O as "Okta"
    U->>H: "Prove identity using strong method"
    H-->>U: "Enrollment link or code"
    U->>O: "Open enrollment"
    O-->>U: "Offer recommended strong factor"
    U->>O: "Register factor"
    O-->>U: "Confirm and show next steps"
    O->>O: "Mark user as ready for cutover"
    

How an application connects to its current provider decides how hard it is to move. Treat each family with its own playbook.

Standard playbook for modern applications

flowchart TD
    APP["Application"] --> T{"Protocol?"}
    T -->|"SAML or OIDC"| M1["Reconnect directly"]
    T -->|"WS-Federation"| M2["Reconnect with testing"]
    T -->|"LDAP or Kerberos"| M3["Directory bridge or modernize"]
    T -->|"Header based"| M4["Gateway integration"]
    T -->|"Local accounts"| M5["Federate, then retire local logins"]
    T -->|"Vendor locked"| M6["Vendor request or exception"]
    

At the heart of every application migration is a small, delicate change: telling the application to trust Okta instead of the old provider.

What an application needs to trust a provider

• The provider’s identifier, sometimes called the issuer or entity identifier.
• The address where users are sent to sign in.
• The signing certificate or keys used to verify assertions.
• The agreed format of the account identifier, and which attributes will be sent.
• The sign-out address and rules.

Where trouble hides

• Certificates. Applications may pin a certificate. When keys rotate, sign-in breaks. Record expiry dates and plan rollovers.
• Identifiers. A mismatch between the issuer the application expects and the one Okta sends causes rejection.
• Account identifiers. A subtle difference, such as upper versus lower case or a domain suffix, creates duplicate accounts.
• Time. Assertions carry time limits. Clock differences cause failures.
• Redirect addresses. For OpenID Connect, an unregistered address blocks sign-in.
• Multiple tenants. Some applications accept only one trusted provider per tenant, forcing an exact moment of switch.

Switch methods

Applications that support multiple providers allow overlap and gradual transition. Those that support only one need a short maintenance window, a tested rollback, and clear communication. In both cases, practice the exact steps in a test instance first.

sequenceDiagram
    participant AO as "Application owner"
    participant ID as "Identity team"
    participant OK as "Okta"
    participant AP as "Application"
    ID->>OK: "Create integration with matching identifiers"
    ID->>AO: "Share metadata and test plan"
    AO->>AP: "Add Okta as additional trusted provider if supported"
    ID->>AP: "Pilot users sign in through Okta"
    AO->>AP: "Make Okta the only provider at agreed time"
    ID->>AP: "Verify with test accounts"
    AO->>AP: "Remove old provider after quiet period"
    

Cutover is not just a configuration change. People are signed in, tokens are in flight, and mobile applications hold long-lived sessions.

What can go wrong

• Existing sessions continue with the old provider until they expire, so some people are in the old world while others are in the new one.
• Refresh tokens issued by the old provider may stop working, forcing sudden sign-ins in mobile applications.
• Cached identity in browsers or desktop clients may keep sending users to the old address.
• Single sign-out relationships break, so signing out of one place does not sign out of another.
• Integrations and automation using old tokens or service accounts may fail silently.

Planning for it

• Shorten session and token lifetimes in the old provider ahead of cutover so that users naturally re-authenticate.
• Pick a time of low activity, but not a time when no one can help.
• Warn users that they will be asked to sign in again.
• Identify applications with long-lived tokens, such as mobile applications, and test them separately.
• Inventory machine-to-machine access tied to the old provider and migrate it explicitly.
• Have the old provider ready to take traffic back if rollback is needed, until the quiet period ends.

stateDiagram-v2
    [*] --> OldSession
    OldSession --> Transition: "cutover begins"
    Transition --> ReAuth: "session expires or is ended"
    ReAuth --> NewSession: "user signs in via Okta"
    Transition --> Rollback: "serious problem"
    Rollback --> OldSession
    NewSession --> [*]
    

Sign-in is only half of identity. Creating, changing, and removing accounts is just as important, and often tied to the old providers.

How old systems handled lifecycle

Some providers push accounts into applications automatically. Others rely on scripts, tickets, or manual work. Some applications create accounts on first sign-in with no cleanup when people leave. Before migrating, you must know, for each application, how accounts appear, change, and disappear.

The target lifecycle

• Joiner. The human resources system creates the person. Okta creates the account, assigns groups by attributes, and provisions applications through standard interfaces such as SCIM where supported.
• Mover. A change of department or role changes attributes. Group rules adjust access automatically and revoke what is no longer needed.
• Leaver. Termination in the human resources system triggers immediate suspension in Okta, session termination, and deprovisioning of applications.
• Contractor lifecycle. A sponsor and an end date control the account.

During migration

• Avoid two systems both provisioning the same application. They fight over the account’s state.
• Switch provisioning authority for each application deliberately, at the same time as sign-in.
• Reconcile existing accounts so that Okta links to them instead of creating duplicates.
• Ensure leavers are handled in both systems until the old one is retired.

flowchart LR
    HR["HR system"] --> OK["Okta"]
    OK -->|"Joiner: create and assign"| APPS["Applications"]
    OK -->|"Mover: change groups"| APPS
    OK -->|"Leaver: suspend and deprovision"| APPS
    OLD["Old provider provisioning"] -.->|"Retire per application"| APPS
    

Many “identity providers” are really directories. Deciding what to do with them is one of the biggest design questions.

Options for each directory

• Keep as a source. Okta synchronizes users and groups from the directory, and the directory continues to hold the master record. Common when the directory also serves servers, file shares, and desktops.
• Keep for infrastructure only. The directory stays for machines and legacy applications, but Okta becomes the master for people and for sign-in to applications.
• Migrate and retire. Move all identities and dependent applications to Okta and shut the directory down. Possible only if nothing else depends on it.
• Merge directories first. Combine several directories into fewer before synchronizing, or synchronize several into one Okta organization with a defined attribute precedence.

Typical challenges

• Several directories with overlapping users and conflicting attributes.
• Directory groups used for file permissions that cannot simply be renamed.
• Computers joined to the directory that depend on it for sign-in.
• Trusts between directories, which carry hidden dependencies.
• Synchronization conflicts when two sources describe the same person.

Cloud directories from other vendors

Organizations often have an existing cloud directory from a productivity suite. Okta can federate with it or take over as the central sign-in service in front of it. Whether you keep it as the source of mailbox identities or replace it depends on how deeply your productivity applications rely on it. Many companies retain it for those applications while placing Okta as the single sign-in layer.

flowchart TD
    D1["On-premises directory A"] --> OK["Okta"]
    D2["On-premises directory B"] --> OK
    D3["Cloud directory of productivity suite"] --> OK
    HRS["HR system"] --> OK
    OK --> PREC["Attribute precedence rules"]
    PREC --> UD["Single Okta profile per person"]
    D1 -.->|"Still used by servers and file shares"| INF["Infrastructure"]
    

Employees and customers have different needs. Putting them in the same system is not always wise.

Why they differ

Guidelines

• Treat customer identity as a separate product with a separate organization or a purpose-built offering, with licensing that matches large numbers of users.
• Do not merge employee and customer accounts into one directory, even if some people are both.
• Allow employees who are also customers to have two separate accounts, or link them carefully with consent.
• Align the security baseline so customer-facing systems do not become a weak path into internal ones.
• Plan separate consolidation timelines, since their risk, volume, and stakeholders differ.

flowchart LR
    EMP["Employees and contractors"] --> WF["Workforce organization: strong factors, lifecycle control"]
    CUS["Customers"] --> CI["Customer identity: convenience, scale, privacy"]
    WF --> INT["Internal applications"]
    CI --> EXT["Customer-facing applications"]
    WF -.->|"Administrators of customer systems"| CI
    

Acquisitions are a leading cause of identity sprawl and a common trigger for consolidation. Time pressure makes them tricky.

Typical stages

Special considerations

• Different legal entities. Some regulations require separation of data or administration for a time.
• Divestitures. The reverse problem: separating identities cleanly when part of the business is sold. Design groups and attributes so that a business unit can be split off.
• Brand and domain changes. Email domain changes affect usernames and account keys in applications.
• Culture. The acquired administrators may feel their expertise is dismissed. Involve them as partners.
• Trust between organizations. Limit the access given across the boundary until risk is understood.

flowchart LR
    ACQ["Acquired company provider"] -->|"Federation"| HUB["Okta hub"]
    HUB --> SHARED["Shared apps: mail, collaboration"]
    HUB --> PARENT["Parent company applications"]
    ACQ --> OWNAPPS["Acquired company applications"]
    HUB -.->|"Later: move users and apps"| FULL["Single Okta estate"]
    

Each provider enforced its own rules for passwords, factors, sessions, and lockouts. The target needs one consistent set.

Compare, then decide

The “strictest wins” trap

It is tempting to adopt the strictest rule from any provider. This may be wise for security, but it can also produce a sudden jump in friction for groups that were used to lighter rules, causing resistance. Instead, define policy tiers by sensitivity, set the target for each tier, and plan the changes, communicating to affected groups and, where necessary, phasing in stricter requirements.

Exceptions

Some populations legitimately need different rules: shop floor staff with shared devices, kiosk users, field workers with weak connectivity. Handle them with documented exceptions, owners, and review dates, rather than weakening the baseline.

flowchart TD
    PA["Policies of provider A"] --> CMP["Comparison table"]
    PB["Policies of provider B"] --> CMP
    PC["Policies of provider C"] --> CMP
    CMP --> TIER["Define tiers by sensitivity"]
    TIER --> TGT["Target policy per tier"]
    TGT --> PHASE["Phase in changes with communication"]
    TGT --> EXC["Documented exceptions with owners and expiry"]
    

Consolidation concentrates power. Decide who may administer Okta, and how changes are controlled, before the estate depends on it.

Who administers what

• A small group of super administrators with strong protection and break-glass procedures.
• Delegated administrators for business units, regions, or acquired companies, limited to their own users and applications.
• Application owners who manage assignments for their own applications within guardrails.
• Help desk roles limited to resetting factors and unlocking accounts for a defined scope.
• Read-only auditors who can view configuration and logs without changing anything.

Change control

Treat configuration of Okta as software: version control, peer review, test in a preview organization, and controlled promotion to production. The consolidation project will make hundreds of changes, and a disciplined route keeps them safe and traceable. Keep an audit trail linking each change to a ticket and an approver.

Governance forum

Create a steering group with representatives from security, infrastructure, human resources, application owners, the acquired businesses, and the help desk. It approves scope, resolves disputes about policy, and removes blockers. Without it, every disagreement stalls the project.

Protecting the administrators

Require the strongest authentication for administrative access, restrict it to managed devices and trusted networks, keep administrative accounts separate from daily accounts, and alert on every administrative change. The consolidated estate is a more attractive target than any of the separate ones were.

flowchart TD
    SG["Steering group"] --> SA["Super administrators: few, protected"]
    SA --> DA["Delegated administrators by business unit"]
    SA --> HD["Help desk roles: scoped"]
    DA --> AO["Application owners within guardrails"]
    SA --> CC["Configuration under version control and review"]
    SA --> AU["Audit and alerting on admin changes"]
    

Most migration pain is felt by people who did not know it was coming. Good communication is not a luxury but a core deliverable.

Know your audiences

• Executives want progress, risk, and cost, in few words.
• Application owners want dates, tasks, and what they must do.
• End users want to know what changes for them, when, and what to do if something goes wrong.
• Help desk wants scripts, known issues, and escalation paths.
• Administrators of old systems want respect, clarity on their future roles, and involvement.

A communication rhythm

Guard against phishing during the project

Attackers love migrations. Messages saying “you must re-enroll your account” are exactly what phishing looks like. Use consistent, authenticated channels, tell users what legitimate messages will and will not ask for, and never request passwords or codes by message. Make the official page easy to recognize and bookmark.

sequenceDiagram
    participant P as "Project team"
    participant U as "Users"
    participant H as "Help desk"
    P->>U: "Early announcement with why and when"
    P->>U: "Wave instructions three weeks ahead"
    P->>H: "Scripts and known issues"
    P->>U: "Reminders one week and one day before"
    U->>H: "Questions on and after cutover day"
    H->>P: "Issues log and trends"
    P->>U: "Follow-up message and lessons"
    

The help desk absorbs the shock of every cutover. A prepared desk turns a stressful day into a manageable one.

What the desk needs

• Training on the new sign-in flow, factor enrollment, recovery, and common errors.
• Scripts for the most likely questions and a clear escalation path.
• Secure verification procedures for resetting factors, so attackers cannot talk their way into accounts by pretending to be locked-out users.
• Scoped tools allowing them to unlock accounts and reset factors only for the people they support.
• Extra staff on cutover days and for a week afterward.
• A shared issues log so patterns are noticed and fixed centrally.
• A direct line to the project team for urgent problems.

Predictable tickets

flowchart TD
    CALL["User contacts help desk"] --> V["Verify identity with strong procedure"]
    V --> TR{"Known issue?"}
    TR -- "Yes" --> SC["Follow script"]
    TR -- "No" --> ES["Escalate to project team"]
    SC --> LOG["Record in shared issues log"]
    ES --> LOG
    LOG --> FIX["Central fix and updated script"]
    

Every cutover should be rehearsed. The cheapest place to find a problem is a test, and the second cheapest is a pilot.

Layers of testing

• Configuration review. A second person checks identifiers, certificates, attributes, and routing rules.
• Test organization. Build and verify the integration in a preview Okta organization against a test instance of the application.
• Persona tests. Test accounts for each type of user: employee, contractor, administrator, part-time, someone with an unusual name or characters.
• Negative tests. Confirm that people who should not have access are denied, and that expired or disabled accounts cannot sign in.
• Load tests. Simulate the morning rush if the application is large.
• Failure tests. What happens if the old provider is down, or if Okta cannot reach a directory?
• Rollback rehearsal. Practice the way back, and time it.

Pilots

Select a pilot group that is friendly, representative, and prepared to report problems: the IT department, volunteers from several regions, and a few people with unusual setups. Run for a defined period with clear exit criteria such as no severe issues for a week and a satisfaction score above a threshold. Use pilot feedback to refine instructions and scripts before the broad wave.

flowchart LR
    CR["Configuration review"] --> TO["Test organization"]
    TO --> PT["Persona and negative tests"]
    PT --> FT["Failure and rollback tests"]
    FT --> PL["Pilot group"]
    PL --> EX{"Exit criteria met?"}
    EX -- "Yes" --> WV["Broad wave"]
    EX -- "No" --> IM["Improve and repeat"]
    

A wave plan turns hundreds of small migrations into a schedule that people can understand and survive.

Constructing waves

• Wave zero: the project team and the IT department. Learn quickly, with friendly users.
• Early waves: simple, low-risk applications and their users to build confidence.
• Middle waves: the bulk of applications, grouped by pattern and owner.
• Late waves: the difficult ones, with dedicated engineering time.
• Final wave: executives, special populations, and the last stragglers, with white-glove support.

Avoid cutovers during business-critical periods: financial period ends, peak sales season, major launches, and holidays when staff are scarce.

Go and no-go checks

Before each cutover, check: tests passed, communications sent, help desk staffed, rollback tested, owners available, no conflicting changes in the period, and monitoring ready. If any answer is no, delay. A postponed cutover costs a little. A failed one costs a lot more.

Rollback design

• Keep the old provider’s trust in the application available until the quiet period ends, if the application allows.
• Define the exact trigger for rollback: error rates, number of blocked users, or a named person’s decision.
• Record exactly what was changed so that it can be reversed in order.
• Plan for rollback of data: accounts created by the new path may need cleaning.
• Decide a time after which rollback is no longer practical, and tell everyone.

gantt
    title Example wave plan
    dateFormat YYYY-MM-DD
    section Preparation
    Discovery and design :a1, 2026-01-05, 60d
    Okta foundation and coexistence :a2, after a1, 45d
    section Waves
    Wave zero IT department :b0, after a2, 14d
    Wave one simple apps :b1, after b0, 30d
    Wave two core business apps :b2, after b1, 45d
    Wave three difficult apps :b3, after b2, 60d
    Final wave special populations :b4, after b3, 30d
    section Closure
    Quiet period and decommission :c1, after b4, 45d
    

A consolidation is not finished until the old systems are gone. Leaving them running keeps all the cost and risk you set out to remove.

Why decommissioning stalls

Teams are tired after the last wave, an unknown dependency appears, or someone fears turning off a system that “might be used”. Without a firm process, old providers linger for years as unmanaged, unpatched, high-value targets.

A safe decommissioning sequence

stateDiagram-v2
    [*] --> Active
    Active --> Draining: "no new apps, users moving"
    Draining --> ReadOnly: "usage near zero, notice given"
    ReadOnly --> Disabled: "quiet period passed"
    Disabled --> Archived: "records preserved"
    Archived --> [*]: "infrastructure destroyed, contracts ended"
    ReadOnly --> Draining: "unexpected dependency found"
    

The transition period is when the attack surface is largest. Two systems, temporary bridges, and a busy team all create openings.

Risks specific to transition

• Weakest link rules. Users routed to the weakest old provider can bypass the stronger controls in Okta for applications that still accept both.
• Orphaned accounts. People who leave are disabled in one system but not another.
• Federation trust abuse. A compromised old provider can assert any identity into Okta if trust is too broad.
• Temporary exceptions. Waivers granted to unblock a wave that are never removed.
• Enrollment hijack. Attackers enroll their own factor on accounts that have not yet enrolled.
• Phishing campaigns imitating migration messages.
• Over-privileged project accounts used by consultants and engineers.
• Data exposure in exports and spreadsheets used for matching and planning.

Mitigations

• Limit what federated identities from old providers can do: restrict them to specific applications and require extra proof for sensitive ones.
• Maintain a combined leaver process, tested end to end.
• Give each exception an owner and an expiry, and review them weekly.
• Pre-enroll users or require strong identity verification for enrollment.
• Brief users about migration-themed phishing.
• Use time-limited, monitored access for project staff and third parties.
• Protect migration data as sensitive: restrict access, encrypt it, and delete it when finished.
• Increase monitoring of both systems during the transition.

flowchart TD
    OLD["Old provider, possibly weaker"] -->|"Federation trust"| OKT["Okta"]
    OKT --> LIM["Limit federated users: scoped apps, extra proof for sensitive"]
    OLD --> LV["Leaver process covers old provider too"]
    OKT --> EX["Exceptions register with expiry"]
    OKT --> MON["Heightened monitoring"]
    ATT["Attacker"] -.->|"Compromise old provider"| OLD
    ATT -.->|"Phishing with migration themes"| USR["Users"]
    

Both the project and the live system need measurement. Without it, you cannot tell whether you are on track or in trouble.

Progress measures

Health measures

• Sign-in success and failure rates by application and by route.
• Time taken for sign-in, especially for federated routes.
• Help desk ticket volumes and categories after each wave.
• Rate-limit usage and synchronization lag from directories.
• Authentication anomalies and suspicious activity in either system.
• Certificate and credential expiry dates.

Using the data

Review weekly with the project team and monthly with the steering group. Share a simple dashboard showing the countdown to the last old provider’s shutdown. Visible progress sustains energy over a long project.

flowchart LR
    LG["Okta and old provider logs"] --> DASH["Project dashboard"]
    TK["Help desk tickets"] --> DASH
    PL["Project plan status"] --> DASH
    DASH --> WK["Weekly team review"]
    DASH --> MO["Monthly steering group"]
    DASH --> AL["Alerts: failure spikes, expiring certificates"]
    

Things will go wrong. Writing down the response ahead of time turns panic into procedure.

The shape of a good response

Stop further changes first. Assess scope: which users and applications are affected. Restore service using the planned rollback. Communicate plainly to users and leadership. Investigate the cause only after service is stable. Capture lessons and update the playbooks. A calm routine, practiced in advance, makes the difference.

flowchart TD
    DET["Problem detected"] --> STP["Pause further changes"]
    STP --> SCP["Assess affected users and apps"]
    SCP --> RB{"Rollback available?"}
    RB -- "Yes" --> ROL["Execute rollback"]
    RB -- "No" --> WK["Workaround or emergency fix"]
    ROL --> COM["Communicate to users and leadership"]
    WK --> COM
    COM --> INV["Investigate cause"]
    INV --> LES["Update playbooks"]
    

Consolidation projects are famous for running late. Honest estimates and clear assumptions protect credibility.

Where time really goes

• Discovery. Always longer than expected, since information is scattered and owners are busy.
• Application owners. Waiting for their time and approval is the most common source of delay.
• The difficult ten percent. A few legacy and vendor-locked applications consume half the effort.
• Data cleanup. Duplicate accounts, stale records, and inconsistent attributes take serious work.
• Factor enrollment. Persuading every user, including executives and shift workers, takes months of reminders.
• Blackout periods. Financial closes, holidays, and product launches remove calendar windows.
• Vendor timelines. Waiting for a supplier to support a new provider.

Estimating

Estimate per application, using the classification from the inventory, and add contingency. Build in time for the pilot and rehearsal of each wave. Present ranges rather than single dates, and update them as the real pace becomes known. Separate the big decisions, such as scope and end state, from the schedule so that scope creep is visible.

Cost categories to track

• Okta licenses and add-on products during and after the project.
• Parallel running of old providers.
• Internal staff time and contractor fees.
• Application changes and vendor fees.
• Training, communications, and support.
• Savings from retired licenses, servers, and support contracts, recognized only once they actually stop.

quadrantChart
    title "Effort versus count of applications"
    x-axis "Few applications" --> "Many applications"
    y-axis "Low effort each" --> "High effort each"
    quadrant-1 "Heavy and large"
    quadrant-2 "Few but hard"
    quadrant-3 "Quick wins"
    quadrant-4 "Bulk and routine"
    "Modern SaaS": [0.9, 0.2]
    "Internal portals": [0.6, 0.35]
    "Header based": [0.3, 0.55]
    "Directory bound": [0.2, 0.85]
    "Vendor locked": [0.15, 0.7]
    

These arrangements repeatedly succeed in consolidation projects.

flowchart TD
    P1["Inventory and clean"] --> G1["Smaller, clearer project"]
    P2["Okta as hub early"] --> G2["Apps change once"]
    P3["Strong-key matching"] --> G3["No wrong merges"]
    P4["Preserve what apps see"] --> G4["No empty accounts"]
    P5["Waves and pilots"] --> G5["Contained risk"]
    P6["Disciplined decommission"] --> G6["Old risk truly removed"]
    G1 --> OUT["Successful consolidation"]
    G2 --> OUT
    G3 --> OUT
    G4 --> OUT
    G5 --> OUT
    G6 --> OUT
    

These habits feel efficient but cause outages, security gaps, or projects that never end.

flowchart TD
    A1["Skip cleanup"] --> B1["Huge messy migration"]
    B1 --> C1["Delays and workarounds"]
    C1 --> D1["Old providers kept online"]
    D1 --> E1["Higher cost and larger attack surface than before"]
    

Every choice in a consolidation gives something and takes something. Naming the trade-offs makes honest decisions possible.

Best practices in one place

• Define the end state and finish line in writing, including named exceptions.
• Inventory providers, applications, accounts, groups, and factors before designing.
• Clean data first, and retire what is not needed.
• Make Okta the hub early, and reconnect each application once.
• Match identities only on strong keys, and keep a cross-reference.
• Preserve outgoing identifiers and group values until applications are individually updated.
• Choose credential and factor migration paths that avoid weak methods.
• Rehearse each wave with tests, a pilot, and a rollback plan.
• Prepare the help desk and communicate early and often.
• Protect against migration-themed phishing and enrollment hijack.
• Run a combined leaver process until the last old provider is gone.
• Decommission old systems deliberately, removing trusts and secrets.

Frequent mistakes

• Underestimating discovery and the difficult last applications.
• Treating the project as technical only and neglecting people and communication.
• Letting temporary exceptions become permanent.
• Forgetting machine-to-machine access tied to the old provider.
• Changing too many things in one wave.
• Keeping the old provider running with no owner.
• Assuming that all vendors support the new trust model quickly.

flowchart LR
    S["Small estate"] --> SB["Fewer waves, faster, simpler governance"]
    M["Mid-sized estate"] --> MB["Phased waves, dedicated team, steering group"]
    L["Large or acquisitive estate"] --> LB["Long program, hub model, divisional delegates, permanent migration playbooks"]
    

Here is an invented company that consolidated five identity providers into Okta over about eighteen months. The names and numbers are made up for illustration.

gantt
    title Calder and Rowe programme timeline
    dateFormat YYYY-MM-DD
    section Foundations
    Discovery and cleanup :a1, 2025-01-06, 70d
    Okta hub and federation :a2, after a1, 45d
    section Waves
    IT department and pilot :b1, after a2, 21d
    Simple applications :b2, after b1, 60d
    Core business applications :b3, after b2, 90d
    Older protocols and gateways :b4, after b3, 80d
    Manufacturing division :b5, after b4, 60d
    section Closure
    Decommission four providers :c1, after b5, 60d
    

Questions that people ask most often when they begin consolidating identity providers.

Consolidating identity providers into Okta is a programme of discovery, design, careful migration, and disciplined shutdown.

We began with how organizations end up with many providers and defined the vocabulary. We examined possible end states, the business case, and the discovery of providers, applications, accounts, groups, and credentials. We designed the target and compared migration strategies, then looked at coexistence with Okta as a hub, routing rules, identity matching, attribute and group harmonization, and the movement of passwords and factors. We covered application migration by protocol, the mechanics of changing trust, sessions at cutover, provisioning, directories, customer identity, acquisitions, and policy harmonization. Then we turned to governance, communication, the help desk, testing, wave planning, decommissioning, transition security, monitoring, failure handling, cost realism, patterns, anti-patterns, trade-offs, and a worked example.