We recently completed a migration from Ping Identity to SailPoint for our identity governance and administration (IGA), and the difference has been pretty stark. While Ping is fantastic for core federation and SSO, we found its governance capabilities, especially around complex access certifications and role management, weren't keeping up as our organization scaled. We needed more depth in the "who has access to what, and why" department.
Here’s a quick breakdown of our main reasons for the switch:
* **Workflow Complexity & Automation:** SailPoint's workflow engine felt more mature for building detailed approval chains for access requests. With Ping, we were often writing more custom scripts to bridge gaps in certification campaigns. SailPoint’s model of "everything is a workflow" gave us finer control.
* **Role Lifecycle Management:** Our role definitions got complex. SailPoint’s tools for discovering, modeling, and certifying roles (both business and IT) were more intuitive for our line-of-business reviewers. Ping's approach felt more technical and harder for non-IT managers to grasp.
* **Analytics & Reporting:** This was huge for us. SailPoint’s out-of-the-box reports for compliance (SOX, GDPR) and the visibility into access risk metrics were more comprehensive. We were building too many custom reports in Ping, which became a maintenance burden.
* **Email Deliverability & Notifications:** Sounds minor, but it matters! The customization and reliability of SailPoint’s notification emails for certifications and approvals were better. We had some issues with Ping's emails being flagged or not rendering well for certain users, which slowed down certification cycles.
Don't get me wrong—Ping is a powerhouse for user authentication. But for the governance layer, SailPoint just fit our needs better. It’s like comparing a best-in-class marketing automation platform (for user journeys) to a best-in-class CRM (for data and governance). They can integrate, but sometimes you need the deep specialization.
Curious if others have had a similar experience, or if you've found ways to extend Ping's governance to cover these areas? 🤔
automate the boring stuff
Hi Michael here. I'm a cloud architect for a financial services firm with about 5,000 employees, and we went through a very similar evaluation about 18 months ago, running both PingFed and SailPoint IdentityIQ in production during a pilot phase before making a call.
Based on our hands-on migration, here are the concrete details I'd highlight:
* **Pricing Model & Scale:** PingIdentity's pricing around governance felt like an add-on to their core access management, and scaling it for thousands of applications got expensive quickly for what it delivered. SailPoint's enterprise licensing is a big commitment, but it's all-in for IGA. In our sizing, SailPoint for full governance came in at roughly 1.5x the cost of Ping's governance suite, but the feature depth justified it for our scale.
* **Deployment & Integration Overhead:** Ping was lighter to get going for basic certifications because we already had the connectors in place for SSO. However, SailPoint's connector framework, while more complex initially, gave us far more control over attribute flow and lifecycle events from sources like SAP and custom databases. The initial setup for SailPoint took about 40% longer, but it reduced ongoing maintenance.
* **The UI/UX Divide for Business Users:** This was the biggest operational win. SailPoint's certification campaigns and role management screens were simply easier for our business line managers to understand and act on. With Ping, our completion rates for access reviews were lower, and we fielded more "what am I looking at?" support tickets. SailPoint's separation of "what you have" from "what your role grants" clicked better with non-technical reviewers.
* **Automation and Customization Ceiling:** You mentioned custom scripts with Ping, and that resonates. SailPoint's Beanshell scripting inside its workflow engine is not simple, but it provided a unified way to build complex approval rules and remediation actions. With Ping, we often hit a "that's not how it's designed" wall much sooner. SailPoint's model is built for that customization, for better or worse.
My recommendation leans heavily towards SailPoint if your primary driver is deep governance, role lifecycle, and compliance reporting for a large, complex organization. If your core need is rock-solid federation and web SSO, and governance is a secondary checkbox, Ping can be the more straightforward choice.
To make it clean for you, I'd need to know: what's your application count sitting at, and how technical are the business owners who will be running the access certifications?
null
Your point about SailPoint's connector framework taking longer to set up but offering more control is critical. We saw the same, and it forced a necessary conversation about data quality from source systems before integration. The extra time wasn't just overhead - it was a disguised data modeling project.
One caveat on the "everything is a workflow" model you alluded to: it can create significant latency in access provisioning if those workflows aren't meticulously monitored. We had to build a separate dashboard just to track average completion times for access request workflows, as they became a bottleneck during onboarding peaks. Did your team implement any specific monitoring on that front?
Garbage in, garbage out.
That emphasis on reporting is a key point I've seen a lot of teams miss. Getting "who has access to what" is one thing, but the actionable part is "why."
Did you find SailPoint's out-of-the-box analytics translated well to your actual compliance evidence packs, or did you still need to build custom dashboards to get the right view for auditors?
Also, with those complex roles, how are you handling monitoring for role drift over time? That's where our old setup always fell apart.
Sleep is for the weak
Yeah, that "finer control" with workflows is a double-edged sword. You get to build exactly what you need, but then you own the operational burden of every single one. It's like giving everyone in the team a Swiss Army knife and then being surprised when someone tries to use the toothpick to change a tire.
We found that extra control came with a hidden tax: you're now in the workflow monitoring business. All those beautifully detailed approval chains can quietly fail or get stuck. We ended up instrumenting them like any other app, feeding metrics into Prometheus and setting up alerts for stuck tasks. Suddenly you're running a mini BPM platform. Fun times.
The reporting depth was a game-changer for audit season though. Totally worth the hassle.
Totally get that on the workflow control. The "finer control" comment nails it - but it's a trade-off, isn't it? You move from writing custom scripts for Ping to building and babysitting a whole library of workflows in SailPoint.
We leaned hard into the out-of-the-box analytics too. For standard compliance packs, they were a godsend. But when we needed to explain *why* access to a particular legacy app was suddenly spiking, the canned reports fell short. We ended up pulling raw data into Power BI for those ad-hoc, "tell me a story" requests from security.
How's your team finding the balance between those pre-built reports and custom needs?
PipelinePerf
You hit on the critical difference: Ping's governance always felt like a feature, not a product. The reporting depth you mentioned was the final straw for us too.
But that "finer control" from the workflow model comes with a serious operational tax. You're now running a distributed workflow engine. We learned the hard way that without aggressive monitoring, those beautiful approval chains you build will stall during onboarding peaks and no one will notice for days. You need to instrument task completion times and failure rates like it's a core application.
Did your team bake in that monitoring from the start, or did you get surprised by a stuck workflow like the rest of us?
Speed up your build
Oh, we got surprised alright. Built a gorgeous onboarding workflow, only to find it silently choked on a holiday when a primary approver was out. Took three days to notice.
We ended up doing exactly what you said - treating it like a core app. I built a simple spreadsheet tracker that pings the SailPoint REST API for workflow stats daily. Tracks average completion time, failures, and idle time. It's clunky, but it gives us that heartbeat check.
The real trick was setting up alerts for *idle* workflows, not just failed ones. A failure is obvious. A workflow sitting in someone's inbox for a week isn't.
That spreadsheet tracker is a clever workaround, but it's still manual overhead. Have you considered piping those REST API calls into your existing observability stack? We send SailPoint workflow metrics directly into CloudWatch. A simple Lambda function fetches the stats daily and pushes them as custom metrics.
It lets us set alarms on idle thresholds and dashboards for completion time trends. Treating it like a core app is right, but you can also bill the cloud cost for those Lambdas back to the IGA team's budget. Makes the "operational tax" visible 😉
- elle
Ah, the classic "just add more cloud services to monitor your monitoring platform" solution. Gotta love the irony.
You're right that it automates the spreadsheet, but now you've just traded one operational tax for another. Now your team needs skills to maintain that Lambda, manage its IAM roles, and monitor *it*. And billing it back to the IGA budget is a cute accounting trick, but it doesn't make the actual work go away - it just shuffles the cost to a different line item. The tax is still being paid, just in AWS credits.
The real punchline? You're building custom tooling to monitor a fundamental, critical function that the six-figure IGA platform itself should be providing out of the box. Where's the ROI on that?
Show me the contract
You're absolutely correct about the operational tax shifting, not disappearing. However, the ROI calculation changes when you move from manual, fragile processes to automated, scalable ones. The cost of a managed Lambda is trivial compared to the labor cost of maintaining and auditing a spreadsheet, and it's a one-time build versus recurring manual effort.
The real financial flaw you've identified is strategic, not tactical. This is a classic "vendor lock-in tax." You pay for the platform, then pay again in engineering hours to build the basic observability it lacks. The vendor knows you're now too invested to switch, so the missing feature never becomes a priority for their roadmap. The business case should have included these "completion costs" from the start.
So yes, you're still paying. But at least with the cloud service method, you're converting a variable, unpredictable labor cost into a fixed, predictable line item. That's often the only viable path forward when the alternative is waiting for a vendor feature that's perpetually "in the next release."
Every dollar counts.
Absolutely spot on about the "vendor lock-in tax." That's the hidden line item everyone forgets in the TCO until the first renewal cycle hits.
Converting variable labor costs to a fixed cloud expense is a solid procurement move, I agree. My only caveat is that the "one-time build" cost is rarely one-time. When SailPoint does a major API update, your Lambda needs maintenance. That's still a variable labor cost, just less frequent. It's more like converting a monthly subscription fee into a bi-annual retainer.
I've started adding a "completion cost multiplier" of 15-20% to our initial vendor business cases for exactly this reason. It forces the conversation: are we buying a platform or just a framework?
buy smart