Migrate from Auth0 to Ory: what the move involves and who does it
Teams that want to self-host customer login and stop paying per monthly active user can move from Auth0 to Ory, but the move is feasible only for user passwords obtained through Auth0's support process, and Ory is a set of headless APIs, so the login UI, social and enterprise connections, and Actions logic become your own work. Ory does not give you a finished login product. Kratos handles identities, credentials and flows, Hydra issues OAuth 2.0 and OpenID Connect tokens, and everything a user sees on screen is built by your application team. In practice the work is usually run by a small group: platform engineers for hosting, databases and upgrades, security engineers for hashing policy, MFA and token lifetimes, and application engineers for the login pages, SDK changes and session handling. The Auth0 export is only the start. Each Auth0 Action, rule, custom database script and enterprise connection must be mapped to an equivalent in Kratos, Hydra or your own code, and each mapping is a decision with a security consequence. Confirm early which Auth0 features your tenant actually uses, because that inventory sets the effort and risk far more than the user count does.
Ask for a written scope before work starts, and confirm three things with the vendor or your own environment: whether your Auth0 plan includes the password hash export, how long your support request is likely to take, and which hash formats Auth0 will provide. Ory documents support for several hash formats, but unsupported formats fall back to a password migration webhook that you must build and operate. Plan for a period when users may sign in through both systems, and decide whether you will migrate passwords in bulk or let users move over at their next sign-in. Keep the Auth0 tenant available until you have verified login, token issuance and account recovery end to end. The main recurring costs after cutover are the people and infrastructure that run Kratos, Hydra and their database, plus the security patch cycle. Open-source Ory is suited to evaluation, development and deployments that accept occasional upgrade downtime and do not require guaranteed CVE patching. If your organization needs SAML, SCIM, organization SSO or multi-tenancy, check the Ory Enterprise License documentation before you commit, because those features are not part of the open-source servers.
Which Auth0 capabilities map to Ory, and which need rework
This table maps Auth0 capabilities to Ory Kratos, Hydra, Polis and Keto, and marks each as clean, needs rework or gap. Read the status column first, then the notes on where SAML, SCIM, organization SSO and multi-tenancy sit in the Ory Enterprise License rather than the open-source servers. The main takeaway is that the user store and password hash import are the most portable parts, while the login UI, Actions logic and enterprise features need planning before cutover.
| Auth0 capability | Ory equivalent | Status and notes |
|---|---|---|
| User store and profiles | Ory Kratos identities | Needs rework: export users as NDJSON or CSV, then map traits and metadata to a Kratos identity schema. |
| Password login with existing hashes | Ory Kratos import with hasher | Clean for BCrypt and Argon2; other formats verify at sign-in and rehash. Unsupported formats need a password migration webhook. |
| Social login | Ory Kratos social sign-in | Needs rework: recreate each provider and client configuration in Kratos. Confirm provider coverage with Ory. |
| Multi-factor authentication (TOTP) | Ory Kratos MFA | Clean: TOTP is supported. Enrollment of existing factors is not automatic, so plan re-enrollment with users. |
| Passkeys | Ory Kratos passkeys | Clean for new enrollments. Confirm migration of existing Auth0 passkey credentials with Ory before relying on it. |
| OIDC and OAuth 2.0 clients | Ory Hydra | Needs rework: register each client in Hydra and point SDKs at standard OIDC endpoints. Hydra is OpenID Certified. |
| SAML and enterprise SSO | Ory Polis, Enterprise License for some features | Gap for SAML and organization SSO in the open-source servers. Confirm the Polis and Enterprise License scope with Ory. |
| SCIM directory sync | Ory Polis, Enterprise License for some features | Gap in the open-source Kratos. Confirm whether Polis covers your provisioning flow before cutover. |
| Organizations and multi-tenancy | Ory Kratos organizations (Enterprise License) | Gap in open source: Kratos multi-tenancy and organizations are Enterprise License features. Confirm licensing before design. |
| Actions and Rules | Custom services behind Kratos and Hydra hooks | Needs rework: no direct equivalent. Rewrite logic as webhooks or application code and test each flow. |
| Fine-grained authorization (FGA) | Ory Keto | Needs rework: model relations as Zanzibar-style tuples. Keto is a separate service you must run and back up. |
What data leaves Auth0 and which integrations must be rebuilt
Auth0 keeps user profiles, password hashes and tenant configuration in different places, and each one leaves through a different path. The cards below separate the bulk user export from the password hash request and the configuration you must recreate in Ory and your own login UI.
Bulk user export job
The Dashboard or the Management API create export users job (POST /jobs/users-exports) produces user profiles in NDJSON or CSV. Use this file for identifiers, emails, verification status, metadata and linked identities. Check the output against a sample account before the full run, because the export does not contain passwords. Confirm which fields your Ory identity schema needs so the file maps cleanly on import.
Password hash export by ticket
Auth0 does not include password hashes in standard exports. Paid plans can request them through a support ticket, and the option is not available on the Free tier. Auth0 does not guarantee a delivery date, so open the request early and plan the cutover around its arrival rather than a fixed day.
Hash formats Ory can verify
Ory Kratos imports hashes in BCrypt, Argon2, MD5, SHA, SSHA, SSHA256, SSHA512, PBKDF2, SCrypt, Firebase SCrypt, crypt(3) and HMAC formats. For formats other than BCrypt and Argon2, Kratos verifies the hash at sign-in and then moves the user to the configured hasher. Identify the exact algorithm and parameters Auth0 returns before you build the import mapping.
Password migration webhook fallback
If the hash format you receive is not on the Kratos list, the import documentation points to a password migration webhook. Your team then needs a service that verifies the old hash against a supplied credential and hands the result back to Kratos. Scope this work early, because it is custom code that you own, test and retire after the last legacy user signs in.
Application OIDC settings and login pages
Client IDs, redirect URIs, allowed logout URLs, token lifetimes and scopes do not travel with the user export. Ory Hydra handles OAuth 2.0 and OpenID Connect, while Kratos leaves the login and registration screens to you. Recreate each application's settings in Hydra and build the login, recovery and verification UI that replaces Auth0 Universal Login.
Social, enterprise connections and Actions logic
Auth0 social and enterprise connections, email templates and Actions or Rules logic are tenant configuration, not user data. Rebuild each connection as an identity provider brokered through your own components, and port Actions logic to code you run. Confirm early whether SAML, SCIM and organization SSO are open-source features or Ory Enterprise License features, since that changes the scope.
How the migration runs from inventory to decommission
This sequence moves Auth0 customer identity to self-hosted Ory in stages, so each application and each user group is proven to log in before Auth0 is switched off. Every step produces a written artifact that a security reviewer, an application owner and your own change board can check.
Inventory applications, flows and hash formats
Start by listing every Auth0 application, API, connection and Action or Rule that handles login, sign-up or token issuance, and record which applications depend on which connection. Export the user population with the Dashboard or the Management API export job, then ask Auth0 support for the password hash export on your plan and confirm the hash algorithm in the response. Compare those algorithms with the formats Ory Kratos can import, noting which hashes need the password migration webhook instead. The output is an inventory register with one row per application, flow, connection and hash format, reviewed by the application owners.
Build the Ory environment and login UI
Deploy Ory Kratos and Ory Hydra in your own infrastructure on a supported database such as PostgreSQL, and place them behind your standard TLS, logging and backup controls. Your engineers or DeployOpen's team build the login, registration, recovery and MFA screens against the Kratos flow APIs, since Ory does not ship a hosted login page. Confirm which Ory release line you will pin and whether your team needs the Ory Enterprise License for features such as organizations or SAML. The output is a tested staging environment and a documented decision on open source versus enterprise features.
Pilot with a test user set and one application
Import a test user set into Kratos, including a few accounts for each hash format you plan to migrate, and connect one low-risk application through Hydra using standard OpenID Connect. Verify that sign-in succeeds with the original password, that the hash is upgraded to the configured hasher after first use, and that MFA enrollment and password recovery work. Measure token claims against what the application expects. The output is a pilot report listing test cases, failures, claim differences and the fixes applied.
Run a parallel period with Auth0 as source of truth
Keep Auth0 as the system of record while the pilot application and a small group of real users sign in through Ory. Route new sign-ups through Auth0 during this period and have a named reviewer check a sample of new accounts and login events for both systems. Track password resets and profile changes so you know which copy of each user is current. The output is a parallel-run log with discrepancy counts, reviewed and signed off by the identity owner before the next application is moved.
Prepare the cutover runbook and rollback plan
Write a cutover runbook that lists the order of application switches, the final user export and import, the DNS, redirect URI and client secret changes, and the owner for each action. Define the rollback trigger and the steps to point applications back to Auth0, and confirm that Auth0 remains available until the rollback window closes. Because Kratos verifies supported hashes at sign-in, agree in advance how users who have never signed in will be handled. The output is an approved runbook and rollback plan with named approvers.
Cut over with migration on first sign-in
During the approved window, import the remaining users with their hashes, switch each application's OIDC configuration to Hydra and Kratos, and monitor failed sign-ins, token errors and support tickets. Users with supported hash formats move to the configured hasher on their first successful sign-in, while unsupported formats rely on the password migration webhook you built and tested. Keep an eye on users who never return, since their accounts will remain in the old format until they do. The output is a cutover log and a count of migrated accounts, with each application confirmed working.
Decommission Auth0 after evidence of working logins
Once the monitoring period in your runbook ends and logins have been stable across all applications, disable Auth0 applications and connections, then retire the tenant according to your data retention policy. Store the final export, hash inventory, pilot report, parallel-run log and cutover log as evidence for your compliance team, and remove any Auth0 secrets from your vault and CI systems. Confirm with your auditors which artifacts they need, since DeployOpen prepares evidence but does not issue audit opinions. The output is a decommission record and an updated inventory showing Auth0 retired.
What drives the cost and duration of an Auth0 to Ory move
This table lists the components that determine how much work and recurring effort a move from Auth0 to self-hosted Ory involves. Read each row as a question to answer in your own environment before requesting a quote. The main takeaway is that hash format coverage, Actions logic and the login UI usually matter more than the user count.
| Driver | Why it changes cost or effort | How to keep it down or what to confirm |
|---|---|---|
| Applications and OAuth clients | Each client needs its redirect URIs, scopes, token settings and SDK switch to standard OIDC against Ory Hydra, so the count sets testing volume. | Inventory every client in the Auth0 tenant and retire unused ones before migration. |
| Password hash formats | Ory Kratos imports BCrypt and Argon2 directly and verifies other listed formats at sign-in. Unsupported formats need a password migration webhook that you build and operate. | Ask Auth0 which hash format your tenant uses, then confirm it against Ory's supported list before requesting the hash export. |
| Hash export request | Password hashes are not in standard exports. Paid plans request them by support ticket, with no delivery date guaranteed, and the option is not available on the Free tier. | Open the ticket early, and confirm eligibility and delivery terms with Auth0 in writing. |
| Actions logic to port | Auth0 Actions and any legacy Rules run custom code during login and token issuance. Ory has no direct equivalent, so each hook must be rewritten as application logic, webhooks or Hydra consent handling. | List every Action by trigger, and classify each as token claim, pre-registration, MFA or external call. |
| Login and registration UI | Ory Kratos is API-first and leaves the login UI to you, so screens, error states, account recovery and verification flows are built by your team or partner. | Decide early whether to reuse existing branding and which flows (sign-up, recovery, MFA prompts) must match current behavior. |
| MFA and passkey enrollment policy | Kratos supports TOTP, passwordless codes and passkeys. Enrollment rules, step-up triggers and recovery for lost devices add design and test work per user group. | Write the enrollment policy per segment, and test recovery paths before cutover. |
| Database and high availability | Kratos runs on PostgreSQL, MySQL or CockroachDB, with SQLite suited to testing. Production clusters, backups, failover and monitoring are engineering work that recurs. | Confirm which database your platform team operates, and ask for the high availability design, backup and restore tests in the quote. |
| Open Source or Enterprise License | Ory Open Source suits evaluation and deployments that accept upgrade downtime without guaranteed CVE patching. The Ory Enterprise License adds SAML, SCIM, organization SSO and multi-tenancy, with 24/7 support SLAs and timely CVE patches. | Map each required Auth0 feature to Open Source or Enterprise License, then get licensing terms from Ory in writing. |
| Recurring patching and upgrades | Ory releases new versions (Kratos and Hydra v26.2.0 were both published on March 20, 2026). Each upgrade needs regression testing of login flows, and Open Source upgrades may require downtime. | Ask who owns the upgrade calendar, testing and rollback, and whether a retainer covers it. |
What usually goes wrong and how to prevent it
Most failed Auth0 to Ory migrations come from a handful of gaps: hashes that never arrived or cannot be verified, login screens that were never fully built, and downstream systems that were not told about changes. Each card below names one failure and the check that prevents it before cutover.
Users locked out after import
Standard Auth0 exports do not contain password hashes, and hash export is a support request on paid plans with no guaranteed delivery date. Without the hashes, users must reset passwords on first sign-in. Ask Auth0 for the hash export early, then confirm that the hash format is one Ory Kratos can verify, either natively (BCrypt and Argon2 are imported directly) or through a password migration webhook for unsupported formats. Test a sample of real accounts end to end before cutover.
Login UI missing recovery and MFA
Ory Kratos is API-first and provides no hosted login pages, so every flow your users rely on must be built by your team. Password reset, email verification, MFA enrollment with TOTP, passkey registration and account recovery are separate flows that often ship last. Before cutover, list every Auth0 screen your users saw, map each to a Kratos flow, and test recovery for users who have lost their authenticator.
Token claim changes breaking apps
Hydra issues tokens with its own issuer, subject and claim set, so applications validating Auth0 tokens will see different iss and aud values and may lack custom claims that were added through Auth0 Actions. Inventory every relying party, record the claims each one reads, and reproduce those claims in your Hydra token hook before switching application SDKs. Run a staging test against each app.
Social and enterprise logins not recreated
Auth0 social connections and enterprise SSO connections are tenant configuration, and a user export does not carry them. Each Google, Microsoft or SAML connection must be rebuilt in your Ory setup, and enterprise SAML, SCIM and organization login are Ory Enterprise License features rather than open-source capabilities. Confirm with Ory which of these you need before design starts, and check that the identifiers linked to existing accounts still match so users are not duplicated.
Assuming open-source CVE patching
Ory describes Ory Open Source as a fit for evaluation, development and deployments where occasional upgrade downtime is acceptable and guaranteed CVE patching is not required. Production identity systems that handle customer credentials need a patching owner, a test environment for each Kratos and Hydra release, and a documented upgrade window. Decide whether you need Ory Enterprise License support with timely CVE patches and 24/7 SLAs, and get that answer in writing before go-live.
How the move differs by starting point and scale
This is the case where the password hash plan matters most. Users who signed up with an email and password will be asked to sign in again on Ory unless you carry their hashes across. Start with the bulk user export job, which produces NDJSON or CSV files of profiles, but remember that standard exports do not include password hashes. The hashes come only through a separate support ticket, and only on paid plans. Ask Auth0 for that ticket early, because delivery is not guaranteed on any date.
- Export scope: Run the export job for the whole tenant and confirm that every user record has an email address, a verification flag and any custom metadata you need.
- Hash request: Submit the password hash export ticket before cutover planning is final, and record the format Auth0 returns.
- Hash import: Ory Kratos can verify BCrypt and Argon2 hashes directly, and it verifies other supported formats at sign-in before moving each user to the configured hasher.
- Login UI: Build password sign-in, registration and recovery screens against the Kratos flow APIs, since Kratos does not ship them.
- Fallback path: If a hash format is not supported, plan a password migration webhook rather than forcing resets for the whole base.
Before you commit, confirm the hash format with Auth0 and test a sample import against a non-production Kratos instance.
A B2B tenant on Auth0 carries more state than a flat user list. Organizations group members, roles and per-customer connections, and that structure does not travel in the user export. The export gives you users and their organization memberships as data to re-create, while Ory has no built-in Organizations model in the open-source servers. Kratos organization login and multi-tenancy are Ory Enterprise License features, so the decision on tenancy comes before the import.
- Membership data: Export users with their organization associations and map each one to a tenant identifier in your own schema.
- Per-customer login: Enterprise SSO connections per organization are not part of the open-source Kratos server, so confirm whether you need the Enterprise License for them.
- Hash plan: Member hashes follow the same support ticket route as consumer users, so the ticket covers the whole tenant.
- Authorization: Organization roles usually become permissions in Ory Keto or in your application code, and that model needs designing before import.
- Login UI: Each customer may expect a branded sign-in path, which adds screens and routing to your application.
Ask Ory which features your tenancy model needs and whether they fall in the open-source servers or the Enterprise License.
Auth0 Actions often hold business rules that run during login, such as enriching tokens, blocking accounts, calling internal services or migrating users on first sign-in. None of that logic is exported with users. Ory Hydra and Kratos do not run Actions, so each Action has to be reviewed, classified and rebuilt in your own services. The migration effort depends on how much behavior lives in those scripts, so inventory them before you plan the work.
- Inventory: List every Action by trigger, such as post-login, pre-user-registration or post-change-password, and note the external calls it makes.
- Token claims: Rebuild claim enrichment in the service that issues or consumes tokens, and test the resulting claim shape against each application.
- Hooks and webhooks: Kratos offers webhooks and hooks at flow stages, which can host some logic, but each hook is code you operate.
- User migration logic: A lazy migration Action that checks a legacy store on login maps to a Kratos import or a password migration webhook.
- Secrets: Credentials used by Actions must move to your secrets manager, not into configuration files.
If Actions contain logic you cannot explain, treat that as a finding to resolve before cutover, not after.
Some tenants have users who sign in only through Google, Microsoft or other social providers and never set a password. These users do not need a password hash, so the support ticket and hash import can be dropped from their plan. What they still need is a stable link between the external identity and the new Kratos identity, so that sign-in resolves to the same account and the same application data.
- Identity linking: Map each social subject identifier to a Kratos identity so existing accounts resolve on first sign-in.
- Social providers: Kratos supports social sign-in, but you register each provider's client credentials in your own configuration.
- Email verification: Confirm which social accounts carry verified emails, since account linking depends on that attribute.
- Mixed tenants: Many tenants mix social and password users, so split the export by login method before deciding which users need hashes.
- Login UI: Social buttons still need a page in your application, even though the provider handles the password step.
Confirm with Auth0 which connection each user came through, because that field determines whether a hash request is needed at all.
Questions teams ask before moving from Auth0 to Ory
Will users keep their passwords after moving from Auth0 to Ory?
Yes, if you obtain the password hashes from Auth0 and Ory can verify the format they are in. Auth0 does not include hashes in standard user exports. Paid-plan customers request them through a support ticket, and Auth0 does not guarantee a delivery date. Ory Kratos can import BCrypt and Argon2 hashes directly and can verify several other formats at sign-in, moving each user to the configured hasher after a successful login. If the hash format is not supported, Ory's import documentation points to a password migration webhook, which your team would build and test. Without hashes, users must reset their passwords, so plan a communication and fallback path for that case.
What does the Auth0 export and hash request involve?
The bulk export is a job you run from the Auth0 Dashboard or the Management API, producing NDJSON or CSV files of user profiles. The password hash export is a separate request made through Auth0 support, available only on paid plans. Your team needs to confirm which hash formats the tenant uses, store the exported files encrypted and restrict access to them, and check that the record count matches the tenant. Ask Auth0 directly what the process and timing look like for your tenant, because the vendor does not guarantee a date. Start that request early, since the migration cannot complete until the hashes arrive. The Auth0 bulk export documentation describes the export format.
How much work is the login UI when moving to Ory?
Ory Kratos is API-first and does not ship a hosted login page, so your team builds the login, registration, recovery, verification and MFA screens. The effort depends on how many flows you need (passwords, passkeys, social sign-in, TOTP), how many applications share the login, how much you match the existing Auth0 Universal Login branding, and how many languages and accessibility requirements apply. Each flow also needs error handling and security review, such as rate limiting and account recovery abuse checks. Teams that already run a front-end framework and design system usually scope this as the largest workstream after the data move. Ask for the list of flows and screens in writing before estimating.
Can our in-house team run this migration without outside help?
A team with experience in OAuth 2.0, OpenID Connect, database operations and front-end development can complete the work in-house, but the gaps usually appear in the hash migration, token and session behavior, and the cutover plan. Consider whether your engineers have built a password migration webhook, tested account recovery at scale and planned a rollback. Outside help can be scoped as a fixed-scope engagement covering planning, implementation, hardening and documentation, with the deliverables and timelines agreed in writing before work starts. DeployOpen plans, implements, customizes, integrates, hardens and documents self-hosted platforms inside your own infrastructure. Compare that scope against the skills and capacity you actually have.
What does Ory Enterprise License add for SAML and organization SSO?
The Ory Kratos README lists SCIM, SAML, organization login (SSO), and CAPTCHAs as enterprise features not available in the open-source version. The Ory Enterprise License adds these along with Kratos multi-tenancy and organizations, the Hydra ROPC grant, 24/7 support SLAs and timely CVE patches. If your Auth0 setup uses enterprise connections or per-customer SAML, budget for the license as a separate recurring cost and confirm pricing and terms directly with Ory, since this page does not give figures. Open-source Ory covers OpenID Connect and OAuth 2.0 well, so the decision depends on how many customers need SAML or organization-level SSO.
What ongoing work does a self-hosted Ory platform need after cutover?
Running Ory is a recurring operations job, not a one-time project. Your team owns the database (Ory Kratos supports SQLite, PostgreSQL, MySQL and CockroachDB), backups and restore tests, high availability, monitoring, certificate rotation and secrets. It also owns upgrades: Ory publishes new versions regularly, and open-source deployments may need downtime during upgrades, which Ory describes as acceptable only where occasional downtime is tolerable. Security patching is your responsibility unless you hold the Enterprise License. Plan for on-call coverage, a patch cadence and a runbook, and consider a support retainer for continuous testing and upgrades.
Does Ory fit regulated use, and what must we verify before cutover?
Ory provides the identity components, but compliance outcomes depend on your configuration, logging, data location and evidence. Before cutover, confirm which data Auth0 retains and whether exported records and hashes are deleted from your staging environments after import. Verify MFA enrollment, session lifetimes, password policy and audit logs in your environment. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Ask your assessor which controls they expect to see evidenced for customer identity.
What DeployOpen does in an Auth0 to Ory engagement
DeployOpen plans, implements, integrates, hardens, backs up and documents a self-hosted Ory deployment inside your own cloud account, data center or air-gapped network. The work is agreed as a fixed scope with written deliverables and timelines before it starts, so the decisions that drive effort are made up front: which Auth0 applications move, whether Ory Kratos identities need a custom password migration webhook, which login flows are rebuilt, and whether Ory Enterprise License features such as organizations or SAML are required. A quote follows from that written scope. Ory's own documentation separates the open-source servers from the Ory Enterprise License, so the scope should state which build will run in production and who is responsible for patching it.
The engagement typically moves through an inventory, a hash format check, a pilot, a parallel run and cutover support. The inventory lists every Auth0 connection, Action, application and custom database script, because only the user records can be exported directly. The hash format check compares the password hash format that Auth0 provides on request with the formats Ory Kratos can import. Formats outside its supported list need a password migration webhook, which DeployOpen would build and test in the pilot. The parallel run keeps Auth0 and Ory serving logins while users are checked, and cutover support covers DNS, application SDK changes to standard OIDC, and rollback. Backup and restore of the Ory database, including PostgreSQL, is set up and tested before cutover, not after.
Ongoing support, upgrades and continuous security testing are available as retainers after go-live, so the engagement does not end at cutover. DeployOpen also prepares systems, configuration and evidence for compliance assessments, such as access logs, backup records and change records, for your independent auditors. DeployOpen does not issue audit reports, attestations or certifications, and it is not an official partner or reseller of Ory. Before you sign, ask for the written scope to name the Ory build, the database and hosting model, the password hash handling plan, the backup and restore test, and the support terms you expect after go-live. Confirm the current Auth0 export options and any support request terms directly with Auth0, since those can change.
How DeployOpen scopes, runs and supports the Ory migration
DeployOpen plans and implements the move from Auth0 to self-hosted Ory inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work starts, and ongoing support is available as a retainer.
How we scope
- Inventory the Auth0 tenant, applications, connections, Actions and custom database scripts that must move.
- Confirm with Auth0 whether a password hash export is available on your plan before fixing the timeline.
- Agree in writing which Ory components, login flows and user populations are in and out of scope.
How we build
- Deploy Ory Kratos, Hydra and the chosen database in your environment, with the hashing configuration documented.
- Run test imports of exported users and verify that sample passwords sign in against the hash formats Ory supports.
- Build the login, registration, recovery and MFA UI that Ory leaves to your application, then test it end to end.
How we hand over
- Deliver runbooks for user import, the password migration webhook if one is needed, and cutover steps.
- Document the configuration, OAuth 2.0 client registrations and token behavior for each application team.
- Walk your platform and security teams through operations, backups and upgrade procedures before handover.
How we support
- Offer ongoing support, upgrades and continuous security testing for the Ory deployment as a retainer.
- Confirm with Ory which Open Source or Enterprise License build fits your SLA and CVE patching needs.
- Keep the migration evidence, configuration records and test results ready for your compliance reviewers.
