The poll data shared in this thread is the most honest benchmark available: out of 15 identity professionals who responded, the largest group (6) said their implementation took 1.5 to 2.5 years, and 3 more said 2.5 years or longer. Only 2 came in under 12 months. This is the real distribution for enterprise IGA implementations — not what vendors show in their time-to-value slides.

Understanding what drives this timeline is more useful than either accepting it as inevitable or dismissing it as the result of poor planning. Some of it is inherent to the problem. Some of it is platform-specific. And some of it is genuinely addressable.

What "End-to-End Implementation" Actually Covers

The poll question asked about end-to-end implementation from planning through configuration and rollout. This framing matters because vendors and customers sometimes use different definitions:

Vendor definition: "Went live" often means the first use case is operational in production — typically the core JML workflow for employees, connected to the 20 highest-priority applications. This is achievable in 3-6 months for enterprise platforms and 4-12 weeks for modern platforms with limited scope.

Customer reality: End-to-end implementation means the platform is governing the full intended scope — all planned connectors configured and stable, access reviews running for all in-scope applications, all departments provisioned, governance program embedded in ongoing IT operations. This is what takes 1.5-2.5 years, even when the initial "go live" happened in month 6.

The gap between "technically live" and "fully operational" is where most of the timeline lives. Understanding this distinction before you start sets more accurate internal expectations.

What Drives Long Implementation Timelines

Architecture and source of truth definition. Before any platform configuration begins, you need clarity on: which system is the authoritative source for which identity attributes, how the IGA tool sits between your HRMS, your IdP, and your applications, and what the request-to-fulfillment flow looks like. This architectural work takes time because it requires organizational decisions — which system wins when Workday and AD disagree on a user's department — that don't have obvious right answers and require stakeholder consensus.

For complex enterprise environments, the initial architecture sessions alone can take weeks. Skipping this work and configuring before the architecture is resolved is the most common cause of implementations that have to be partially rebuilt.

Data quality. IGA automation is only as reliable as the data it runs on. Implementation cannot proceed meaningfully until the source of truth is clean: employee records have accurate departments, job titles, and manager assignments; terminated employees are correctly marked; contractors are distinguishable from employees. Most organizations discover data quality gaps during implementation that they didn't know existed — HR records that were accurate enough for HR purposes but not accurate enough for automated access provisioning decisions.

The time required to identify and remediate data quality issues is implementation time that vendors rarely account for in their timeline estimates.

Connector development and testing. Every application that needs to be governed requires a working, tested connector. Standard applications with mature SCIM integrations deploy quickly. Applications with limited API support, legacy systems, or custom internal tools require more time — sometimes weeks per connector — for configuration, testing, and validation. The more non-standard applications in your scope, the longer the connector phase takes.

Organizational change management. IGA implementation isn't just a technology project. It requires application owners to participate in access reviews, managers to respond to certification campaigns, HR to maintain data that drives automation, and security teams to approve the platform's access to critical systems. Getting these stakeholders aligned, trained, and actively participating takes time that doesn't appear in implementation plans.

IGA projects fail because of political infighting, not technical problems. The time to secure organizational buy-in is implementation time.

Scope expansion. Most implementations start with a focused scope (employees + 20 applications + core JML) and expand over time. The expansion phases — adding more applications, adding contractors and external users, adding access reviews, adding SoD controls — are part of the end-to-end implementation even if they're labeled "phase 2" or "phase 3" in the project plan.

Platform Choice and Timeline

Legacy enterprise platforms (SailPoint IIQ, Saviynt). The 1.5-2.5 year range in the poll reflects implementations at this tier. The configuration complexity — static access profiles that must be defined upfront, BeanShell custom logic for non-standard scenarios, connector development for the full application stack — genuinely takes this long when done thoroughly. Organizations that "go live" in 6 months with a legacy platform have typically scoped themselves to a narrow use case and have significant work remaining.

SailPoint ISC. Faster than IIQ due to the more configuration-driven model. Practitioners with recent ISC implementations report 3-6 month timelines for focused initial scope, with continued expansion into the 12-18 month range for full program deployment.

Modern mid-market platforms (Zluri, Lumos). The 4-12 week timeline Zluri targets is for the initial production deployment — the first JML workflow and initial application set running in production. This is realistic for the first phase. The full governance program covering all planned applications and use cases still takes longer, but the initial time-to-value (first compliance evidence, first automated offboarding) comes significantly earlier.

The honest framing: modern platforms don't compress 2 years of governance program development into 8 weeks. They deliver initial operational value in 8 weeks while the broader program continues to develop.

What You Can Do to Accelerate Without Cutting Corners

Define the architecture before touching the platform. The most common implementation delay is starting configuration before the source of truth hierarchy, the request-to-fulfillment flow, and the connector scope are clearly defined and agreed. Spending 2-4 weeks on architecture before the platform is configured saves months of rework.

Start with a focused use case. The implementations that succeed fastest pick one well-defined problem (offboarding automation for employees, access reviews for the 10 highest-risk applications, birthright provisioning for a specific department) and make it work completely before expanding. Scope creep into multiple use cases simultaneously is the most common cause of implementations that stretch from months to years without producing meaningful governance value.

Fix data quality before configuring automation. Audit your HRMS data against your current user population before building any automated provisioning logic. Finding that 15% of employee records have incorrect department codes after you've built role-based provisioning logic is worse than finding it before.

Don't wait for perfect before going live. The organizations in the "1 year" buckets in this poll often got there by running a well-scoped initial phase rather than trying to govern everything before going live. "Good enough to govern the most important 20 applications" is a more achievable 6-month milestone than "governing all 150 applications."

Include stakeholder readiness in your timeline. Application owner training, manager certification campaign onboarding, and security team approval for platform access are all on the critical path. Treat them as implementation work rather than post-launch activities.

What "Fast Implementation" Claims Actually Mean

When vendors claim 4-week implementations, ask specifically: what is the scope that achieves go-live in 4 weeks? Typically: a single HR source, a small set of standard applications (5-10), and the core JML workflow for a defined user population. That's a legitimate starting point for a governance program — not a complete implementation.

The better question isn't "how fast can we go live" but "what does the first governance milestone look like and when does it produce value?" The answer to that question — first automated offboarding running in production, first access review evidence generated for SOC 2 — is achievable faster with modern platforms than with legacy ones. The complete governance program takes longer regardless of platform choice.

Frequently Asked Questions

How long does a typical IGA implementation take?

Based on practitioner data, most enterprise IGA implementations take 1.5 to 2.5 years from planning to full rollout. The initial "go live" (first use case in production) is achievable in 3-6 months for legacy enterprise platforms and 4-12 weeks for modern mid-market platforms with focused initial scope. The gap between initial go-live and full program deployment accounts for connector expansion, organizational change management, and the iterative addition of governance use cases.

What factors most influence IGA implementation length?

The factors that consistently extend IGA implementations are: architecture and source-of-truth decisions that require organizational consensus, HR data quality issues that must be resolved before automation can work correctly, connector development for non-standard and legacy applications, organizational change management to get application owners and managers actively participating, and scope expansion beyond the initial use case.

Can modern IGA platforms really implement in weeks?

Modern platforms like Zluri can deploy an initial production use case (core JML workflow, 5-10 standard applications, first access review campaign) in 4-12 weeks. The caveat: this is the initial deployment, not the complete governance program. Organizations moving from no governance to first-milestone governance do this faster with modern platforms. Organizations with complex multi-system environments, significant legacy application estates, and enterprise-scale scope are building a governance program that takes longer regardless of platform choice.