Introduction

An app migration can move the live site successfully while SAML single sign-on still posts the login response to the old domain. Users may reach the new application homepage without trouble, but the identity provider continues sending assertions to a retired Assertion Consumer Service endpoint because the SAML configuration was never updated after the cutover.

Treat this as an SSO endpoint-alignment problem instead of a general authentication outage. Start by checking the exact ACS URL used during the SAML response flow, because one stale hostname in IdP settings or service provider metadata can keep authentication tied to the previous domain after the rest of the app has already moved.

Symptoms

  • SAML login sends users or assertions to the old domain after app migration
  • The identity provider login works, but the final sign-in step fails on callback
  • Users see SSO errors only after authentication is handed back to the application
  • The new app loads normally, but SAML-based login still reaches the retired hostname
  • One identity provider connection works while another still uses the old ACS endpoint
  • The issue started after app migration, domain change, or single sign-on reconfiguration

Common Causes

  • The identity provider still stores the old ACS URL for the application
  • Service provider metadata still advertises the previous callback domain
  • The entity ID, reply URL, or SSO application settings were copied forward without updating the live endpoint
  • Multiple SAML apps or environments exist, and production still uses the wrong one
  • Teams validated local login or page access but skipped the full SAML callback path after migration
  • The old domain remained reachable long enough to hide the stale ACS configuration

Step-by-Step Fix

  1. Reproduce the SAML login failure and capture the final destination used for the assertion or callback, because you need the real ACS target before changing identity settings.
  2. Compare the live ACS URL with the intended post-migration domain, path, and HTTPS scheme, because SAML endpoints are strict and even a small mismatch can break login.
  3. Check the identity provider configuration for the affected SAML app and review the reply URL, ACS URL, and any related sign-in endpoints, because the stale domain often remains on the IdP side after a domain move.
  4. Review the service provider metadata and application-side SAML settings as well, because the app may still publish or expect the old callback URL even if the IdP was partly updated.
  5. Confirm that production is using the correct SAML application, certificate set, and environment mapping, because a staging or legacy enterprise app can silently keep the old domain active.
  6. Update the real ACS URL and related SAML endpoint settings only after confirming the new domain is fully ready for sign-in traffic, because changing the wrong environment can create a wider outage.
  7. Retest the full SAML login flow from the identity provider through the application and verify the response lands on the new domain, because a saved config edit does not prove the live SSO path is fixed.
  8. Review additional SAML connections, subdomains, or branded login apps if more than one configuration exists, because migrations often fix one identity flow while another still posts to the legacy domain.
  9. Document the final ACS URL, entity ID, and IdP/SP ownership after recovery, because SAML settings are easy to miss during future app or domain migrations.