The SME tenant migration trap: why your build-vs-buy auth forgot the data layer

Every SME custom software project hits the same crossroads: build authentication or buy a SaaS identity provider. The standard advice says buy. Login is solved, and you should focus on your core domain. We agreed, and shipped a multi-tenant platform on a popular auth SaaS within six weeks.

The Decoupling Trap

Our auth SaaS owned the user directory and group mappings. Our Postgres database owned the tenant-scoped rows. When a user logs in, the SaaS issues a JWT with custom claims listing their assigned tenant IDs. Our API middleware trusts those claims to filter queries.

This works cleanly when tenants are static. When you need to migrate 4,200 users from tenant A into tenant B, the SaaS becomes a liability. You cannot just update a foreign key. You must orchestrate a parallel migration across two separate systems with different consistency guarantees.

The Inconsistency Window

We ran the migration on a Sunday. The Postgres side took eleven minutes: a standard UPDATE on the tenant foreign key, validated and committed. The auth SaaS side took four hours of batched API calls. Their rate limits capped us at 10 requests per second per tenant.

During those four hours, the system was inconsistent. Users already migrated in Postgres still carried old tenant claims in their active JWTs. They queried the API and saw permission denied on data they legally owned. We had to force a global session revocation to resolve it.

Build-vs-buy auth debates focus on the login form, MFA, and password resets. For SME platforms, the real cost is data ownership. When your authorization boundaries leak across a network call into a third-party system, any bulk change becomes a distributed transaction problem.

Co-locating Authorization

If we had built a thin auth layer on top of our own database, the tenant migration would have been a single transaction. Eleven minutes, zero inconsistency, zero revocations. The trade-off is maintaining password hashing and session management. For most SMEs, that is a small price for data sovereignty.

We still use the SaaS for OIDC federation and MFA. But we decoupled authorization. The SaaS authenticates the user. Our database authorizes them. The JWT now carries a user ID only. Every request pays one extra database query to resolve permissions, adding 4ms to p99 latency.

That 4ms latency tax is the honest cost of keeping your authorization data co-located with your business data. It eliminates an entire class of consistency failure modes. You can migrate, split, or merge tenants without orchestrating network calls to a third-party API.

Before you buy an identity SaaS for your multi-tenant platform, map out the migration scenarios. If changing a tenant boundary requires distributed coordination between your database and their API, you have not solved auth. You have just deferred a production incident.