Identity and access, move by move.
Most identity work we get called into is overdue. An IdentityIQ release is about to lose support, two directories survived an acquisition, or an auditor asked who approved a grant and nobody could say. These are the moves we've run, with the connectors, roles and cut-over plans that carried them.
- AD FS federation to Entra ID authenticationmigration · delivered
- Auth0 Rules and Hooks to Actions before end of lifeupgrade · delivered
- Consolidating Okta and Entra ID after years of running bothconsolidation · delivered
- ForgeRock AM/IDM to PingOne Advanced Identity Cloudmigration · delivered
- Homegrown customer login to Auth0 or Okta Customer Identityimplementation · delivered
- IBM ISIM, Oracle OIM or homegrown provisioning to SailPoint or Saviyntmigration · delivered
AD FS federation to Entra ID authentication
Told without the client's name or anything that could identify them.
A healthcare group's identity team ran an AD FS farm and Web Application Proxy servers on Windows Server 2016, and every token-signing certificate renewal turned into a scramble. Users saw a branded AD FS page for some apps and the Microsoft sign-in page for others, and MFA was enforced in two places. We used the AD FS application activity report and Connect Health to find which relying party trusts still got traffic, backed up the federation settings, and rebuilt access policies as Conditional Access in report-only mode. After staged rollout pilots on password hash sync, domains converted one at a time and the remaining apps moved in waves. The farm was shut down once Connect Health showed no new requests.
what the client got- Sign-in runs on Entra ID cloud authenticationWe converted federated domains to managed authentication with password hash sync. That also turned on leaked-credential detection, something AD FS never had.
- One set of MFA and access rulesAD FS access control policies were rebuilt as Conditional Access policies, legacy authentication is blocked, and federatedIdpMfaBehavior was set explicitly so MFA wasn't skipped during the switch.
- Every relying party has an owner and a targetWe moved each trust to a gallery app, a custom SAML app or an app registration. Some we simply retired. Nothing went live in a wave until its claims matched the old tokens one for one.
All 13 in identity and access
Read any of them and you get the story, the before-and-after architecture, the plan phase by phase and the results.
AD 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 studyConsolidating Okta and Entra ID after years of running both
Picking one primary identity provider after years of running Okta and Microsoft Entra ID side by side, then moving apps, MFA and provisioning to it.
read the case studyForgeRock AM/IDM to PingOne Advanced Identity Cloud
Moving self-managed ForgeRock AM and IDM, now called PingAM and PingIDM, to PingOne Advanced Identity Cloud without breaking sign-in or provisioning.
read the case studyHomegrown customer login to Auth0 or Okta Customer Identity
We swap homegrown customer login and its user table for Auth0, move users without forcing password resets, and keep the CRM records in sync.
read the case studyIBM ISIM, Oracle OIM or homegrown provisioning to SailPoint or Saviynt
Getting off IBM ISIM, Oracle OIM or homegrown provisioning scripts and onto SailPoint or Saviynt, with provisioning, certifications and audit history intact.
read the case studyIdentity integration after a merger or carve-out
We give people access on day one after a merger or divestiture. Then directories, identity providers and governance get merged or separated, on a plan.
read the case studyIdentityIQ 8.x to 9.0 upgrade
Upgrading SailPoint IdentityIQ 8.x to 9.0, with the route through 8.5, the iiq-precheck scan, javax to jakarta fixes and a tested rollback.
read the case studyOn-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 studyOracle Access Manager and OIG to a modern identity provider and IGA
Replacing Oracle Access Manager and Oracle Identity Governance 12c with a cloud identity provider and SailPoint or Saviynt before support runs out.
read the case study
RSA SecurID tokens to passwordless MFA with passkeys
Retiring RSA SecurID tokens, hardware and software, in favour of phishing-resistant passkeys while VPN, RADIUS and server logons keep working.
read the case studySailPoint IdentityIQ to Identity Security Cloud
Leaving IdentityIQ for SailPoint Identity Security Cloud (formerly IdentityNow) with custom logic, certifications and audit history carried across.
read the case studySAP Identity Management replacement with Entra ID or SailPoint
Replacing SAP Identity Management before its 2027 end of maintenance, with provisioning to SAP and non-SAP systems moved to Entra ID Governance or SailPoint.
read the case studyNot sure which one fits?
Send us what you run and what's due. An engineer reads it and tells you where we'd start.
start an assessment →Risks that keep coming up
One risk from each of these moves, and the case study that shows how we handled it when it hit.
-
Claim rules with no direct mapping ↗
Custom claim transforms, attribute stores and issuance rules don't always map to Entra claims mapping. Each one is rebuilt and compared against a real token before cut-over.
-
Shared state between rules ↗
A lot of rules hand data to the next rule through the user or context objects. That doesn't carry over. Auth0 says data changed on the event object isn't visible to other Actions, so chained logic gets redesigned.
-
Provisioning from two sources ↗
When both platforms push SCIM to the same app, accounts flip between attribute values or get deprovisioned by the wrong side. One source per app is set before any wave starts.
-
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.
-
Duplicate accounts by email ↗
It's common to find the same email in a homegrown store twice, with two different passwords. We settle account linking rules before the import, otherwise those users get two profiles.
-
Orphan and mismatched accounts ↗
Years of manual fixes leave accounts that don't correlate to any person. They're reviewed with owners before cut-over, or the first certification fills up with noise.
Platforms and services across these moves
Ordered by how often they appear in this area's case studies.
01Are we moving to Okta or Ping instead?
That works too. We do the same inventory, claim mapping and wave plan, and only the target changes. If Okta or Ping is already your primary identity provider, we plan the move there.
02Can Rules and Actions run side by side?
Yes, during the migration. We move one rule at a time, disabling it and binding its Action in the same deploy, so the tenant is never without the logic.
03What about AI agents already registered in both?
We list every agent with its owner and scopes, decide which platform governs agents from now on, and re-register them there. Agents nobody owns get disabled. If someone needs one back, they claim it.
04Should 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.
05Auth0 or Okta Workforce Identity for customers?
They're different products. Auth0 is Okta's customer identity platform, with Universal Login, Organizations for business customers and MAU-based pricing. Workforce Identity is built for employees. Customer sign-in, we put on Auth0.
More case studies by area
The same approach, applied to other parts of the estate.
898005ed - 01Microsoft Learn: Migrate from federation to cloud authenticationlearn.microsoft.com ↗
- 02Microsoft Learn: Stages of migrating application authentication from AD FS to Entra IDlearn.microsoft.com ↗
- 03Microsoft Lifecycle: Windows Server 2016learn.microsoft.com ↗
- 04Auth0 docs: Rules (end-of-life notice)auth0.com ↗
- 05Auth0 docs: Migrate from Rules to Actionsauth0.com ↗
- 06Auth0 blog: Auth0 for AI Agents is generally available (19 Nov 2025)auth0.com ↗
- 07Okta newsroom: Auth0 product innovations (21 May 2026)okta.com ↗
- 08Okta support: What's new in Okta for AI Agentssupport.okta.com ↗
Facing one of these moves?
Tell us what you're on now and where you need to be. We'll come back with how we'd run the move.
- 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