Navigating the Unified Identity Frontier
So, your leadership has finally decided that the duct-taped mess of a legacy identity system you’ve been nursing for five years is going to the digital graveyard. This is a significant pivot for any enterprise. Now you’re staring at a migration to the newly unified Ping Identity platform, which integrated the ForgeRock portfolio following the 2023 merger.
It is a bit like being told you’re moving from a cramped studio apartment into a sprawling mansion, but you have to carry every single piece of furniture on your back. You are doing this across a tightrope, suspended over a pit of hungry stakeholders and auditors. Identity migrations are high-stakes operations where the margin for error is razor-thin.
In this practitioner's guide, we will examine the technical realities of moving to the unified Ping/ForgeRock ecosystem. We will focus on the transition from legacy stacks to modern orchestration while maintaining security posture and user experience.
Why the Migration is Non-Negotiable
Nobody wakes up and thinks they would love to spend six months re-architecting authentication flows just for fun. Usually, we do this because the old system has become a liability. According to the Verizon Data Breach Investigations Report (2024), stolen credentials remain a primary entry point for breaches, often facilitated by legacy systems that cannot support modern MFA or risk-based signals.
The big draw for moving to the unified Ping/ForgeRock ecosystem is identity orchestration. In older environments, changing a login flow required writing custom Java or C# code and hoping for the best during the build. Now, we use tools like PingOne DaVinci or ForgeRock’s Intelligent Access Trees.
These tools allow you to treat identity like a modular system. You can drag a "Webauthn" block, connect it to a "Risk Engine" block, and immediately deploy a secure flow. Before we get to the fun drag-and-drop design, we have to deal with the messy reality of the current environment.
Step 1: The Identity Audit and Discovery
You cannot migrate what you do not understand. This is the phase where teams realize their "simple" environment is actually a tangled web of hundreds of applications. You will find applications using SAML 1.1 (yes, it still exists in legacy financial and healthcare apps), and some using proprietary protocols that haven't been updated in a decade.
We need to categorize every application in the environment. I recommend bucketing applications into three distinct categories based on their technical debt and integration capabilities.
- The Modern Standard: Anything already using OpenID Connect (OIDC) or SAML 2.0. These are your easiest migrations because they follow established standards like RFC 6749.
- The Adaptable Middle: Applications that can be updated to use modern protocols with a configuration change but currently rely on older methods like WS-Federation.
- The Legacy Hard-Core: On-premises applications that expect a specific proprietary cookie or an HTTP header. This is where PingAccess or ForgeRock’s Identity Gateway must be deployed to act as a protocol translator.
IMPORTANT
Never trust your existing documentation or CMDB. It is almost certainly out of date. Use network traffic logs and IdP login logs to see what is actually hitting your servers. You will inevitably find "shadow" applications that the business relies on but IT has forgotten.
Step 2: Mapping the Souls (Data Migration)
Moving user records is a standard database task, but moving passwords is a nightmare for the security team. Most modern systems use secure hashing algorithms like Bcrypt, Scrypt, or PBKDF2 (as recommended by NIST SP 800-63-4). You cannot "see" the cleartext password to move it to the new system's directory.
You have three primary choices for handling this transition. You can force a global password reset, which is a guaranteed way to spike help desk volume. You can perform a bulk import if you have access to the original salt and hash, though this is technically complex.
The most effective method is the Lazy Migration (also known as Just-In-Time provisioning). This method ensures a seamless transition for the user while slowly populating the new directory.
- A user attempts to log in to the new Ping/ForgeRock system.
- The new system checks its local directory and finds no record or no password.
- The new system securely queries the legacy system (the "Source of Truth") behind the scenes.
- If the legacy system validates the credentials, the new system captures the password and saves a new hash in its own database.
- The user is now fully migrated without ever knowing a change occurred.
Quick Reference: Migration Strategy Comparison
| Strategy | User Impact | Effort | Risk Level |
|---|---|---|---|
| Big Bang | High (Mandatory Reset) | Low | High |
| Lazy Migration | Zero (Silent Move) | Medium | Low |
| Bulk Export/Import | Medium (Sync Issues) | High | Medium |
Step 3: Building the Orchestration Journeys
Once the data is mapped, we move into the orchestration phase. In the ForgeRock world, these are called "Trees" or "Journeys." In the PingOne world, it is "DaVinci." The philosophy is the same: treat the authentication process as a series of logic gates.
The goal here is not to replicate your old, boring username/password prompt. If you do that, you are wasting the capabilities of the new platform. You should be building dynamic pathways that respond to the context of the login attempt.
For example, if a user logs in from a managed corporate laptop on a known office network, you might allow a passwordless experience using Windows Hello for Business or Apple TouchID. If they are logging in from an unknown IP address in a high-risk region, the journey should automatically trigger a step-up MFA challenge.
Step 4: The Coexistence and Bridge Phase
Unless you are a glutton for punishment, you will not flip a switch and move 50,000 users overnight. You will live in a hybrid world for several months. This is often referred to as the "Identity Bridge" phase of the migration.
During this time, you will likely have your legacy IdP and your new Ping/ForgeRock instance running concurrently. You can use an "IdP Discovery" or "Home Realm Discovery" page. When a user enters their email address, the system determines which "house" they belong to and routes them accordingly.
TIP
Keep the UI/UX of the new login screen as close to the old one as possible during the transition. Users are trained to spot visual changes as potential phishing attempts. Drastic changes in branding during a migration will lead to a surge in "Is this a scam?" tickets.
Step 5: Advanced Testing and Failure Modes
Brilliant architects often fail because they forget to test the "Edge Cases." A migration isn't just about the happy path where everyone remembers their password and has a working phone for MFA. You must test the failure modes of the new system.
One common failure mode is the "Shadow Account" problem. This occurs when a user is deleted from the HR system but their session remains active in the new IdP because the logout signal was never sent to the legacy apps. You must ensure that your SCIM (System for Cross-domain Identity Management) flows are robust.
Refer to RFC 7643 and RFC 7644 for the proper implementation of SCIM. This ensures that when an identity is deactivated in your primary directory, that status is propagated to all downstream applications in real-time.
WARNING
Test the "Back Button" behavior in your OIDC flows. Users frequently hit the back button during an authentication journey. If your orchestration logic doesn't handle state management correctly, it can result in "State Mismatch" errors that lock the user out of the session.
Vendor Component Comparison
Since the merger, the unified Ping Identity offers multiple ways to achieve the same goal. It is important to understand which tool fits your specific use case.
PingFederate
Strengths
- Extremely mature support for complex, on-premises legacy integrations.
- High performance for high-volume service provider (SP) and identity provider (IdP) roles.
- Deep integration with Windows ecosystems and Kerberos.
Limitations
- Can be complex to manage at scale without significant automation.
- The UI for policy creation is more traditional compared to modern drag-and-drop orchestrators.
ForgeRock Access Management (AM)
Strengths
- Superior "Intelligent Access Trees" for complex, branching authentication logic.
- Native support for a wide variety of social and third-party identity providers.
- Highly extensible via scripting (JavaScript/Groovy) for custom requirements.
Limitations
- Requires a specialized skill set to manage the underlying directory and configuration.
- The transition to the unified Ping cloud platform is still an ongoing process for some legacy on-prem features.
Key Takeaways for the Practitioner
- Audit thoroughly: Use actual logs to find legacy apps using SAML 1.1 or header-based auth.
- Prioritize Lazy Migration: Avoid the "Big Bang" password reset to keep the help desk from being overwhelmed.
- Leverage Standards: Stick to OIDC and SAML 2.0 for new integrations to avoid future technical debt.
- Focus on Orchestration: Use DaVinci or Access Trees to build risk-aware journeys rather than static login pages.
- Validate Provisioning: Ensure SCIM (RFC 7643) is correctly implemented to prevent orphaned accounts in downstream apps.
Migrating to a unified platform like Ping Identity is a massive undertaking, but it is the most effective way to retire "Identity Debt." By moving toward an orchestrated model, you gain the ability to respond to new security threats in minutes by adjusting a flow, rather than spending weeks writing custom code.
It will be a challenging few months of migration. You will likely encounter legacy applications that refuse to accept a modern JSON Web Token (JWT). However, once you reach the other side and have a single, orchestrated pane of glass for your identity landscape, the increased security and agility will justify the effort.