Origin
Pranay has spent the past quarter on calls with IT leads at companies running SailPoint. Some had been deploying for two years. Some inherited a half-built rollout from a predecessor. A few were quietly building the case for ripping it out. None said the product was bad. All described the same handful of failures.
When teams say "we have problems with SailPoint," they're usually describing one of three things. The product is not the issue. The fit is.
Failure 1: The implementation that never finished
The most common pattern: a 400-to-600-person company bought SailPoint two years ago, brought in a partner for a nine-month rollout, and is now at 18 months with maybe 30% of their app inventory connected. The professional services bill has crossed $400K. The roadmap to complete keeps slipping because the team building it is also doing day-to-day IT.
What's actually happening: SailPoint is a connector-by-connector deployment, and every non-standard app needs a custom integration. At enterprise scale that's fine because there is a dedicated IAM team grinding through it. At 500 employees there isn't, so the long tail of apps stays manual indefinitely. The deployment becomes a permanent half-state.
Failure 2: The maintenance black hole
Companies that did finish the implementation often describe the second failure. The deployment works, but it requires constant attention. Connector updates when vendors change their APIs. Policy adjustments as the org evolves. New apps added to the catalog. Role definitions drift from what teams actually do.
Someone has to own this. When that person leaves, the institutional knowledge of how the policies were structured walks out with them. In the past six months we've heard from three companies running SailPoint who can't make changes to their deployment because the original admin is gone and nobody on the current team understands the configuration.
Failure 3: The audit-coverage gap
The third pattern is the most subtle. SailPoint is in place. The SOC 2 report says access management: compliant. The box gets checked. But what SailPoint actually governs is the SCIM-enabled subset of the environment, which is the modern SaaS tools that already have decent provisioning controls on their own.
The orphaned-account risk lives in the rest of the stack: the legacy app finance uses, the vendor portal nobody owns, the LIMS or the EHR or the trading system. None of those connect to SailPoint. They get governed manually, or not at all.
The compliance posture says complete coverage. The actual coverage is partial. The auditor doesn't ask which apps are governed by SailPoint and which aren't, so the gap doesn't show up until something goes wrong.
What the signal means
These failures are not bugs in SailPoint. They are consequences of using a tool built for 5,000+ employees inside companies that don't have the team, the budget, or the time horizon SailPoint assumes.
The honest version of the conversation isn't "is SailPoint good?" It's "what does the failure mode look like when SailPoint is the answer to a question this company isn't actually being asked?"
The pattern we keep hearing: most companies under 1,500 employees who bought SailPoint regret it within 18 months. Not because the product disappointed them. Because the fit was always wrong.