Which open-source option replaces Auth0 Organizations for B2B tenants
If your B2B SaaS team uses Auth0 Organizations to give each customer its own members, roles and login connection, the two main self-hosted candidates are ZITADEL organizations and Keycloak Organizations. The right choice depends on how deep your tenancy model goes, whether each customer needs its own identity provider, and what shape your tokens must take for the applications that consume them. This is a module-level replacement, not a full Auth0 replacement, so the rest of your login stack (social connections, Actions, MFA and SDKs) needs its own mapping.
ZITADEL organizes tenants as instances, organizations inside instances, and projects that group applications, roles and grants. Each customer organization can federate login with a different identity provider, which lines up closely with the Auth0 Organizations pattern of one connection per customer. Keycloak handles the same need through realms and its Organizations feature, so the question is whether one realm per product with organizations inside it fits your customer count and isolation requirements. Before you commit, confirm with each vendor how organization-level IdP configuration, domain verification and role claims appear in the access and ID tokens your APIs validate, since claim names and nesting are where migrations usually break.
Run a small proof of concept with two or three representative customers. Include one customer on an external OIDC or SAML provider, one with a per-organization role model, and one that depends on a custom claim. Check whether your resource servers can read the organization and role data from the token as you expect, and whether your provisioning path (for example, SCIM 2.0 in ZITADEL or the equivalent Keycloak integration you choose) keeps memberships in step with your own system of record. Ask both vendors and your integration partner to confirm these behaviors in writing against your target version, and plan for the token changes your applications will need to accept during cutover.
Mapping Auth0 Organizations capabilities to ZITADEL and Keycloak
This table maps the Auth0 Organizations features that B2B SaaS teams rely on to the closest ZITADEL and Keycloak options, with notes on where the match is direct and where it needs design work. Read each row as a starting point for a proof of concept, since exact claim names and feature behavior should be confirmed against current documentation and your own test tenant.
| Capability | ZITADEL option | Keycloak option | Coverage notes |
|---|---|---|---|
| Organization membership | Users belong to organizations inside an instance, and projects and users live within that organization structure | Organizations feature with members assigned to each organization within a realm | Both models support per-customer membership. Confirm whether a user can belong to several organizations in your design, since Auth0 Organizations allows it. |
| Organization-level roles | Project roles and grants can be scoped to an organization, so applications see role assignments per tenant | Realm and client roles are assigned to users, with organization membership used to scope access in your application logic | ZITADEL's grant model maps closely to per-customer roles. In Keycloak, confirm how organization-scoped roles are modeled in your version and whether your app must enforce them. |
| Per-organization enterprise connections | Each customer organization can use a different identity provider, including OIDC, SAML, LDAP and Entra ID or Okta | Identity providers are configured per organization in the Organizations feature, with brokering to customer IdPs | Both can route each customer to its own IdP. Test the full login path with a real customer IdP, including just-in-time user creation and attribute mapping. |
| Domain-based login routing | Organization domains and login hints can direct users to the correct organization and identity provider | Organization domains can route a user by email domain to the matching organization's identity provider | Confirm the exact routing behavior, including how shared or unverified domains are handled. Domain verification steps are part of the design, not automatic. |
| Organization metadata | Custom metadata can be attached to organizations through the API, and Actions or metadata can feed tokens | Organization attributes can be stored and read through the Admin API or custom mappers | Keycloak typically needs custom attributes or a mapper to surface metadata in tokens. Confirm the supported attribute model in your release. |
| Organization-scoped admin delegation | Organization managers and administrator roles can be granted within one organization without instance-wide rights | Organization-level administration is available for delegated management, with fine-grained admin permissions in the admin console | Delegation models differ in detail. Document which customer admins may manage members, connections and roles, then test that boundary. |
| Token claims carrying organization context | Tokens can carry organization identifiers and role claims. Confirm the exact claim names and whether they appear in access or ID tokens | Organization information can be included in tokens through protocol mappers. Confirm the claim names and mapper configuration for your release | Auth0 uses its own namespaced claims. Expect to rewrite token validation and claim parsing in each application, and confirm the final claim names in your environment. |
When ZITADEL or Keycloak fits B2B tenancy
Auth0 Organizations give each customer its own members, roles and login connection. ZITADEL and Keycloak model that same need with different building blocks, so the first decision is where each customer boundary should sit. The cards below cover the main choices and the mistakes to avoid when moving them.
ZITADEL organizations inside an instance
In ZITADEL, an instance is a virtual tenant with full data isolation, and organizations sit inside it, holding the users and projects for one customer. Projects group applications, roles and grants, so a customer organization can be granted access to a shared application without copying it. The check to make: confirm whether each customer needs its own instance for isolation, or whether an organization boundary inside one instance is enough for your data and admin model.
Keycloak Organizations inside a realm
Keycloak keeps tenants in realms, and its Organizations feature lets a realm hold many B2B customers, each with its own members and identity provider. Clients and roles are shared across the realm, which simplifies operating one application for many customers. The trade-off is that a realm is also the main security boundary, so customers who need separate signing keys, admin teams or user stores usually point toward separate realms.
One instance or realm versus many
Keeping one ZITADEL instance or one Keycloak realm for all customers reduces the number of components to patch, back up and monitor. Separate instances or realms add isolation and let each tenant have its own configuration, but every extra boundary adds an admin surface and a configuration to keep in sync. Ask who administers each customer, whether any customer needs data residency in a specific region, and how often tenant settings will change.
Risk of one-to-one mapping
Copying each Auth0 organization into a new tenant object, with its own connections, roles and rules, often recreates Auth0's sprawl in a system with different defaults. Auth0 Actions and Rules logic, custom roles and per-organization connections should be reviewed for what still applies, then grouped into shared projects and roles. Treat the migration as a redesign of tenancy, and document which grants each customer should hold before importing any members.
Per-customer identity providers
Both platforms let a customer bring its own identity provider, such as Entra ID, Okta or a SAML provider, so its staff log in with their corporate account. ZITADEL documents that each customer organization can use a different identity provider, and Keycloak brokers per-organization connections in the same way. Confirm which customers use SAML, which use OIDC, and whether any rely on SCIM provisioning, since each path needs its own test and attribute mapping.
Token claims and tenant context
When a user signs in, the token must carry enough context for each API to know which customer the user belongs to, and that context changes when the tenant model changes. Organization and role claims in ZITADEL and Keycloak do not match Auth0's names, so every API that reads an org or role claim needs an updated mapping. Ask your team to list each claim your services read, then test a token from each tenant type before cutting traffic over.
How ZITADEL instances, organizations and projects model tenants
ZITADEL splits tenancy into three levels, and mapping them correctly is the first design decision in an Auth0 Organizations migration. An instance is a virtual tenant with full data isolation, so users, policies and configuration in one instance cannot be read from another. Inside an instance, organizations hold the users and projects that belong to one customer or business unit. Inside an organization, projects group the applications you ship, the roles those applications define and the grants that assign those roles to users. Decide early whether each customer gets its own organization inside a shared instance, or whether a regulated customer warrants its own instance. Isolation at the instance level is stronger, but it also means more instances to configure, back up and upgrade.
Per-customer login is handled at the organization level. Each customer organization can federate sign-in with a different identity provider, such as a customer's Entra ID tenant over OIDC or SAML, an Okta organization, or an LDAP directory. This is the closest equivalent to an Auth0 enterprise connection assigned to an Organization. In Auth0, the many organizations in one tenant share the tenant's connections, rules, actions and tenant-level settings, and the separation between customers depends on how those are configured. In ZITADEL, the separation is structural, so a customer's identity provider and its users sit in that customer's organization by design. Confirm with the ZITADEL documentation how login policies and branding are scoped to each organization before you promise customers that their configuration is independent.
Before you map existing Auth0 organizations one to one, list which settings you actually vary per customer. Identify the role names your applications check, the grants each customer should receive, and whether any customer needs its own instance because of contractual or data residency terms. A useful test is to create two sample organizations with different identity providers in a non-production ZITADEL instance and confirm that a user from one cannot see the other's projects or sign in through the other's provider. The exact token claims that carry organization and role information should also be checked against your application's token validation logic, since that code is what breaks first during cutover.
What changes in tokens and in your application code
Organization context reaches your application as claims inside the tokens, so the token layout is the first thing to check. In Auth0, organization context normally arrives in the ID token and access token as an org_id claim, and your code reads it to decide which customer's data to load. ZITADEL and Keycloak carry the same idea in different places: ZITADEL places organization information in its own claim namespace inside the token, while Keycloak's Organizations feature exposes membership through its own mapper configuration and realm settings. Claim names, claim locations and the audience values differ between the three, so an application that checks Auth0's org_id directly will not find the equivalent value without changes. Confirm the exact claim names, whether each is in the ID token, the access token or both, and how the audience is set in the vendor documentation for your chosen product before you write any code.
The most reliable way to plan the change is to capture real tokens. Create a test organization in your target platform, add one member with a role and one with no role, and sign in as each user with the same client your production app uses. Decode the ID token and the access token, then record every claim that identifies the organization, the roles and the permissions, along with its exact name and value type. Repeat the test in your current Auth0 tenant so you have a side-by-side table. Pay attention to whether roles appear as a flat array or nested under a namespace, and whether an organization identifier is a stable internal ID or a slug that can change. Those differences decide whether your existing authorization checks can stay in place or need rewriting.
Application code that reads organization claims must be updated in the same release as the identity switch, not after it. Search your codebase for every reference to Auth0 claim names, Auth0 namespaces, the organization parameter in login requests and any middleware that validates the audience. Replace each reference with the target platform's claim, then run regression tests that log in as members of at least two different organizations and confirm that each user sees only their own data. Plan a dual-validation period if you need to accept tokens from both issuers during cutover, and make sure that period has an end date. Some of this work depends on how your tokens are validated, so verify the issuer, audience and signing key handling with your security team before rollout.
Per-customer domains, identity providers and SCIM provisioning
How does domain-based routing send a customer's users to their own login?
In ZITADEL, a verified domain on an organization lets the login page recognize users by their email suffix and route them to that organization's login policy and identity providers. Keycloak has no organization-level domain routing of its own in the features described here, so teams typically build it with a home-realm discovery step in a thin login front end or in their application, mapping the email domain to the correct realm or identity provider. Confirm with each vendor's current documentation which routing behavior your chosen version provides, and test the flow with a user from each customer domain before go-live.
How is a customer's Entra ID or Okta connection set up for one organization?
Each option lets you register the customer's Entra ID or Okta application as a federated identity provider, scoped to one tenant or organization, so only that customer's users see the button or redirect. ZITADEL documents that each customer organization can use a different identity provider over OIDC or SAML, and it also supports Entra ID and Okta as provider types. In Keycloak, you create an identity provider per realm or per organization, depending on the model you choose. The customer supplies the redirect URI, client ID and secret or certificate, and you must confirm the attribute and claim mappings during a test login.
Does ZITADEL support SCIM 2.0 user provisioning?
Yes. ZITADEL provides a SCIM v2 service provider interface for standardized user provisioning and lifecycle management, so an identity provider such as Entra ID or Okta can create, update and deactivate users automatically. Confirm which SCIM resources and attributes your version supports and how the endpoint is scoped to a single organization. Plan a test with one customer directory first, because deprovisioning behavior is where mismatches usually appear.
Can Keycloak provision users over SCIM 2.0 for each customer?
Confirm this before you commit to a design. The Keycloak documentation covered for this topic describes OpenID Connect, SAML 2.0, identity brokering and user federation with LDAP and Active Directory, but it does not establish a built-in SCIM 2.0 server. Teams that need SCIM with Keycloak usually evaluate a community extension or a separate provisioning service, and they should ask whether that component is supported for their Keycloak version. Budget for the extension's maintenance and upgrade testing as a recurring cost, and check how it maps customer groups to Keycloak roles.
How are custom domains such as login.customer.com handled?
A custom login domain is a DNS and TLS task layered on top of the identity server. You point a CNAME record at your reverse proxy or load balancer, issue a certificate for that hostname, and configure the identity server's external URL and allowed redirect URIs so tokens and cookies are issued for the custom host. ZITADEL and Keycloak both expect the public hostname to match their configured issuer, so changing it later can break existing sessions and client configurations. Confirm the exact hostname configuration steps for your version, and plan certificate renewal in your operations runbook.
Can a customer's admin manage their own members and roles?
Partly, and the answer depends on how you model delegation. ZITADEL places users, projects and grants inside organizations, so you can grant an organization-level administrator role to a customer's staff for their own members, while your platform team keeps control of instance-wide settings. Keycloak can delegate some administration through realm roles and fine-grained permissions, but a self-service portal for customer admins usually has to be built or assembled by your team. Confirm the exact delegation rights in each product, and decide whether customer admins may change login policies or identity providers, since those settings carry security risk.
What does it cost to build per-customer routing and provisioning?
Costs fall into three groups: the one-time design and build of routing, customer identity provider onboarding and any SCIM integration; the recurring work of testing each new customer's connection; and the platform cost of running the servers, PostgreSQL and high availability. Work grows with the number of customer identity providers, the number of distinct SCIM integrations and the support load when a customer's directory changes. Ask any implementation partner for a written scope that lists each customer onboarding step, the extensions you will maintain, and who handles upgrades. DeployOpen provides fixed-scope engagements agreed in writing before work starts, with pricing quoted from that scope.
Migrating organizations, members and roles from Auth0
This sequence moves each Auth0 customer organization, its members, roles and enterprise login connections into a self-hosted tenancy model, one customer at a time, so every customer can be verified before the next one moves. The result is a tested mapping and a repeatable cutover runbook.
Export users and request password hashes
Run the bulk user export job from the Auth0 Dashboard or the Management API (POST /jobs/users-exports), choosing NDJSON or CSV output. Password hashes are not included in standard exports, so on a paid plan submit a support ticket to request the hash export. Auth0 does not guarantee a delivery date, and the option is not available on the Free tier, so confirm your plan and open the request early. Done when you hold a complete user file and either the hash file or a documented decision to force password resets for those users.
Inventory organizations, members and connections
Using the Management API, list every Auth0 organization, its members, the roles assigned to them, and the enterprise or social connections enabled for each organization. Record which connection belongs to which customer, along with the domains and login settings each one uses. Owned by the platform team with input from the customer success lead, this produces a spreadsheet or JSON inventory. Done when every organization in production appears once, with a named owner and a connection list that matches the Auth0 dashboard.
Model the target tenancy
Decide how the inventory maps to the target system. In ZITADEL, customers usually map to organizations inside one instance, with projects holding applications, roles and grants. In Keycloak, the usual approach is one realm for the product, with its Organizations feature for per-customer membership and identity providers. Write down which Auth0 concepts become which target objects, and where each customer's data and policies live. Done when the mapping document is signed off by the engineering and security leads and covers every object type in the inventory.
Recreate roles, grants and identity providers
Build the target projects, applications, roles and grants from the mapping, then recreate each enterprise connection as an identity provider attached to its customer organization. Confirm that each identity provider only serves its own customer's domains. Auth0 Actions that enrich tokens need to be rewritten in the target platform's extension model, so list them separately. Done when a test organization can sign in through its recreated identity provider and receive the expected roles in its token.
Import users into each organization
Import users one organization at a time, using the exported files and, where obtained, the password hashes. Check which hash algorithms the target platform can verify before importing, and plan forced resets for any hash it cannot verify. Keep the import scripts idempotent so a rerun does not duplicate members. Done when the count of members per organization matches the Auth0 inventory and a sample of accounts can sign in.
Run a pilot organization
Choose one low-risk customer organization and move its members and login connection through the full runbook while Auth0 remains live. Have the customer's administrators test sign-in, role-based access, SSO logout and any token claims their applications read. Record every discrepancy and fix the mapping or scripts before the next move. Done when the pilot customer has completed a documented test run with no open access defects.
Cut over each customer and retire Auth0 access
Move the remaining organizations in batches, each with a scheduled window agreed with the customer, updating application configuration so the customer's domain points to the new login. Keep Auth0 read-only as a fallback until each organization has signed in successfully on the new platform. Retire Auth0 only after the final organization has been verified and the export files are archived under your retention policy. Done when every organization signs in on the target platform and the cutover log records each move.
Running Auth0 and the new identity server side by side during cutover
Cutover for B2B customers rarely happens in one step, so the application has to accept tokens from two issuers for a period of time. Plan this as a per-customer switch: each customer organization moves when its users, its identity provider connection and its application configuration are ready, and the rest stay on Auth0. In practice that means the application needs a mapping from each token's iss claim to the correct issuer, JWKS endpoint and expected audience, and that mapping has to be keyed to the customer organization. Confirm with the vendor documentation how each platform sets the issuer for an organization or instance, because the issuer format is what your validation code will match on. Do not assume that a single validation library setting covers both issuers without testing it against real tokens from each side.
Redirect and callback URIs need the same care. Each application client on the new server needs its own allowed redirect URIs, logout URIs and web origins, and any Auth0 callback that still serves a migrating customer must stay registered until that customer is fully moved. Watch for customers that reach the same application through a custom domain or a different hostname, because a missing URI on either side produces a login error that looks like a configuration fault rather than a cutover fault. Keep a single register of which URI belongs to which customer and which system, and remove Auth0 entries only after a documented check that no traffic still uses them.
Token validation during the switch is where mistakes carry the most risk. Tokens issued by each side should be accepted only for the audience and scopes the application expects, and the application should reject tokens whose organization claim does not match the session it is serving. Test a customer's sessions that are already open at the moment of cutover, along with refresh tokens and logout, because those cross the boundary in ways a simple login test does not show. Plan the retirement date for the Auth0 path before you start, and keep the dual-issuer code small so it can be removed. This dual-running period usually lasts longer than the team expects, so budget for the engineering and support time it consumes.
Cost components of running B2B tenancy yourself
Replacing Auth0 Organizations moves the per-tenant bill onto your own infrastructure and staff. The cards below separate what you pay once, such as building provisioning and admin tooling, from what recurs, such as databases, high availability capacity and upgrades.
Database and infrastructure
ZITADEL and Keycloak both store tenant, user and session data in PostgreSQL, and the supported range for each is listed in the vendor docs. Recurring costs are the database instances, storage, backups, compute for the identity nodes and network egress. Ask your team what a second region or a standby database adds, since those costs grow with each tenant you host. Confirm the exact supported PostgreSQL versions against the version you deploy before you size anything.
High availability design
Production login must survive node failures, so you pay for redundant nodes and a database that replicates synchronously. Keycloak documents three cluster designs, and its supported multi-cluster options each need that synchronous replication. Recurring cost rises with the number of sites and the failover testing you schedule. Ask for a written failover test plan as part of any quote, because an untested cluster is an unpriced risk.
Organization provisioning and admin tooling
Auth0 Organizations give you a console for members, roles and connections. Self-hosted, you build the onboarding flow that creates each organization, attaches its identity provider and domain, and assigns roles. This is largely one-time engineering, followed by recurring maintenance each time your customer model changes. Ask for the provisioning scope, the admin screens you need and who will own them after handover.
Upgrades and operator update approval
Keycloak plans four minor releases a year, and the Operator documentation strongly recommends manual approval for operator updates to avoid unplanned upgrades. Each upgrade needs a staging test, a database schema check and a rollback plan, which makes it recurring work. Decide who approves upgrades and how often you test them, and ask any implementation partner whether that retainer is included or billed separately.
Support and the Auth0 spend that stops
Self-hosted ZITADEL and Keycloak are open source, so you pay no per-user license fee, but support comes from a vendor contract, a partner retainer or your own on-call engineers. The Auth0 monthly active user charges and any Organizations or enterprise connection add-ons end when cutover finishes. Ask your current Auth0 account team for the contract end date and any notice period, then compare that against the support cost you add.
Questions buyers ask before replacing Auth0 Organizations
How much effort does replacing Auth0 Organizations take?
The effort depends mainly on how many customer organizations you have, how many use their own enterprise identity provider, and how many Actions or Rules run during login. Each customer organization needs its members, roles and connection rebuilt in ZITADEL organizations or as a Keycloak Organizations setup, so the count of tenants and connections drives the work more than the user count does. Application changes depend on how closely your code follows Auth0's SDKs. Ask any implementation partner to list every organization, connection, custom login step and application in writing before estimating, because those inventories are what determine the scope.
How long does a migration from Auth0 Organizations usually take?
Duration is set by the number of customer organizations to move, the number of identity provider connections to recreate and test, the number of applications to repoint, and how many login flows need rebuilding. Data export is usually the shortest step, because Auth0 can bulk export users in NDJSON or CSV through the Dashboard or the Management API. Testing each customer's login path and running a cutover without disrupting their members usually takes the longest. Neither Auth0 nor the open-source projects publish a fixed timeline for this work, so ask for a duration tied to a written list of organizations and connections, and confirm the dates with the vendor or partner.
Can our own team migrate from Auth0 Organizations without outside help?
A team with experience running a stateful service, PostgreSQL administration and OpenID Connect can often handle a small, single-region migration alone. The harder parts are a production-grade deployment, high availability, backups, upgrades and per-customer connection testing, which together make up most of the ongoing work. Keycloak requires a synchronously replicated database for its supported high availability designs, and ZITADEL recommends Kubernetes with the official Helm chart for high availability. Decide early which of these you will own, and whether you want a fixed-scope engagement for the migration and a retainer for ongoing operations.
What skills and time do our engineers need for this work?
Your engineers need to understand OpenID Connect, OAuth 2.0 and, for some customers, SAML 2.0, plus enough database and container operations knowledge to run the identity service. Application developers must update SDK calls, token validation and role checks, and your support team needs a runbook for customer login issues. Plan for engineers to review the token claims and roles their apps read, because those are where most integration bugs appear. Ask your partner or vendor which skills their deliverables assume, and what your engineers must sign off on before cutover.
Do user passwords carry over from Auth0 Organizations?
Passwords carry over only if you obtain the password hashes, and Auth0 does not include them in standard user exports. On paid plans you request the password hash export through a support ticket, and Auth0 does not guarantee a delivery date. The option is not available on the Free tier, so confirm your plan before you plan the cutover. If the hashes do not arrive or cannot be imported, the alternatives are just-in-time migration, where users log in once and the identity service verifies them against the old system, or a password reset flow. Zitadel documents just-in-time migration as one of its approaches, so check the fit for your user base with the vendor.
Do tokens change for our applications after moving off Auth0 Organizations?
Yes, the token issuer, audience and claim names change, so every application that validates tokens needs review. Auth0 tokens carry its own issuer URL and organization claims, while ZITADEL and Keycloak issue tokens from their own issuers, and organization or role information appears under different claim names. Both products implement standard OpenID Connect, which makes the switch to standard OIDC libraries simpler, but the claims your code reads are still specific to each product. Keep a table that maps each Auth0 claim to its ZITADEL or Keycloak equivalent, and test a token from each customer organization before you switch traffic.
What does a fixed-scope engagement with DeployOpen cover?
A fixed-scope engagement covers the deliverables, scope and timeline agreed in writing before work starts. For an Auth0 Organizations migration, the written scope typically lists the platform to deploy in your infrastructure, the organizations and identity provider connections to rebuild, the applications to integrate, the data export and import steps, the testing, the documentation and the handover. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. DeployOpen does not publish a price list, and a quote follows from the written scope. Ongoing support, upgrades and continuous testing are available as retainers.
Does DeployOpen issue compliance certificates for our identity platform?
No, DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. For a customer identity platform, the evidence you assemble often includes access reviews, configuration baselines, logging of administrative actions and documented backup and restore tests. Ask your auditor which evidence they expect before the migration starts, so those records are captured during the work rather than rebuilt afterwards.
How DeployOpen scopes and delivers an Auth0 Organizations replacement
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source identity platforms inside your own cloud accounts, data centers or air-gapped networks. For Auth0 Organizations, that means turning your tenant model, per-customer connections and token claims into a written scope before any build work starts.
How we scope
- Inventory which Auth0 organizations, members, roles and enterprise connections your application depends on today
- Decide whether each customer maps to a ZITADEL organization inside an instance or to a Keycloak realm or organization, and record why
- Agree the scope, deliverables and timelines in writing before work starts, since engagements are fixed-scope by default
How we build
- Configure per-customer identity providers and verified domains, then test login for each connection type in a staging environment
- Rebuild the claims your APIs read from tokens so organization and role data arrives in the same shape the application expects
- Run security testing against the new login and token flows, and harden the database, TLS and admin access before go-live
How we hand over
- Document the tenant model, connection settings, token claim mappings and the steps to onboard a new customer organization
- Provide backup and restore procedures, including how the database and identity configuration are captured and tested
- Walk your platform and security teams through upgrade steps and the runbook so operating the platform stays in your hands
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover
- Retainers can cover version upgrades, patching of the database and cluster, and review of new customer connections
- Ask any provider to confirm in writing which upgrade, monitoring and incident response tasks sit inside the retainer and which are billed separately
