Migrate SSO without customer reconfiguration

Single Sign-On (SSO) isn't a monolithic authentication problem—it's a modular capability that evolves differently than the rest of your auth infrastructure.

Here's how it usually goes: You built on AWS Cognito because it was there, it was easy, and it worked. Your first enterprise customer asked for SSO. You configured it. Then another. By the fifth one, you're thinking "there has to be a better way to do this." Or maybe you started with Auth0 when you had 10 enterprise customers, and now at 50 customers their per-connection pricing is making your CFO wince every time they review the bill. You don't want to rip out your entire auth system—your password flows work fine, your MFA is solid—you just need SSO to make economic sense.

SSO should be modular. Swap it out like you'd swap any other dependency. Simple, right?

Except it's not. Because SSO isn't just code on your end.

Every single one of your enterprise customers has someone in IT who carefully configured their Okta tenant or Azure AD to talk to your app. They added your Entity ID (auth.yourapp.com), plugged in your callback URL, uploaded certificates. It probably took them three tries to get it right because of a trailing slash somewhere. They documented it. They moved on with their lives.

Now you want to change providers. Which means every one of those carefully configured setups needs to change. New Entity IDs. New callback URLs. New certificates.

You know what happens next: scheduling calls across time zones and change freeze windows. Walking someone through SAML configuration while they share their screen and you pray they don't typo the URL. Coordinating deployments with customers who need board approval for infrastructure changes. And when something breaks—because something always breaks—entire organizations lose access to your app.

One team told us they got through 23 migration calls before giving up and staying on their expensive provider for another two years. The migration cost was just too high.

How SSO actually works (and why migration is painful)

Quick sidebar on why this is so complicated: SSO works by establishing trust between your application (Service Provider) and your customer's identity system (Identity Provider). That trust is built on predetermined parameters.

For SAML, it's Entity IDs, callback URLs, and certificates. For OIDC, it's Client IDs, Redirect URIs, and Discovery endpoints. Your customers configure these once in their IdP. From then on, authentication flows smoothly—users log in through their IdP, assertions flow to your app, everyone's happy.

The problem? All those parameters are tied to your current provider. To switch, every customer needs new values. And you can't automate that—each customer must manually update their IdP, which means coordination, testing, and deployment windows on their side.

‍

The better way: migrate without touching customer configs

We built a migration approach that eliminates customer-side reconfiguration entirely. Through DNS redirection and smart proxying, you can move from Auth0, WorkOS, Firebase, or AWS Cognito to Scalekit while your customers' IdP settings stay exactly the same.

The DNS redirect layer: Your auth domain (auth.yourapp.com) already points to your current provider. Add a lightweight proxy that examines each authentication request and routes it to the right place.

Smart organization mapping: Keep a simple mapping of who's migrated and who hasn't. The proxy checks it on every request.

Transparent routing: When someone logs in, the proxy sends migrated organizations to Scalekit and unmigrated ones to your old provider. Same login flow, same experience, zero user-visible changes.

Preserved IdP configuration: Scalekit accepts the same Entity IDs and callback URLs your customers already configured. Their SAML or OIDC responses flow through the proxy to Scalekit exactly as they did before.

How it actually works

Let's say you're ExampleCorp with 50 enterprise customers on Auth0. Everyone's configured their IdP to send SAML assertions to auth.examplecorp.com/saml/callback.

Step 1: Configure Scalekit to accept the same Entity ID and ACS URL that Auth0 uses. When a customer's IdP sends a SAML response, Scalekit processes it with the exact parameters already in their IdP.

Step 2: Deploy a lightweight proxy at your auth domain. We provide ready-to-use implementations for AWS Lambda, Cloudflare Workers, or your existing infrastructure.

Step 3: Route authentication requests. When someone from acmecorp.com logs in, your app initiates SSO as usual. The proxy checks the mapping and routes to the right provider.

Step 4: Handle IdP responses. After authentication, the SAML response returns to auth.examplecorp.com/saml/callback. The proxy examines it, sees it's from a migrated org, and forwards it to Scalekit.

Step 5: Complete authentication. Your callback handler exchanges the authorization code for user details—exactly as before, just from a different provider.

Migrate at your own pace

Here's the best part: you control everything. Migrate one organization at a time. Test thoroughly. Roll back instantly if something's off. No coordination calls. No implementation meetings. No customer-side changes.

Start with internal test accounts. Move a few friendly customers. Gradually work through your customer base at whatever pace makes sense—days, weeks, months. Both providers run in parallel the whole time. Once everyone's moved, remove the proxy and point your auth domain straight to Scalekit.

Ready to migrate? Talk to our team or check out our migration documentation.

‍