ForgeRock self-managed to ForgeRock Identity Cloud migration playbook
A 6-9 month migration from self-managed ForgeRock to Ping's ForgeRock Identity Cloud SaaS — config export, journey rebuild, and a controlled traffic-shift cutover.
TL;DR
Ping acquired ForgeRock in 2023, and ForgeRock Identity Cloud is now the SaaS landing zone for self-managed AM / IDM workloads. The migration is half technical and half operational: you're shifting from infrastructure you control to a SaaS where you don't. Plan for a 6-9 month timeline at a typical mid-enterprise scale, with the bulk of effort in journey re-implementation and customer-traffic cutover.
ForgeRock Access Management / Identity Management (self-managed)
Ping Identity Cloud (formerly ForgeRock Identity Cloud)
Typical timeline
6-9 months for a mid-enterprise CIAM workload (1M-10M users, 5-15 brands / tenants).
Why teams move
- End of self-managed support cycle pressure from Ping post-acquisition
- Reduce infrastructure operations cost (10-15 engineers off-platform → 2-3 on-platform)
- Faster delivery of new features (SaaS upgrades vs on-prem upgrade cycles)
- Cloud SLA + uptime guarantees vs self-managed best-effort
The migration in 5 phases.
1. Inventory + decision (Months 1-2)
2 months
- Document existing AM / IDM topology, traffic patterns, customizations
- Identify customizations that won't port cleanly to Identity Cloud (custom Java handlers, low-level config)
- Decide migration strategy: greenfield (start fresh in cloud, migrate users) vs lift-shift (port existing config)
2. Identity Cloud tenant setup (Months 3-4)
2 months
- Provision Identity Cloud tenants (typically separate dev / stage / prod)
- Configure realms / orgs mapping to existing self-managed realms
- Port the highest-traffic 3-5 journeys to the cloud Journey UI
3. Journey + customization rebuild (Months 4-6)
2-3 months
- Rebuild remaining journeys (login, registration, password reset, MFA, account recovery)
- Replace custom Java handlers with Identity Cloud scripts (JavaScript) where possible
- Re-implement custom IDM mappings as Identity Cloud Sync configurations
4. User migration + cutover (Months 7-8)
1-2 months
- Bulk-migrate user records (passwords stay one-way-hashed; preserve immutable user IDs)
- Traffic-shift via DNS-weighted routing (10% → 25% → 50% → 100% over 2-4 weeks)
- Monitor login success rate and journey-completion rate at each weight
- Have a fast rollback path on the DNS weights
5. Self-managed sunset (Month 9)
~1 month
- Verify zero residual traffic to self-managed endpoints
- Decommission self-managed AM / IDM infrastructure
- Document the Identity Cloud operational runbook for the on-call team
What lives where.
| Capability | Source (ForgeRock) | Target (Ping) |
|---|---|---|
| Authentication journeys | AM Authentication Trees | Identity Cloud Journeys Same concept, different UI. Trees export to JSON; Journeys import is partial — re-author is common. |
| User store | IDM (DS / external LDAP / external DB) | Identity Cloud Managed Users External DB / LDAP can stay external via Identity Cloud Sync. Or migrate to Managed Users for full cloud ownership. |
| Custom code | Java auth modules / IDM connectors | Identity Cloud scripts (JavaScript) No Java in cloud. Custom Java handlers require rewrite in cloud-supported JavaScript scripts. |
| Federation | AM federation (SAML / OIDC IdP + SP) | Identity Cloud federation Functional equivalent. Metadata import is supported. |
| MFA | ForgeRock Authenticator + WebAuthn + external (push / SMS) | Identity Cloud MFA + WebAuthn + integrated push Users with existing ForgeRock Authenticator enrollments can keep them if migrated correctly. Plan a re-enrollment fallback. |
What moves, what doesn’t.
User records
Export from existing DS / DB → transform → import via Identity Cloud bulk API. Preserve immutable user IDs (typically the existing UUID) so external systems referencing those IDs continue to work.
Password hashes
If existing hashes are in a format Identity Cloud accepts (Argon2, bcrypt, PBKDF2), they migrate. If using a legacy algorithm, plan a "rehash on next login" flow.
Session state
Sessions do not migrate. Users will be forced to re-authenticate on cutover. Time the cutover to minimize disruption (overnight, weekend).
MFA enrollments
WebAuthn credentials are bound to the original relying party — they may need to be re-registered if RP ID changes. Test against your specific RP ID design.
The 7-step cutover.
- 01Pre-stage all journeys in Identity Cloud prod tenant
- 02Run end-to-end smoke tests for login, registration, password reset, MFA
- 03Begin DNS-weighted shift at 10% traffic; monitor for 24h
- 04Step up to 25%, 50%, 100% with 48h between steps
- 05Hold at 100% for at least 2 weeks before decommissioning self-managed
- 06Documented rollback: shift DNS weights back to 0% on the cloud side
What teams find out the hard way.
Custom Java is the hidden cost
Self-managed ForgeRock deployments typically have 5-20 custom Java auth modules accumulated over years. Identity Cloud doesn't support Java. Re-implementing in JavaScript scripts takes longer than expected; some functionality may require external services.
Connector parity is per-system
Many IDM connectors in self-managed ForgeRock are not yet available in Identity Cloud. Inventory connectors first; for unsupported ones, either keep them on a self-managed bridge or rebuild via external integration.
Per-tenant scaling guardrails
Identity Cloud tenants have rate limits and per-second-login caps. Validate your peak-traffic profile against tenant SKU sizing during the build phase.
Customizations to the login page UX
Many self-managed deployments have heavily-customized login UX. Identity Cloud supports JS-injected customization, but the full theming model is more constrained. Plan UX-design review early.
Questions we get on this migration.
Can we keep our self-managed ForgeRock indefinitely?
Ping continues to sell self-managed licenses, but pricing and support trajectory has shifted to favor the cloud. Audit your contract renewal terms 12 months ahead of the next cycle.
What about extreme-scale CIAM (100M+ users)?
Identity Cloud has reference deployments at this scale, but discuss tenant sizing and dedicated infrastructure with Ping during the design phase. Some very-high-scale tenants get dedicated cloud infrastructure rather than multi-tenant.
Will our existing OAuth refresh tokens work after migration?
Generally yes if the cloud tenant uses the same issuer URL. If the issuer URL changes, tokens issued by the old issuer will need to be re-issued. Plan a forced-refresh window or a longer dual-issuer overlap.
We’ve led this migration. More than once.
Engagement starts with a 90-minute discovery call — we tell you what we’d actually do, with timeline + risk register. No commitment.