DEV Community
Follow
Leaving self-hosted Duende: what migrates, and what you stop operating
Duende IdentityServer is a robust solution for owning your identity layer in .NET, but it comes with significant operational overhead. Self-hosting requires managing the IdP itself, including patching, scaling, and licensing, alongside building all surrounding functionalities like admin UIs, MFA, and audit logs. Many teams eventually decide to offload this operational burden, making migration a key consideration. The good news is that migrating from Duende is largely mechanical, as its configuration resides in SQL and users in ASP.NET Identity.
Clients, scopes, and users migrate across smoothly. Crucially, ASP.NET Identity V3 password hashes are natively supported, eliminating the need for user password resets, a common pain point with other IdP migrations. Roles, assignments, external logins, and OIDC identity providers also transfer directly, though SAML providers require re-configuration. Maintaining identity stability is paramount, so the migration preserves user 'sub' and 'client_id' to prevent breaking downstream dependencies.
The migration tool is rigorously tested against real, seeded Duende databases to catch subtle issues, like handling datetimeoffset for locked-out users, which would otherwise cause import failures. The primary benefit of moving is to stop operating an IdP and instead leverage included features for SAML, SCIM, MFA, audit logs, and custom branding, offloading patching and scaling responsibilities. If maintaining full control remains a priority, staying with Duende is a valid choice. However, for organizations seeking to reallocate time away from IdP operations, a smooth migration off Duende is a compelling option, offering a read-only preview to assess the import before committing.
