Introduction

An identity migration can move a SCIM service to a new domain or API path while Okta provisioning still sends create, update, or deprovision calls to the old endpoint. Sign-in can continue working, but lifecycle changes never reach the new service, one Okta app instance provisions correctly while another still targets the retired URL, or provisioning fails only after the old endpoint is removed because app settings, credentials, and provisioning templates often drift separately.

Treat this as a provisioning-target problem instead of a generic Okta outage. Start by checking which SCIM base URL an affected Okta app integration actually uses at runtime, because migrations often validate sign-on policy and user access first while account lifecycle traffic continues following the earlier provisioning path.

Symptoms

  • Okta SCIM provisioning still sends users to the old endpoint after migration
  • Sign-in works, but create, update, or deprovision actions never reach the new service
  • One app integration uses the new SCIM endpoint while another still uses the retired one
  • Provisioning failures start only after the old API path, domain, or credentials are removed
  • The new service is healthy, but Okta lifecycle events never arrive there
  • The issue started after moving an identity platform, SCIM connector, reverse proxy, or app domain

Common Causes

  • The Okta app integration still stores the old SCIM base URL
  • Provisioning credentials or OAuth settings were rotated, but the target endpoint itself was not updated
  • A duplicated app integration or test instance still owns production assignments
  • Attribute mappings, group push, or import jobs were updated for one app instance but not another
  • Automation or app templates keep recreating integrations with the retired provisioning endpoint
  • Validation confirmed the new service accepted manual API calls but did not verify where live Okta provisioning requests actually went

Step-by-Step Fix

  1. Capture one affected provisioning event and record the Okta app integration, SCIM base URL, authentication method, and assigned user or group flow it actually uses, because the live provisioning target determines where identity lifecycle changes really land.
  2. Compare that active provisioning path with the intended post-migration identity design, because one stale app integration can keep ongoing user management tied to the retired endpoint.
  3. Review Okta provisioning settings, sign-on versus provisioning separation, app duplicates, attribute mappings, group push configuration, and automation templates for references to the old SCIM service, because lifecycle traffic can remain misdirected even when authentication already uses the new platform.
  4. Check each production, sandbox, and cloned Okta app instance separately if behavior differs, because migrations often fix one integration while another still owns assignments and sends traffic to the previous endpoint.
  5. Update the authoritative SCIM base URL, credentials, and app assignment path so affected provisioning actions target the intended service, because rotating credentials or enabling provisioning alone does not retarget existing Okta integrations.
  6. Run a controlled create or profile update and confirm the intended SCIM service receives and processes the request, because a green provisioning status in Okta does not prove the right endpoint handled the change.
  7. Verify the old SCIM endpoint no longer receives user lifecycle traffic from the migrated integration, because split provisioning paths can stay hidden while both endpoints remain available.
  8. Review authentication scopes, TLS trust, rate limits, and import safeguards if provisioning still fails, because the destination can be correct while API trust or policy still blocks the new path.
  9. Document which team owns Okta app configuration, provisioning templates, and cutover validation so future SCIM migrations verify the actual runtime provisioning target before retiring the previous endpoint.