Introduction

An identity migration can move sign-in to the new platform while user provisioning still talks to the old SCIM endpoint. Logins may work normally, but new accounts fail to appear, deprovisioning never reaches the target system, or group updates keep going to the retired tenant because the provisioning connector was left behind during the cutover.

Treat this as a lifecycle-integration problem instead of a general authentication outage. Start by checking which SCIM base URL the active provisioning job actually calls, because identity migrations often update SSO first while user sync remains pinned to the previous endpoint.

Symptoms

  • Single sign-on works, but users or groups stop syncing after migration
  • New accounts are missing in the target application even though identity changes exist in the new platform
  • Deprovisioning still affects the old tenant or old environment
  • One provisioning app works while another still pushes updates to the previous endpoint
  • Provisioning logs show token, endpoint, or resource errors after migration
  • The issue started after moving identity platforms, tenants, or lifecycle management integrations

Common Causes

  • The provisioning connector still uses the old SCIM base URL for /Users or /Groups
  • A saved bearer token belongs to the retired tenant or previous application instance
  • The old provisioning app remained enabled while the new one was only partly configured
  • Group, role, or attribute mapping was migrated, but the live connector endpoint was not
  • Provisioning scope filters still target the wrong tenant, environment, or app instance
  • Validation focused on login success and skipped create, update, suspend, and deprovision lifecycle checks after the cutover

Step-by-Step Fix

  1. Capture one failed provisioning event and record the exact SCIM base URL, application, and error returned by the live sync job, because the active lifecycle path matters more than the configuration you expected to be in place.
  2. Compare that live endpoint with the intended post-migration SCIM target, because one stale base URL can keep every create, update, and deactivate action tied to the retired system.
  3. Review the provisioning app settings, SCIM connector configuration, and stored bearer token for any remaining reference to the old tenant or endpoint, because lifecycle integrations often keep their own credentials separate from SSO settings.
  4. Check whether more than one provisioning app, enterprise application, or environment mapping exists, because one old connector can remain enabled even after the new identity platform is live.
  5. Update the authoritative SCIM endpoint and token only after confirming the target application is ready to receive lifecycle changes, because pointing production sync at the wrong environment can create a larger access problem.
  6. Trigger a controlled provisioning change such as a test user update or group assignment and confirm it reaches the intended target, because saving the connector settings does not prove the live sync path is fixed.
  7. Verify the old endpoint no longer receives provisioning traffic, because duplicate or split lifecycle flows can leave one environment partially managed.
  8. Review attribute mappings, group scope, and deprovisioning rules if the endpoint is correct but results are still wrong, because migrations often fix transport while old lifecycle logic remains attached.
  9. Document which team owns SCIM endpoints, provisioning tokens, and lifecycle validation during future migrations, because user sync failures are easy to miss when sign-in testing passes.