Migrating to another IAM provider without stopping authentication
Changing identity platform is a project that touches every business application, which is why it is rarely tackled head-on. The path to LoginMaster is built on open standards — SAML 2.0, OAuth 2.0 and OpenID Connect — and proceeds in phases: first map the scope, then validate in parallel, then migrate one application at a time with rollback always available.
Why organizations switch identity provider
The reasons that lead a European organization to reassess its IAM repeat with few variations.
Cost grows with your users
Per-active-user licensing ties IAM spend to organizational growth: every new employee, customer or test environment turns into recurring cost. LoginMaster bills per tenant and project, with unlimited users included.
Data sovereignty
With non-EU providers, identity data stays technically accessible to the vendor and subject to third-country regulation. In the Tenant-Cloud architecture personal data stays inside the customer Tenant, and the Cloud only handles encrypted, pseudonymized data.
Consolidation and unclear roadmaps
Acquisitions and mergers between IAM vendors put modules, price lists and support back in question. A single platform avoids redesigning access every time the vendor reshuffles its portfolio.
Technical lock-in
Proprietary authorization rules and non-standard SDKs make every change expensive. LoginMaster builds on SAML 2.0, OAuth 2.0 and OpenID Connect, with documented REST APIs and TypeScript and .NET SDKs.
The process in three phases
No big bang: the existing provider stays in service until the last application has moved.
1. Assessment of your current setup
We map the tenants, applications and access policies of your current provider, taking stock of every SSO integration and provisioning flow before anything moves. This is where proprietary customizations that need redesigning on open standards come to light.
2. Parallel pilot
LoginMaster runs side by side with the existing provider for a subset of users and applications. Authentication, MFA and provisioning get validated on real cases without touching the rest of the organization, which keeps working on the original system.
3. Phased cutover, application by application
Applications migrate one at a time, with rollback available at every step. There is no single switch moment: SSO and MFA stay live for the whole duration of the migration.
What actually moves in a migration
Four areas to put on the table before starting, each with a different degree of complexity.
SSO integrations
Federations built on SAML 2.0, OAuth 2.0 and OpenID Connect map across directly: the same standards your current provider exposes are the ones LoginMaster integrates on with Google Workspace and Microsoft Entra ID.
Users and access structure
User records, projects and roles are rebuilt inside the customer Tenant via REST APIs and official SDKs. The multi-project model lets you mirror the segmentation already in place without duplicating accounts.
Provisioning and lifecycle
Joiner, mover and leaver flows are ported onto REST APIs, SDKs and webhooks. Support for the SCIM 2.0 standard is on the platform roadmap.
Credentials and second factor
Where access is federated via SSO the question does not arise: users keep authenticating at their corporate identity provider. For directly managed credentials, the Argon2 and split-salt protection shared between Tenant and Cloud has to be factored into how user activation is designed: that is a point to settle together during the assessment.
For technical detail on the APIs, SDKs and webhooks used during the move, see the integration and developers page and the one on user provisioning and lifecycle.
Which platform are you migrating from?
Each path has a dedicated page with a point-by-point comparison and the specifics of the source platform.
Weighing several European options at once? The European IAM comparison brings the differences between EU-hosted platforms into focus.
Migration FAQ
The approach is designed to avoid it: LoginMaster runs alongside the existing provider during the pilot phase and applications move one at a time, with rollback available at every step. There is no single switch moment where authentication stops for everyone.
The dedicated comparison pages cover Auth0, Okta, Keycloak, Microsoft Entra ID, AWS Cognito, Firebase Auth, Ping Identity, ForgeRock, OneLogin, JumpCloud and ZITADEL. Since migration relies on SAML 2.0, OAuth 2.0 and OpenID Connect, the same path applies to providers not on the list that expose the same standards.
It depends on the number of integrated applications, how many proprietary policies need redesigning on open standards, and the availability of application teams for cutover. A realistic duration is set at the end of the assessment, once the scope is mapped: asking for an estimate before that point means working on assumptions.
Personal data resides inside the customer Tenant. The LoginMaster Cloud only operates on encrypted data and pseudonymous references, so not even the provider can read your users' identities. That is the substantive difference from a provider that hosts user records in its own cloud.
Yes, because several requirements become properties of the architecture rather than configurations to maintain: per-project configurable 2FA, cryptographic isolation per tenant, logs that plug into your SIEM, and dual-signature tokens. The detailed regulatory mapping is on the dedicated compliance page.
Let's start with theassessment
The first step is understanding what you actually run in production: integrated applications, access policies, provisioning flows. From there we build a plan with realistic timing.