There is an important distinction to make before talking about a ForgeRock migration.
ForgeRock Identity Cloud became PingOne Advanced Identity Cloud. The larger migration challenge is moving an established self-managed ForgeRock environment — typically some combination of AM, IDM, DS, Identity Gateway, custom nodes, scripts, connectors, and years of application integrations — into Advanced Identity Cloud.
That is not a lift-and-shift.
A mature ForgeRock estate usually reflects years of accumulated business requirements. Custom scripts appear. Authentication trees grow branches. Connectors sit close to internal systems. Gateway patterns support applications that never learned SAML or OIDC. Operational teams build procedures around direct access to logs, servers, and configuration.
Moving to SaaS changes many of those assumptions.
The right question is not:
How do we copy this environment into AIC?
It is:
What should move, what should change, and what should be left behind?
That is where the migration begins.
This Should Be a Business Decision, Not a Panic Migration
Ping has been clear that customers are not being forced off self-managed ForgeRock.
That matters.
The decision to move to AIC should be based on architecture, operations, cost, risk, and long-term identity strategy.
For some organizations, SaaS is compelling because it reduces infrastructure ownership, patching, upgrade projects, and platform maintenance.
For others, heavy customization, regulatory requirements, or unusual network and integration patterns may justify remaining self-managed longer.
Cloud should be the target because it fits the environment, not because it is newer.
Journeys Are Where Complexity Usually Appears First
Authentication trees are one of the first places migration teams look.
But counting trees tells you very little about migration effort.
A mature environment may contain scripted nodes, application routing, MFA logic, contractor handling, Kerberos, account recovery, IP-based decisions, exception paths, and integrations with external services.
Some of that may move cleanly.
Some may be better rebuilt using native AIC capabilities.
Some may depend on assumptions that do not exist in SaaS.
The important question is not only what a journey does, but why it exists.
Long-lived IAM environments collect logic nobody wants to remove because nobody is completely sure what still depends on it.
A migration is an opportunity to challenge that.
Moving complexity to the cloud does not make it less complex.
Identity Data Is Often Harder Than Authentication
Authentication gets the attention. Identity data often creates the real migration work.
Self-managed ForgeRock environments may contain custom schema, managed users, groups, roles, indexed attributes, application-specific fields, lifecycle logic, and years of mappings between systems.
Those objects need to be evaluated deliberately.
Which system owns each attribute?
Which fields actually drive policy?
Which custom attributes still matter?
How are groups and roles represented?
What happens to credentials during migration?
Password strategy may involve direct migration, pass-through authentication, or a staged transition.
The migration may also run for months, meaning old and new environments coexist.
That creates another challenge: keeping identity data consistent while users and applications move at different speeds.
The data model is part of the IAM architecture.
If it contains years of workarounds, moving all of it into AIC simply preserves the same problems in a newer platform.
Provisioning Architecture Changes Too
IDM migrations deserve separate attention.
In a self-managed deployment, connectors may sit inside infrastructure with direct access to Active Directory, LDAP, databases, HR systems, and internal applications.
AIC changes that relationship.
Remote Connector Servers, firewall paths, credentials, resilience, reconciliation, monitoring, and support ownership all become architectural decisions.
The business requirement may remain simple:
Create the account. Update the user. Disable access.
The technical path can change significantly.
This is also the right time to reconsider old provisioning patterns. Some mappings may no longer be necessary. Some targets may now support better APIs. Some integrations may deserve retirement rather than migration.
The goal is to preserve the capability, not recreate every historical implementation decision.
Customization Is Where Migration Estimates Get Real
Standard configuration is rarely the difficult part.
Customization is.
Every custom node, script, plugin, scheduled job, filesystem dependency, unusual endpoint, and network assumption should be identified early.
Then classify it.
Can it move?
Can AIC replace it with native functionality?
Can it be redesigned using a supported pattern?
Does it belong outside the identity platform?
Or is it solving a requirement the business no longer has?
This is why serious migration planning starts with discovery.
The expensive surprises are usually hiding in the things someone built years ago because the standard product could not quite do what the business needed.
Moving IAM to SaaS Does Not Modernize Legacy Apps
The identity platform can move to the cloud.
The old applications stay old.
Kerberos still needs to work.
Header-based authentication still needs headers.
Legacy systems may still depend on gateways, proxies, local accounts, LDAP, or unusual federation patterns.
Those dependencies do not disappear because AM and IDM moved into AIC.
That is why phased migration matters.
Some applications can move early. Others may remain on the existing platform while dependencies are resolved. Gateway patterns can help bridge old and new environments while production behavior is validated.
For large enterprises, that is usually safer than trying to move everything in one heroic weekend.
SaaS Changes the Operating Model
One of the biggest changes is not authentication at all.
It is how the platform is operated.
Self-managed ForgeRock often gives administrators deep control over infrastructure and configuration. AIC introduces a different model for environments, configuration promotion, secrets, tenant controls, and platform-managed changes.
Teams need clear answers on how changes move from development to production, where environment-specific values belong, how secrets are handled, and how rollback works.
A cloud migration is a good forcing function for configuration discipline.
Development, test, stage, and production should not become four independently maintained IAM environments.
The migration should leave behind a repeatable promotion process, documented environment differences, and a clear way to determine what changed when production behaves differently.
A Successful Login Is Not the Finish Line
IAM projects have a bad habit of declaring victory when the user successfully authenticates.
Then Monday morning happens.
The help desk needs to troubleshoot failures.
Operations needs logging and monitoring.
Application teams need escalation paths.
Security needs audit evidence.
Engineers need rollback procedures.
Someone needs to understand what Ping owns, what the customer owns, and when support escalation is required.
Runbooks, monitoring, troubleshooting, support ownership, and operational handoff belong in the migration plan before cutover.
A system that works but cannot be supported reliably is not a completed migration.
Where Navar Helps
This is where experienced ForgeRock and Ping implementation work makes a difference.
Navar works across both sides of the transition: established ForgeRock environments and PingOne Advanced Identity Cloud.
We start with the environment that actually exists.
That means understanding journeys, customizations, identity data, provisioning, gateway dependencies, legacy applications, and operational processes before defining the target architecture.
Then the migration becomes a set of deliberate decisions.
What moves cleanly?
What should be modernized?
What needs an interim pattern?
What requires redesign?
What should be retired instead of migrated?
And what cannot be allowed to break when production traffic moves?
Navar can support the assessment, architecture, journey migration, AIC configuration, application onboarding, provisioning design, gateway integration, testing, cutover planning, troubleshooting, and operational handoff needed to turn that plan into a working production environment.
Migrate the Capability, Not the Technical Debt
Moving from self-managed ForgeRock to PingOne Advanced Identity Cloud can be an opportunity to simplify an IAM environment.
But only if the project is treated as more than configuration transfer.
Journeys should be questioned.
Identity data should be cleaned up.
Provisioning patterns should be reconsidered.
Customizations should justify their existence.
Legacy applications should get the integration pattern they actually need.
And operational processes should be rebuilt for the SaaS model.
The goal is not to recreate the old platform somewhere else.
It is to preserve the identity capabilities the business depends on while leaving unnecessary complexity behind.
That is the difference between moving ForgeRock to the cloud and actually modernizing IAM.
If your organization is considering a move from self-managed ForgeRock to PingOne Advanced Identity Cloud, Navar can help identify the real migration dependencies, design the target architecture, and build a path to production without discovering the difficult parts during cutover.
