Zitadel vs Kanidm: when each one fits
If you are building customer logins for B2B products, Zitadel is the better fit. If you are running a workforce identity server for Linux desktops, servers and SSH, Kanidm is the one built for that job. The choice turns on whether you need SAML and multi-tenant organizations, or whether Unix integration, TPM-backed offline login and SSH key distribution are the priority. Zitadel is licensed under AGPL-3.0 with Zitadel v3 and offers a commercial license for teams that cannot accept AGPL terms. Kanidm is licensed under MPL-2.0, which carries file-level copyleft obligations that most internal deployments handle without difficulty; confirm the terms with your legal team against the Kanidm LICENSE.md file.
Four questions usually decide it. First, do your customers or partners bring their own identity providers, and does each customer need its own organization with separate users and roles? Zitadel organizations and per-organization identity provider federation are built for that. Second, must you integrate with SAML 2.0 applications? Kanidm does not list SAML among its features, and its maintainers steer users toward OAuth2/OIDC, then LDAP app passwords, with SAML as a last resort. Third, do your Linux hosts need login against the identity server, with offline authentication and SSH keys managed centrally? Kanidm lists those capabilities directly. Fourth, can your team accept a PostgreSQL dependency for Zitadel, or do you prefer Kanidm's own database and built-in replication?
Before you shortlist either platform, run a small pilot against your real applications and Linux hosts, and ask each vendor to confirm the features you depend on in writing, since product scope changes between releases. Check Kanidm's quarterly release cadence and its rule that upgrades are supported only from the previous minor version, and check Zitadel's supported PostgreSQL versions and your own backup plan. Price and effort depend on your scope, so ask for a fixed-scope quote from DeployOpen that lists each integration, the hosting model and the migration path if you later need to change platforms.
Zitadel vs Kanidm by scenario: customer identity or Linux estate
This table maps common scenarios to the platform that fits them better, based on the supplied facts about organizations, SAML, Unix integration, SCIM and passkeys. Read each row against your own user base, protocol requirements and host estate, and note the condition that could reverse the choice. The main takeaway is that Zitadel suits multi-tenant customer identity, while Kanidm suits workforce identity on Linux and SSH.
| Scenario | Better fit | Why, and when the other platform could still be right |
|---|---|---|
| B2B SaaS with customer-managed users | Zitadel | Zitadel organizations act like tenants inside one instance, so each customer can manage its own users. Kanidm is not built around that tenant model. Kanidm could still fit if the users are internal staff rather than your customers. |
| SaaS product that must offer SAML to enterprise buyers | Zitadel | Zitadel implements SAML 2.0 and each customer organization can use a different identity provider. Kanidm's SAML support is an open feature request, so confirm current status before relying on it. |
| Linux and SSH workforce | Kanidm | Kanidm provides Unix and Linux integration with TPM-protected offline authentication and SSH key distribution. Zitadel does not list these host-level features. Zitadel could still be right if the workforce mainly signs in to web applications. |
| Mixed estate with Active Directory or FreeIPA | Neither alone; confirm with your architect | Kanidm offers a read-only LDAPS gateway for legacy systems, and Zitadel can federate LDAP sources. Neither replaces a Windows or Kerberos domain, so FreeIPA or Active Directory may still hold the directory. Test how each integration handles your group structure. |
| App team needing passkeys with password fallback | Zitadel | Zitadel supports passkeys based on FIDO2 and WebAuthn with fallback to password login, and documents this for application logins. Kanidm also lists passkeys, including attested passkeys, so Kanidm could fit if attestation matters to your policy. |
| Team that needs a single server for identity, OAuth2 and host login | Kanidm | The Kanidm README states it aims to be a complete identity provider without other components alongside it. Zitadel's strengths sit in multi-tenant web identity, so it may need additional components for host login. |
| Team that wants an SQL database it already operates | Zitadel | Zitadel uses PostgreSQL 14 to 18, which your database team may already run. Kanidm uses its own database and replication, so it adds a store that your team must back up and monitor differently. |
How Zitadel and Kanidm are built and what that means for operations
Zitadel and Kanidm make different bets on where state lives and who runs it. Zitadel keeps its history in PostgreSQL as an event stream, while Kanidm ships its own database and replication. The cards below set out what each choice means for backups, staffing and the skills your team needs before go-live.
Event-sourced data in PostgreSQL
Zitadel stores every change as an event, which gives a built-in audit trail of all changes over an unlimited period. The event store sits in PostgreSQL, so your database team owns backup, restore and version tracking alongside the identity platform. Check whether your retention rules for the audit history match what the event store keeps, and who may read that history.
Instances, organizations and projects
Zitadel organizes tenants as instances with full data isolation, organizations inside instances where users live, and projects that group applications, roles and grants. This suits a B2B product where each customer manages its own users. For a workforce estate, the same hierarchy means your admins must learn which level owns a given policy before they create the first organization.
Three documented self-hosting routes
Zitadel documents self-hosting on Linux and macOS binaries, Docker Compose and Kubernetes, and recommends a Kubernetes cluster with the official Helm chart for high availability. Each route still needs a PostgreSQL instance. Choose the route your platform team can patch and back up on a fixed schedule, and confirm the image tags you will pin before the first deployment.
Kanidm's own database and replication
Kanidm does not use SQL as a database. It uses SQL as a durable key-value store and implements its own querying, indexing and eventually consistent replication, so no external database is required. Your team does not staff a separate database service for it, but backup and restore follow Kanidm's own procedures, which you should rehearse before you rely on them.
Two-node high availability
Kanidm provides two-node high availability through replication. That is a narrower resilience model than a clustered PostgreSQL deployment with multiple application replicas. Confirm your recovery time and failover expectations against it, and decide whether a two-node design meets the availability requirement your audit or service owners have set.
Mandatory TLS and CLI-first administration
Kanidm makes TLS mandatory for all connections rather than an optional feature added later. Administration is offered primarily through its CLI, with the web UI designed more for user interactions. Your administrators need to be comfortable with command-line workflows, and automation for user lifecycle changes will depend on that CLI.
Zitadel vs Kanidm side by side on SAML, passkeys and databases
This table sets Zitadel's multi-tenant identity platform against Kanidm's all-in-one identity server on the capabilities that most often decide the shortlist: protocols, passkeys, Unix and SSH integration, database model, high availability and tenancy. Where a row is not covered by the supplied facts, the cell tells you what to confirm with the vendor. Read it as a starting filter, then test the rows that matter for your estate.
| Capability | Zitadel | Kanidm |
|---|---|---|
| License | AGPL-3.0 for core, Console and hosted login since v3.0; APIs, SDKs, Helm charts and Terraform stay Apache 2.0 | MPL-2.0 |
| Standards protocols | OpenID Connect, OAuth 2.0, SAML 2.0 and SCIM v2 service provider interface | OAuth2 and OIDC with token exchange, RADIUS, read-only LDAPS gateway for legacy systems; SAML is not a listed feature |
| Passkeys | Passwordless login with FIDO2 and WebAuthn, with fallback to password login | WebAuthn passkeys including attested passkeys |
| Unix and SSH integration | Not listed in the supplied documentation; confirm with the vendor if Linux login is needed | Linux and Unix integration with TPM-protected offline authentication, plus SSH key distribution |
| Database | PostgreSQL 14 to 18 required for self-hosting | Own database using SQL as a durable key-value store, with built-in caching, indexing and replication; no external database |
| High availability | Helm chart on Kubernetes recommended for high availability; confirm the supported topology for your sizing | Two-node high availability through replication |
| Multi-tenancy | Instances hold virtual tenants with full data isolation; organizations inside instances hold projects and users | Single identity server model aimed at workforce and Linux estates; confirm how it fits multiple customer tenants |
| Federation | Google, GitHub, Entra ID, Okta, LDAP, Keycloak and any OIDC-compliant provider, with a different identity provider per organization | Administration centered on the CLI; confirm external identity brokering needs with the vendor |
How SAML and Unix integration change the decision
The first capability that often decides this comparison is SAML 2.0. Zitadel implements SAML 2.0 alongside OpenID Connect and OAuth 2.0, so it can serve SaaS applications and enterprise tools that accept only SAML assertions. Kanidm does not list SAML among its features. A GitHub issue proposing SAML was opened in August 2023 and is still open, and the maintainers direct users to OAuth2/OIDC first, LDAP app passwords second, and SAML only as a last resort. If a key vendor in your estate requires SAML, Kanidm is not a fit for that integration today. Before committing, list every application that will sign users in, check each vendor's documentation for OIDC support, and confirm with the Kanidm project whether SAML has moved since your evaluation.
The second capability is Unix and SSH integration. Kanidm lists Linux and Unix integration with TPM-protected offline authentication and SSH key distribution, so a fleet of servers can authenticate against one identity source and receive SSH keys from it. This matters when you run many Linux hosts, bastions or developer workstations and want account lifecycle and key rotation handled centrally. Zitadel does not present this as a feature of its own, so Linux host access would normally be handled by another tool. A team whose users reach mostly web applications through browser login may never use these features, in which case the Unix capabilities add little. To test this, inventory how many hosts need interactive or SSH logins, how many of them currently rely on local accounts or shared keys, and whether your operations team has a process for revoking keys when people leave.
What the licenses allow and what is paid for each platform
Zitadel uses a split license model. Its core, Console and hosted login are licensed under the GNU Affero General Public License 3.0, which moved from Apache 2.0 with Zitadel v3.0 on 31 March 2025. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain under Apache 2.0, so the components your teams call or deploy can usually be used under the more permissive terms. The repository's LICENSING.md also describes a commercial license that Zitadel offers as an alternative to AGPL-3.0.
- Core under AGPL-3.0: The identity server, Console and hosted login fall under AGPL-3.0. Review what the license requires before you run a modified build for users.
- Clients and deployment assets under Apache 2.0: SDKs, APIs and Helm or Terraform files are Apache 2.0, which simplifies integration and infrastructure-as-code work.
- Network use clause for SaaS teams: AGPL-3.0 extends source obligations to users who interact with a modified program over a network. A SaaS team that changes Zitadel code and offers it to customers may need to publish those changes, so involve counsel before customizing the core.
- Commercial license: LICENSING.md states that a commercial license is offered. The supplied facts do not describe its terms, so ask Zitadel what it covers, what it costs and whether it applies to your deployment.
- Support is not a license: Licensing governs use and modification. Ask separately what support, upgrade and escalation options Zitadel sells and what they cost.
Confirm with counsel whether your planned modifications, internal use or customer-facing use trigger AGPL-3.0 source obligations, and get the commercial license terms in writing before you rely on them.
Kanidm is licensed under the Mozilla Public License 2.0 (MPL-2.0), according to the LICENSE.md file in the kanidm/kanidm repository. MPL-2.0 is a file-level copyleft license. If you modify MPL-licensed source files and distribute the modified files, you must make those files' source available under MPL-2.0. You can combine MPL-licensed files with proprietary code in a larger work without relicensing the entire work, which is the main practical difference from a license that reaches the whole program.
- File-level copyleft: Changes to existing Kanidm source files stay under MPL-2.0 when distributed. Keep a record of which files you modified.
- Separate new files: New files you create that do not modify Kanidm files can carry your own license, subject to the MPL terms for the Kanidm code itself.
- No paid edition in the supplied facts: The supplied facts do not identify a paid Kanidm edition, a commercial license or a support subscription. Do not assume one exists.
- Confirm support directly: Ask the project which support channels, response expectations and maintenance commitments exist for your version. The support guidelines describe release and upgrade policy, but they are not a contract.
- Upgrade policy affects cost: Kanidm supports each stable release for four months and upgrades only from the previous minor version, so budget for regular upgrade work in your own environment.
Before you commit, ask Kanidm whether any commercial or contracted support exists, and have counsel confirm how MPL-2.0 applies to any changes your team plans to distribute.
What drives the running cost of Zitadel and Kanidm
Running cost for both platforms is driven less by licence fees than by who operates the stack and how often it must be upgraded. Zitadel is free to download under AGPL-3.0, but self-hosting it means a PostgreSQL instance (versions 14 through 18 are supported) plus the Kubernetes cluster and official Helm chart that Zitadel recommends for high availability, if you follow that path. Kanidm stores its data in its own database and replicates it natively, so the infrastructure line is a replicated Kanidm pair rather than a database service. Ask each vendor or partner to price the nodes, storage, backups and load balancing that your chosen topology needs, and to state whether the quote includes a second site.
Staff skills are the largest recurring cost, and the two platforms draw on different teams. Zitadel asks for people who can run Kubernetes, PostgreSQL backups and point-in-time recovery, and TLS termination in front of the identity provider. Kanidm asks for people who are comfortable with its CLI as the primary administration tool, with its web UI designed mainly for user interactions, and with Unix administration for the PAM and NSS integration that Linux estates rely on. Licensing adds a one-time review cost: AGPL-3.0 compliance review for Zitadel if you modify and offer it over a network, or a commercial licence quote if you cannot accept those terms, which Zitadel's licensing documentation describes. Kanidm's MPL-2.0 is a file-level copyleft, and most teams need only a short legal review.
Upgrade effort recurs, and Kanidm's calendar makes it predictable but unforgiving. Kanidm releases quarterly on February 1, May 1, August 1 and November 1, supports each stable release for four months, and upgrades only from the previous minor version, so 1.2.0 to 1.3.0 is valid but 1.2.0 to 1.4.0 is not. A team that falls two minor versions behind must step through intermediate releases, so budget for a quarterly upgrade window and test it on a replica. Zitadel's upgrade effort depends on your deployment method and image tag discipline. Ask any quote to separate one-time work (architecture, migration from existing directories, integration with applications) from recurring work (patching, upgrades, backup restore tests, on-call coverage), and to name who carries the pager for each.
Moving between Kanidm and Zitadel: what transfers and what is rebuilt
This sequence shows which parts of an identity estate move cleanly between Kanidm and Zitadel, which parts must be rebuilt on the target side, and how to cut over without losing a fallback path. It works in either direction, though the supplied facts document a migration path only into Zitadel.
Inventory every application and its protocol
The team that owns identity lists each relying party, whether it speaks OIDC, OAuth 2.0, SAML 2.0, LDAP, RADIUS or SSH key login, and who owns it. Kanidm covers OAuth2/OIDC, LDAPS for legacy systems, RADIUS and SSH key distribution, but SAML is not among its listed features, so any SAML application must be flagged now. The step is done when every application has one owner, one protocol and one target identity path recorded in a shared inventory.
Map users, groups and roles to the target model
Decide how existing accounts and groups land on the target side. In Zitadel, users and projects live inside organizations within an instance, and projects group applications, roles and grants, so Kanidm groups usually become project roles or grants. In Kanidm, Zitadel organizations collapse into groups and access rules. Document which attributes are carried over, which are dropped, and who approves the mapping. The output is a signed mapping table that the cutover team can test against a sample of accounts.
Rebuild OIDC clients on the target side
Each OIDC or OAuth 2.0 client is registered again on the target platform with its redirect URIs, scopes and token settings, and the new client identifiers and secrets are stored in the application owner's secret store. Client identifiers generally change, so applications need configuration updates even when their code does not. The step is complete when every OIDC client authenticates a test user in a non-production environment and the old client registrations are marked for retirement.
Rebuild SAML relying parties and directory integrations
SAML relying parties cannot be copied across platforms. If the target is Kanidm, SAML applications have no supported path in the supplied facts, so they need an alternative such as OIDC migration on the application side or a different component. If the target is Zitadel, SAML 2.0 is supported, but metadata, certificates and attribute mappings must be recreated and tested. Confirm LDAP and RADIUS client behavior, including any LDAP app passwords, with the vendor and your own applications. The check is a successful sign-in and attribute release for each SAML and directory consumer.
Plan credential handling for passwords and passkeys
Plan for passwords and passkeys to need re-enrollment unless the vendor confirms a secure transfer path for your versions. Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, including just-in-time migration, but the supplied facts contain no equivalent Kanidm import guide, so ask Kanidm and your implementation partner how credentials would move in your direction. Passkeys are bound to the platform that registered them, so users should be told in advance how to enroll again. The output is a written credential plan that names which users must act and what fallback they have.
Run a pilot with a representative user group
Move a small group of users and two or three applications that cover OIDC, LDAP or SSH access, and the SAML case if one exists. Testers exercise sign-in, password reset, passkey enrollment, group-based access and logout on both platforms. Record every failed step, its root cause and the fix. The pilot is done when the test cases in the plan pass for every protocol in scope and the owners of each application sign off in writing.
Cut over with a documented rollback window
Switch applications in batches, starting with the lowest-risk ones, and keep the source platform running with its data unchanged until every batch is stable. Define the rollback trigger, the person who can invoke it and the steps to restore the previous client configuration. Confirm the retention window for the source platform with your own change board, since the supplied facts do not set one for either product. The cutover is complete when all applications authenticate against the target, monitoring shows no unexplained failures, and the rollback steps have been rehearsed.
Retire the source platform and record evidence
After the rollback window closes, export audit logs and configuration snapshots from the source platform for retention, then decommission its clients, secrets and data stores under your change process. Keep the mapping table, pilot results and cutover records with the system's change documentation. The step produces a closed-out migration record that compliance reviewers and auditors can read, though DeployOpen prepares that evidence and does not issue any audit or certification outcome.
Where Zitadel and Kanidm projects usually run long
Zitadel projects most often slip at the design stage. The instance and organization model has to be settled before the first customer is onboarded, because in Zitadel each customer sits in an organization inside an instance, and changing that shape later means reworking projects, roles and grants. Each customer organization that brings its own identity provider needs its own federation configuration, test sign-in and claim mapping, so the work multiplies with the customer count rather than staying fixed. SCIM provisioning is the other common delay. Test the create, update and deactivate paths against each customer's directory before go-live, not after. On the infrastructure side, plan the PostgreSQL version (14 to 18 are supported for self-hosted Zitadel) and the Kubernetes and Helm configuration as one piece of work with a named owner for backups and upgrades.
Kanidm projects usually slip at the Unix and device layer rather than at sign-in. Group design needs to cover POSIX attributes for every Linux host that will rely on Kanidm, and those decisions are hard to undo once accounts are in use. TLS is mandatory for all Kanidm connections, so certificate issuance, rotation and trust distribution to every client should be scheduled as a workstream of its own. Offline login depends on TPM-protected credentials, which behave differently across laptop, server and virtual machine hardware, so test that matrix with real devices before committing to it. If legacy systems need the read-only LDAPS gateway, confirm early which bind and query patterns they use, because gateway behavior is often the last item closed.
For either platform, the client should provide named owners for identity design, directory and HR data, and operations, plus a test estate that mirrors production. Gather identity provider credentials and test accounts for every federated partner before work starts. Write sign-off criteria into the scope: which sign-in paths, provisioning events, device types and legacy clients must pass, and who accepts each one. Fixed-scope work is easiest to hold to a timeline when those criteria are agreed in writing, and a quote should price each of them explicitly.
Questions buyers ask before choosing Zitadel or Kanidm
Which one needs less effort to run day to day?
Kanidm usually asks for less moving parts, because it ships its own database layer and replication and does not need an external SQL server. Zitadel needs a PostgreSQL instance in every self-hosted deployment, supported on versions 14 through 18, and its high availability recommendation points to Kubernetes with the official Helm chart. The effort you actually carry depends on your estate: a single Linux team with a few applications will feel the difference differently from a multi-tenant SaaS platform with many customer organizations. Ask any implementer to list the components, backup targets and upgrade steps for your exact topology in the written scope before you compare totals.
What drives the implementation cost, and what should we ask for in a quote?
Cost follows scope more than product price. The main drivers are the number of applications and protocols to integrate (OIDC, SAML, SCIM or LDAP), the identity sources you must federate, how many tenants or customer organizations you run, Unix and SSH rollout across hosts, passkey policy, and the migration of existing users and credentials. Both platforms are open source, so the recurring cost is mostly your own staff time, infrastructure and any support contract you choose. Ask for a fixed-scope quote that lists each integration, each deliverable, the test and cutover approach, the documentation handover and the post-go-live support terms, all agreed in writing before work starts. DeployOpen does not publish a price list, so the quote comes from that written scope.
Can our own team run either platform without outside help?
It depends on your team's skills and how much of the platform you plan to own. A team that already runs PostgreSQL, Kubernetes or Linux identity services can operate Zitadel with the documented deployment options, and a team comfortable with the Kanidm CLI and Unix administration can operate Kanidm with fewer dependencies. Both need someone accountable for TLS, backups, restore testing and upgrades. Kanidm's administration is offered primarily through its CLI, so teams that expect a full graphical admin console should confirm that workflow before committing. DeployOpen implements, customizes, hardens, backs up, upgrades, documents and supports self-hosted platforms in your own infrastructure, and ongoing support is available as a retainer.
Can Kanidm replace Keycloak or Zitadel for a SAML-dependent SaaS product?
Not on the evidence available today. SAML is not among Kanidm's listed features, and the GitHub issue proposing SAML support, opened in August 2023, is still open. The maintainers direct users toward OAuth2/OIDC first, LDAP app passwords second and SAML only as a last resort. Zitadel implements OpenID Connect, OAuth 2.0 and SAML 2.0 and offers SCIM v2 provisioning, and Keycloak supports OpenID Connect, OAuth 2.0 and SAML 2.0. If your enterprise customers require SAML single sign-on, list every SAML integration they need, then test each one against the platform before you decide. Confirm the current status of the Kanidm SAML issue with the project directly.
What does the AGPL-3.0 license mean if we host Zitadel for customers?
Zitadel's core, Console and hosted login moved from Apache 2.0 to AGPL-3.0 with Zitadel v3.0 on 31 March 2025. APIs, SDKs, proto definitions, examples, documentation, Helm charts and Terraform configurations remain Apache 2.0. AGPL-3.0 has network-use obligations that can reach modified versions of the server you run for users over a network, so a hosted product should have its legal and licensing position reviewed by counsel before launch. Kanidm is licensed under MPL-2.0, which is a file-level copyleft license. Your legal team should confirm which obligations apply to your specific deployment and modifications. Ask Zitadel about its commercial license terms if AGPL-3.0 is not acceptable.
How hard is it to migrate from one platform to the other later?
Migration effort depends on what you move: user accounts and credentials, applications and their protocol configuration, group and role models, and Unix or SSH host settings. Zitadel documents migration guides from Auth0, Keycloak, Firebase and another Zitadel instance, using approaches such as just-in-time migration, which can reduce a one-time cutover. Kanidm has a different data model and Unix focus, so moving application registrations and Unix accounts is a separate project. Time depends on the number of applications, the credential types in use, and how many users must re-enroll passkeys. Ask for a migration plan in the written scope that covers rollback, a parallel run period and the testing of each application.
How does the upgrade cadence differ between Zitadel and Kanidm?
The cadences work differently, and the difference matters for planning. Kanidm releases quarterly, on February 1, May 1, August 1 and November 1, supports each stable release for 4 months, and supports upgrades only from the previous minor version, for example 1.2.0 to 1.3.0 but not to 1.4.0. That means you may need several small upgrade steps to catch up. Zitadel publishes releases on its GitHub releases page, with v4.19.5 released on 15 October 2026 as the current release at the time of writing. Check Zitadel's own support windows and upgrade path notes before you commit. Either way, a written upgrade runbook, a staging environment and a restore test should be part of the scope.
How DeployOpen helps choose, implement or migrate identity
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the choice between Zitadel and Kanidm is tested against your real estate before anything is built. We start from the workloads you need to authenticate, not from the feature list of either product.
How we scope
- We confirm whether the main workload is customer identity with many organizations or a workforce and Linux estate.
- We list the protocols each application needs, including whether SAML 2.0 is a hard requirement for any integration.
- We record the scope in writing before work starts, covering deliverables, timelines and the systems in scope.
- We identify which identity sources, such as LDAP, Active Directory or upstream OIDC providers, must be federated.
How we build
- We deploy the chosen platform in your cloud account, data center or air-gapped network, using the documented install method your team prefers.
- We configure PostgreSQL for Zitadel or confirm the embedded storage model for Kanidm, with backup and restore procedures tested.
- We integrate passkeys, Unix or SSH login, and application clients according to the agreed scope, then test each login path.
- We run security testing against the identity endpoints and document the findings and remediation.
How we hand over
- We deliver architecture notes, configuration records, runbooks and a record of the decisions taken during the choice.
- We train your operators on administration tasks, including the CLI-led workflows that Kanidm relies on and the console workflows used with Zitadel.
- We document the upgrade path for the chosen release line, including any constraints on skipping versions.
- We provide evidence and control documentation for your compliance assessors, who remain responsible for any audit outcome.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped in writing.
- We can review each new release against your configuration before you schedule an upgrade.
- We can help plan a migration if you later move between the two platforms or from another identity system, with the scope agreed in advance.
- A quote follows from the written scope, so we ask you to share your user counts, protocols and hosting constraints first.
