IdentityServer4 → Duende Migration Checklist

IdentityServer4 has been end-of-life since December 13, 2022. If it still signs your tokens, this checklist is the shortest path to a supported, patched identity platform. It is the same sequence we run in client migrations — work through it top to bottom, and treat every unchecked box as deployment risk.

1. Inventory your current IdentityServer4 deployment

You cannot scope a migration you haven’t measured. Before touching packages:

• List every client (application) registered in your IdentityServer, including grant types and redirect URIs.
• List every API scope and API resource, and which clients consume them.
• Identify custom grant types, custom IProfileService implementations, and custom validators — these are where migration effort concentrates.
• Locate your persisted grant store (EF Core operational store, custom store, or in-memory) and note its size.
• Document your signing key material: where keys live, how they rotate, and which clients cache discovery documents.
• Record your current .NET runtime version — Duende IdentityServer versions have minimum .NET floors that may force a runtime upgrade first.

2. Choose your Duende license

Duende IdentityServer is source-available but requires a paid license for production use in most companies.

• Check whether you qualify for the free Community Edition (revenue and usage limits apply).
• Otherwise compare paid tiers against your client count and feature needs (the BFF framework, dynamic providers, and CIBA sit in higher tiers).
• Verify terms and current pricing at duendesoftware.com — thresholds change; don’t budget from third-party posts.
• Budget the license as a recurring cost alongside the migration effort, not as an afterthought.

3. Migrate the packages and code

• Replace the IdentityServer4 packages with Duende.IdentityServer and update namespaces — for standard setups this is the bulk of the code change.
• Upgrade to the minimum .NET version your target Duende release requires, and run your existing test suite before changing any identity code.
• Re-apply customizations deliberately: custom grant validators, profile services, CORS policies, and token lifetime overrides all deserve a line-by-line review against the new defaults.
• Rebuild from the official Duende templates if your IdentityServer4 host accumulated years of drift — a clean host with your configuration ported in is often safer than an in-place upgrade.

Doing this under deadline? We run this exact checklist as a fixed-scope Migration Sprint — assessment, code and data migration, compatibility testing, and hardening, from $9,600.

4. Migrate the data

• Apply the operational-store schema migrations for your target Duende version — persisted grants, device codes, and keys have evolved since IdentityServer4.
• Decide what to carry over: long-lived reference tokens and refresh tokens usually must migrate; short-lived grants can often be allowed to expire naturally during cutover.
• Move signing keys intentionally. If you rotate keys as part of the migration, remember that clients cache discovery documents — publish the new keys before retiring the old ones.

5. Test client compatibility

The silent breakages live here, not in the compiler output:

• Validate every grant flow you actually use — authorization code + PKCE, client credentials, refresh tokens — against a staging Duende instance.
• Diff the discovery document (/.well-known/openid-configuration) between old and new instances; changed endpoints or claims surface here first.
• Compare issued tokens field-by-field: claim names, claim formats, token lifetimes, and audience values. Stricter defaults can change what downstream APIs receive.
• Re-test logout and session management — front-channel and back-channel logout behavior is a common post-migration surprise.

6. Plan cutover and rollback

• Prefer a parallel deployment: run Duende alongside IdentityServer4, cut clients over in groups, and keep the old instance warm until the last client moves.
• Define an explicit rollback trigger (error-rate threshold, failed client count) and rehearse the rollback at least once in staging.
• Schedule cutover inside a low-traffic window and freeze client-configuration changes for its duration.
• Keep token lifetimes in mind: a rollback after hours of issuing Duende-signed tokens means those tokens must remain valid — or be revoked — under the old instance’s keys.

7. Harden post-migration

• Confirm automatic key rotation is configured (Duende manages this natively — verify, don’t assume).
• Review logging: token issuance events should be auditable without leaking token contents.
• Remove IdentityServer4 packages, dead configuration, and the old deployment once the rollback window closes — an idle EOL token server is an attack surface, not a backup.
• Put the Duende upgrade cadence on your roadmap: staying one major version behind is how the next “IdentityServer4 situation” starts.

---

Last verified against Duende IdentityServer v8 in July 2026. If you’d rather hand this list to someone who has run it before, start with an $80 assessment session — it scopes your migration and counts toward the sprint price if you proceed.