ForgeRock AM/IDM to PingOne Advanced Identity Cloud
Cohash moves self-managed ForgeRock AM, IDM and DS estates to PingOne Advanced Identity Cloud, the SaaS platform formerly called ForgeRock Identity Cloud. We inventory every authentication tree, custom node, script and IDM mapping, rebuild them in development, staging and production tenants, connect on-premises targets through a remote connector server, and move users and applications in waves with a rollback point for each.
- 01Inventory trees, nodes and mappings
- 02Rework custom code for a SaaS tenant
- 03Build tenants and promotion
- 04Connect on-premises targets
- 05Users, cookie domains and waves
- 06Decommission
The story
Told without the client's name or anything that could identify them.
A retailer's identity team ran self-managed ForgeRock AM, IDM and DS on Kubernetes, on an AM 7.x build that predated the PingAM rename. Custom Java authentication nodes only built on one engineer's laptop, and DS replication, reconciliation and cluster patching took more time than onboarding applications. When the PingAM 8.x upgrade estimate came in, they asked what the SaaS tenant would take instead. We exported every tree, node, mapping and OAuth client, rewrote the Java nodes as scripted logic or built-in nodes, and built development, staging and production tenants from source control. Applications then moved to PingOne Advanced Identity Cloud in waves, with the old stack kept as the rollback until results matched for a full cycle.
why it was urgentSince February 2026, PingAM and PingIDM (the old ForgeRock AM and IDM) follow Ping's unified End of Life policy. The 7.5 line is Long-Term Support, and 8.0 is Short-Term Support, which hits End of Life roughly two years after the next version ships. Older 7.x builds are left with a choice: commit to a self-managed upgrade cadence, or move to the SaaS tenant.
- openThe estate runs an AM 7.x build that predates the PingAM rename, and nobody has planned the next upgrade.
- recurringCustom Java authentication nodes were written years ago and only build on one engineer's laptop.
- blockedKeeping DS replication, IDM reconciliation and Kubernetes patched eats more of the week than onboarding applications does.
- openThe upgrade estimate for PingAM 8.x came back and someone asked what the SaaS tenant would cost instead.
The estate, before and after
Before: self-managed ForgeRock AM, IDM and DS
Applications signed users in through an older AM 7.x build with custom Java nodes. IDM reconciled and provisioned to Active Directory and databases, and the team ran DS replication and Kubernetes patching itself.
Read the diagram as text
- Users → ForgeRock AM 7.x: sign in
- Applications → ForgeRock AM 7.x: OIDC · SAML
- Custom Java nodes → ForgeRock AM 7.x: auth trees
- ForgeRock AM 7.x → ForgeRock DS: profiles · sessions
- ForgeRock IDM → ForgeRock DS: sync
- ForgeRock IDM → Active Directory: provision
- ForgeRock IDM → Internal databases: reconciliation
After: PingOne Advanced Identity Cloud with a remote connector
Users and applications sign in through journeys in the PingOne Advanced Identity Cloud tenant, with configuration promoted from source control. A remote connector server inside the network connects out to the tenant and provisions Active Directory and databases.
Read the diagram as text
- Users → Advanced Identity Cloud: sign in
- Applications → Advanced Identity Cloud: OIDC · SAML
- Dev, staging, prod tenants → Advanced Identity Cloud: promote config
- Remote connector server → Advanced Identity Cloud: outbound connection
- Remote connector server → Active Directory: provision
- Remote connector server → Internal databases: reconciliation
How we run it, phase by phase.
6 phases take you from ForgeRock AM and IDM (self-managed) to PingOne Advanced Identity Cloud. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory trees, nodes and mappings
Export everything: trees, custom and scripted nodes, OAuth clients, IDM mappings, connectors, reconciliation schedules, DS schema extensions. Give each item an owner and one decision, whether that's rebuild, a built-in node, or retire.
- phase 02
Rework custom code for a SaaS tenant
Compiled Java extensions don't run in the SaaS tenant the way they did in self-managed AM. We rewrite custom Java nodes as scripts or swap in built-in nodes. Secrets and per-environment values go into ESVs.
- phase 03
Build tenants and promotion
Journeys, applications and identity configuration are built in the development tenant. We export them to source control and promote them to staging, then production. Production gets nothing that hasn't been reviewed.
- phase 04
Connect on-premises targets
We connect Active Directory, databases and other internal targets through a remote connector server, since the tenant can't reach them directly. Mappings get tested on real data before live sync.
- phase 05
Users, cookie domains and waves
Profiles and supported password hashes are imported, and users with other hashes move when they next sign in. After custom and cookie domains are set, apps are re-pointed wave by wave, with the self-managed stack kept warm in case we need to roll back.
- phase 06
Decommission
Once sign-in and reconciliation results have matched for a full cycle, we shut down the AM, IDM and DS servers and archive their audit logs for retention.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
No AM, IDM or DS servers to patch
Sign-in, identity management and the directory now run in PingOne Advanced Identity Cloud. We shut down the self-managed servers and archived their audit logs for retention.
- result 02
No custom Java that builds on one laptop
We rewrote the custom Java nodes as scripted logic or replaced them with built-in nodes. Secrets and per-environment values live in ESVs now.
- result 03
Every configuration change is reviewed
We keep journeys, applications and identity configuration as exported files in source control, promoted from development through staging to production.
- result 04
On-premises targets still get provisioned
A remote connector server links the tenant to Active Directory and the internal databases, and mappings were run against real data before we turned on live sync.
- result 05
Users kept signing in through the move
Profiles and supported hashes got imported. Everyone else moved over the next time they signed in. We set custom and cookie domains before each application wave.
Risks we plan for
-
Custom Java nodes with no SaaS equivalent
Nodes that call internal services or hold state need a design decision before the build starts. Leaving them to the end turns a migration into a rewrite under deadline.
-
Hash formats that won't import
Certain hash schemes or salts can't be imported into the tenant. Users with those hashes migrate just in time when they next sign in, so the old store has to stay up a while longer.
-
Cookie and session changes
Apps that read the AM session cookie directly, or share a parent domain with it, can break when the cookie domain changes. We test each one in real browsers before its wave.
-
Reconciliation drift during the parallel run
Let old and new IDM both write to a target and they'll keep overwriting each other. So every target has a single provisioning side at a time, and the switch date is written down.
Where AI helps, and where it needs guardrails
In PingAM 8.1 an AI agent is an OAuth client acting for a user through delegated token exchange, and Ping's Identity for AI products have been generally available since 24 March 2026. We use the migration to give every agent and MCP server a client, scopes and an owner of its own. The shared service accounts that many AM estates run on stay behind. Coding assistants draft node script conversions for us, and each one has to pass recorded test sign-ins before it's promoted.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Inventory of trees, nodes, scripts, OAuth clients and IDM mappings, with a rebuild, replace or retire call on each
yours to keep - code02
Tenant configuration as exported files with a promotion pipeline
yours to keep - tests03
Remote connector server build and mapping test results per target
yours to keep - plan04
User import plan covering hash formats, duplicates and just-in-time migration
yours to keep - runbook05
Wave plan and cut-over runbook with a rollback point per application group
yours to keep
Platforms and services on this move
Services involved
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Connector
- The integration between an identity platform and an app. It's how the platform reads and changes accounts and access in that app.in context →
- 02Wave
- One batch of workloads moved together. Large migrations run as a series of these, so each one can be planned, cut over and reviewed on its own.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we upgrade to PingAM 8.x or move to PingOne Advanced Identity Cloud?
It depends on hosting rules, how much custom Java you own and who runs the platform. Strict data residency or heavy custom nodes favor staying self-managed on the 7.5 LTS line or 8.x. A small custom footprint and a team tired of patching DS and Kubernetes favor the SaaS tenant. We count the custom objects and price both paths.
02Do users have to reset their passwords?
Not if the hash format imports. If it doesn't, just-in-time migration moves each user on their next sign-in. They type the same password and never get a reset email.
03Can the old and new platforms run at the same time?
Yes. We move applications in waves and keep the self-managed stack live. Each target's provisioning switches once, on a date we record, so the two IDM instances never compete for accounts.
04How long does it take?
It depends on how many authentication trees and custom nodes you have, how many targets need the remote connector server and how many applications share session cookies. The inventory in the first phase gives us the real estimate.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case study03490418 - 01Ping Identity docs: PingOne Advanced Identity Cloud (formerly ForgeRock Identity Cloud)docs.pingidentity.com ↗
- 02Ping Identity docs: name changes for ForgeRock products (PingAM 8 reference)docs.pingidentity.com ↗
- 03Ping Identity developer blog: LTS, STS and everything in between (5 Dec 2025)developer.pingidentity.com ↗
- 04Ping Identity: End of Life Policypingidentity.com ↗
- 05Ping Identity docs: New in PingAM 8.1.xdocs.pingidentity.com ↗
- 06Ping Identity press release: Identity for AI generally available (24 Mar 2026)press.pingidentity.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it