Why Identity Projects Slip: The 4 Estimates That Go Wrong

The estimate that looked fine until week three

Identity projects do not usually fail in the demo. They fail when a "simple" SSO rollout turns into 14 legacy apps, three directory models, two compliance teams, and one business unit that refuses to change its login flow. In 2026, the pattern is still the same: the project slips because the first estimate was built on assumptions, not inventory.

The uncomfortable truth is that identity project estimates are wrong in the same four places every single time: scope, integration, migration, and operations. If you miss any one of them, your timeline drifts by weeks or months, and your cost model starts lying.

A recent enterprise pattern we see often: a 90-day CIAM rollout becomes 180 days after the team discovers 23 downstream systems, 6 custom auth flows, and a consent model that needs legal review in three regions. The code was not the problem. The estimate was.

1) Scope is never just "users and apps"

The first broken estimate is scope. Teams count the visible surfaces: the portal, the IdP, the top 10 apps. They forget the hidden work: service accounts, machine identities, partner tenants, break-glass access, and the policy exceptions that live in spreadsheets.

Why scope expands so fast

Identity touches every edge case in the enterprise:

• Human users, contractors, and B2B partners
• SaaS apps, on-prem apps, and API gateways
• Privileged access, local admin, and emergency access
• Regional privacy rules and data residency constraints
• Audit evidence, logs, and retention policies

If you estimate identity project scope as "one platform and a few integrations," you are already undercounting. A realistic mid-market rollout in 2026 often includes 25-40 applications, 3-5 identity stores, and 8-12 policy variants before launch.

What good scope estimation looks like

Use a discovery matrix before you commit dates. For each app, capture protocol, owner, auth method, user population, and migration risk.

App Discovery Matrix
- App name: Salesforce
- Owner: Revenue Ops
- Protocol: SAML 2.0
- User count: 4,800
- MFA: Native + conditional access
- Custom claims: 7
- Cutover risk: Medium
- Rollback path: Yes

A team that does this properly usually finds 20-30% more work than the first workshop suggested. That is not scope creep. That is the real scope.

2) Integration effort is dominated by the ugly apps

The second wrong estimate is integration. Architects often price the happy path: OIDC, SCIM, standard SAML, clean APIs. Then the project hits the apps that were never built to be modernized.

The apps that break the schedule

The schedule slips when you meet:

• Legacy Java apps with hardcoded session logic
• Mainframe or VDI access tied to old LDAP groups
• Vendor products with partial SAML support
• Apps that require header injection or reverse proxy auth
• Custom workflows that depend on username formats

In 2026, the average enterprise identity program still carries at least 15-25% of apps that need custom handling. One finance client estimated 12 hours per app for integration. The actual median was 31 hours, with three outliers above 80 hours because of custom claims mapping and test environment gaps.

A realistic integration estimate

Do not estimate by app count alone. Estimate by integration class.

integration_classes:
  standard_oidc:
    effort_hours: 6-10
    risk: low
  standard_saml:
    effort_hours: 8-16
    risk: medium
  scim_provisioning:
    effort_hours: 10-18
    risk: medium
  legacy_header_auth:
    effort_hours: 20-40
    risk: high
  custom_auth_bridge:
    effort_hours: 40-120
    risk: very_high

If your portfolio has 10 standard apps and 5 legacy apps, the legacy apps will consume most of the calendar time. That is why identity project estimates based on averages fail. The tail dominates the plan.

Architecture decision that saves weeks

Use a "modern first, bridge second" pattern:

1. Move standard apps to OIDC/SCIM.
2. Put legacy apps behind a single federation gateway.
3. Reserve custom code for only the exceptions that cannot be proxied.

This reduces the number of unique auth patterns your team must support. In one 60-app rollout, that cut integration work by 28% and reduced test-case count from 640 to 410.

3) Migration takes longer than the platform build

The third wrong estimate is migration. Teams budget for the new identity platform, but they underbudget the identity data cleanup, attribute mapping, and user comms that make migration possible.

Why migration is slower than expected

Identity data is messy:

• Duplicate accounts across directories
• Stale group memberships
• Inconsistent email aliases
• Missing MFA enrollment for inactive users
• Conflicting authoritative sources for job title, department, and manager

A clean migration is rarely a lift-and-shift. It is a data reconciliation project with security implications.

The hidden work in migration

A realistic migration plan includes:

• Directory normalization
• Attribute mapping and transformation rules
• Password reset or passkey enrollment strategy
• Parallel run and rollback design
• User support for first-login failures

Example: a 22,000-user workforce migration to Entra ID and passkeys can look like a 10-week build and a 4-week cutover. In practice, the data cleanup alone may take 6-8 weeks, especially if you need to resolve duplicate identities and align HR feed quality.

