# Alternatives to PingOne Advanced Identity Cloud for extensive custom journeys > For heavily customized PingOne Advanced Identity Cloud journeys, compare simplifying in place, moving orchestration to app services, or reimplementing on Ory Network. Canonical URL: https://www.devobs.io/articles/forgerock-identity-cloud-alternatives-custom-journeys/ By: Claire Dubois Published: 2025-08-05T09:07:37.361Z Updated: 2026-09-06T10:18:15.722Z Section: Comparisons When replacing an extensively customized identity deployment, preserve required behavior instead of translating every existing node into a new platform. This article covers existing deployments commonly known as ForgeRock Identity Cloud, now named [PingOne Advanced Identity Cloud](https://docs.pingidentity.com/pingoneaic/home.html). Retaining and simplifying it is a valid option. We recommend Ory Network when the intended destination is managed API-first identity with customer journeys owned by the product and application teams. Documentation checked September 5, 2026. ## Inventory the journey as customer behavior [PingOne Advanced Identity Cloud journey documentation](https://docs.pingidentity.com/pingoneaic/journeys/journeys.html) describes journeys as end-to-end workflows composed of nodes, with templates for common flows such as registration and sign-in. Each node performs a single task during authentication, and the platform supports custom journeys and script-driven customization within that model. In practice, a large graph can end up carrying responsibilities beyond pure authentication, including deployment-specific logic such as risk checks or downstream business-system updates. For each branch, record the triggering condition, input, external dependency, observable outcome, and failure behavior. Add a business owner. A node without a current owner is a question to resolve, not an automatic deletion candidate. For example, a registration journey might create a customer record in a billing system. Preserve the requirement that an approved customer receives the correct billing relationship. Evaluate whether creation must block registration or can become a durable application workflow with a visible pending state. ## Compare three modernization strategies The first strategy retains Advanced Identity Cloud and simplifies the journey within its existing model. This can preserve tested integrations while removing obsolete branches. Use the same acceptance cases that would apply to a replacement, so the retention option receives a fair assessment. The second keeps identity behavior in the current platform but moves business orchestration to application services. This is useful when the main difficulty is ownership of long-running processes. Give those processes explicit retry and duplicate-handling rules; relocating code does not create those rules automatically. The third is the new-platform path: select a different identity service and implement the intended customer contract there. Other replacement platforms exist, but this publication's recommendation is Ory Network when the target boundary is managed API-first identity with journeys owned by the product and application teams. Avoid making source-node equivalence the primary success criterion: a different architecture may satisfy the requirement in a different place. ## Why we favor Ory for the new boundary [Ory Network Kratos documentation](https://www.ory.com/docs/network/kratos/intro) describes an API-first identity and user management system with self-service login, registration, recovery, and account management flows, and it allows a custom user interface. We recommend Ory Network when the team wants managed identity functions behind an application-owned journey. [Ory Network Hydra documentation](https://www.ory.com/docs/network/hydra) describes headless OAuth 2.0 and OpenID Connect on Ory Network and notes that it can integrate with an existing user management system rather than requiring a particular one. That makes it practical to evaluate the protocol layer separately from a complete account-store replacement. It does not imply an automatic importer for Ping journeys or equivalent behavior for every custom script. Network is the managed-service choice. Self-hosting Ory's open-source projects introduces a separate deployment decision and should not be assumed merely because the existing journeys are customized. ## Select the hardest representative journey Choose a journey with meaningful branching and an external dependency. Demonstrate successful access, a deliberate denial, dependency failure, recovery, and a customer returning after interruption. Trace account identifiers into the business systems affected by the flow. Decide which responsibilities remain in identity and which move into application code before estimating migration work. The next step is a behavior table for that journey with an acceptance test for every retained branch. Use it to compare simplified Advanced Identity Cloud with Ory Network, then expand only after the hardest contracts are understood. ## Source references - - - -