# Example: identify duplicate identities before migration
Import-Csv users.csv |
  Group-Object employeeId |
  Where-Object { $_.Count -gt 1 } |
  Select-Object Name, Count

If you skip this step, your cutover day becomes your data quality audit. That is the most expensive time to discover bad records.

Benchmark to use in planning

For a workforce identity migration, a useful planning baseline in 2026 is:

• 5-8 minutes per user for high-touch remediation
• 1.5-3 minutes per user for standard automated migration
• 10-20% extra time for exceptions, escalations, and support tickets

That means a 15,000-user migration can easily consume 400-900 labor hours before you count change management.

4) Operations are treated like overhead, then they eat the budget

The fourth wrong estimate is operations. Teams assume the platform will "run itself" after launch. It will not. Identity is a living service: certificates expire, policies change, apps break, and auditors ask for evidence at the worst possible time.

What operations actually includes

Operational cost is more than license renewals. It includes:

• Policy tuning and access reviews
• Certificate and secret rotation
• Incident response for auth outages
• Help desk tickets for lockouts and enrollment issues
• Quarterly audit evidence and control reporting
• Connector maintenance and vendor upgrades

In many enterprises, identity operations absorb 0.5-1.5 FTE per 1,000 active users once the platform is live. If you run CIAM at scale, support demand can be higher because customer login issues are directly revenue impacting.

A simple operating model that works

Treat identity like a product, not a project.

Identity Ops Model
- Platform owner: accountable for uptime and roadmap
- Security owner: policy, controls, and audit evidence
- App enablement team: new integrations and regression testing
- Service desk: enrollment, reset, and access requests
- SRE/infra: monitoring, alerting, and rollback

Add SLOs from day one. For example:

• Auth success rate: 99.95%
• MFA challenge latency: under 2 seconds at p95
• Directory sync lag: under 5 minutes
• Help desk first-response time: under 15 minutes for login incidents

If you do not budget for operations, the platform degrades, the business loses trust, and the next phase gets frozen.

Common Pitfalls

The same mistakes keep repeating because teams optimize for approval, not accuracy.

Pitfall 1: Estimating from vendor demos

A demo shows one app, one happy path, and one clean tenant. Your environment has exceptions, data debt, and governance. Build estimates from discovery, not slides.

Pitfall 2: Ignoring non-functional work

Logging, monitoring, DR, and compliance evidence are not extras. For identity, they are part of the delivery. A platform with 300 ms login latency but no audit trail is not production-ready.

Pitfall 3: Treating migration as a single event

Migration is a sequence: prep, pilot, parallel run, cutover, and stabilization. If you compress it into one weekend, you are borrowing time from support and incident response.

Pitfall 4: Underpricing exception handling

The 80/20 rule is brutal in identity. The last 20% of apps, users, or policies can consume 50% of the effort. Put a specific contingency line in the estimate, usually 15-25% for integration-heavy programs.

Pitfall 5: Forgetting the people cost

Training, comms, and support scripts are part of the project. If you introduce passkeys or phishing-resistant MFA, expect a temporary spike in tickets. A well-run rollout still sees 8-15% of users needing at least one support interaction.

A better way to estimate identity projects

You do not need perfect forecasts. You need estimates that fail less often.

Use a four-part estimate model

1. Scope estimate: count identities, apps, policies, and exceptions.
2. Integration estimate: classify each app by auth pattern and complexity.
3. Migration estimate: quantify data cleanup, cutover, and support.
4. Operations estimate: budget people, monitoring, and audit work for 12 months.

Add a risk multiplier

A simple model that works in practice:

Total effort = Base effort + Integration tail + Migration cleanup + Ops setup
Risk buffer = 15% for mature estates, 25% for mixed estates, 35% for legacy-heavy estates

If your organization has multiple directories, regional compliance constraints, and legacy apps, use the higher buffer. It is cheaper to carry contingency than to renegotiate halfway through the program.

What to ask before you commit dates

• How many apps need custom handling?
• How many identities are duplicated or stale?
• Which apps require human approval or exception workflows?
• What is the rollback plan for cutover?
• Who owns ongoing identity operations after launch?

If the answers are vague, the estimate is not ready.

Key Takeaways

• Estimate identity projects from discovery, not from the first workshop.
• The four estimates that go wrong are scope, integration, migration, and operations.
• Classify apps by auth pattern and complexity; app count alone is misleading.
• Budget migration as data cleanup plus cutover, not just platform work.
• Treat identity operations as a product function with SLOs, ownership, and support.
• Add a 15-35% risk buffer depending on how much legacy and exception handling you have.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.