How Long IGA Implementations Take Across Core Enterprise Systems

An IGA implementation timeline is rarely a single date. For most enterprises, the real question is whether you are planning a narrow first production wave, a focused enterprise rollout, or a broader governance program that spans HR, directory, SaaS, and cloud systems. On a clean, modern scope, the first wave can land in roughly 4–12 weeks. When you add legacy systems, multiple owners, or deeper testing, 3–6 months is a more realistic planning band. If your target state includes Workday Active Directory Microsoft 365 plus ServiceNow and cloud platforms, plan for a multi-wave program measured in months, not one connector project.

That distinction matters because IGA work is not just integration work. Discovery, data cleanup, connector onboarding, policy design, testing, remediation, and rollout can overlap, but they do not all finish at the same time. A CIO who treats first go-live as full governance will underestimate the schedule every time.

The short answer: first value comes faster than full governance

The fastest path is a tightly scoped first use case. That usually means one defined population, one HR source, a small application set, and core joiner-mover-leaver automation. In that shape, the first production wave can be live in weeks.

Once the scope includes older infrastructure, custom interfaces, or a heavier approval model, the calendar stretches. A focused enterprise first wave commonly takes about 3–6 months. If you are also adding access reviews, entitlement cleanup, external identities, cloud permissions, and organizational adoption, the work expands into later waves.

The mistake is assuming that a live connector equals a mature program. It does not. A credible first wave proves automation. Full governance comes later.

What the planning bands actually mean

The most useful way to think about an IGA implementation timeline is by outcome, not by vendor label. A narrow modern rollout can move quickly because the source data is cleaner, the connector path is standard, and the approval chain is shorter. A broader enterprise rollout is slower because identity governance touches ownership, policy, testing, and operating behavior.

Here is the simplest planning view:

Workstream	Planning band
Discovery and scope	1–3 weeks
Identity-data cleanup	2–6 weeks
Application and entitlement mapping	2–5 weeks
Connector onboarding	Varies by application and interface
Policy and workflow design	1–4 weeks
Testing and pilot	2–4 weeks for the first validation wave
Remediation and evidence validation	2–6 weeks
Lifecycle expansion	3–8 weeks per meaningful wave
Broader rollout and adoption	Ongoing over months

Do not add those ranges together mechanically. They overlap. Discovery can run while data is being cleaned and connectors are being prepared. Testing can begin before every application is onboarded. The schedule is governed by dependency, not arithmetic.

Why discovery and data cleanup decide the pace

Discovery sets the shape of the program. Before you commit to dates, you need the first business outcome, the authoritative identity source, the target populations, and the in-scope applications. You also need named owners for approvals, testing, and operations.

Data cleanup is where many programs either speed up or stall. An IGA platform can automate bad data just as efficiently as good data. If worker identifiers, manager fields, status values, or ownership records are inconsistent, the system will surface those problems immediately. In practice, this is where you sort out duplicate accounts, null identifiers, rehires, transfers, and cases that do not map cleanly.

For a CIO, this is not an implementation detail. It is a schedule risk. Clean data shortens the path to production. Poor data turns every later step into a remediation exercise.

Why application onboarding is often the longest variable

The phrase application onboarding sounds simple. In practice, it includes authentication, network access, attribute mapping, entitlement mapping, matching keys, scope filters, testing, logging, reconciliation, and rollback planning. That is why an “out of the box” connector can still take meaningful time to finish.

A repeatable onboarding packet helps, but each application still has to answer the same questions: who owns it, what does create or disable mean, what attributes match a person to an account, and what happens when the source record is incomplete or the target API fails.

This is also where modern and legacy environments diverge. Standard connectors usually fit inside a focused wave. Custom files, databases, and older interfaces take longer because they require more design, more testing, and more exception handling.

Where Workday and Active Directory usually sit in the sequence

For many organizations, Workday is the worker source of truth and Active Directory or Microsoft Entra is the next dependency. That is why the Workday Active Directory Microsoft 365 sequence often defines the critical path for identity lifecycle work.

Workday usually needs to be clean enough to drive joiner, mover, and leaver events. That means stable worker identifiers, clear status values, and a deliberate choice about contingent workers, rehires, future-dated hires, and multiple positions. If those decisions are unsettled, every downstream system inherits the ambiguity.

Active Directory adds another layer of timing. It is quick when there is one healthy forest, an existing agent host, open network paths, and a small target population. It becomes slower when there are multiple forests, disconnected networks, restrictive firewall changes, unclear ownership, or complex account matching.

Microsoft 365 sits on top of both as a governance surface. One rollout may start with identity lifecycle in Entra. Another may extend into group ownership, access packages, and access reviews. Those are related, but they are not the same project.

Why ServiceNow and cloud platforms extend the schedule

ServiceNow often looks straightforward from a connector standpoint. The actual schedule is usually driven by process alignment. You are not just syncing records. You are deciding whether access requests, approvals, fulfillment, revocation, and audit ownership will run inside the same operating model.

Cloud platforms add more complexity because “cloud onboarding” can mean very different things. In AWS, you may be dealing with SCIM provisioning plus permission-set governance. In Azure, role hierarchy, scope, and privileged access decisions matter. In Google Cloud, federation design and group limits matter. In OCI, identity domains, federation, and provisioning are separate paths that need to be distinguished early.

In other words, the connector is only part of the job. The schedule is usually driven by governance decisions more than by the initial technical handshake.

What shortens an IGA program

Shorter programs usually have the same traits:

• A narrow first outcome and a defined population

• One trusted HR source with clean worker data

• An existing directory or identity foundation

• Standard connectors instead of custom interfaces

• Application owners who can make decisions quickly

• A simple policy model for birthright and requestable access

• A pilot with small scope and clear rollback

• Parallel workstreams for data, policy, and testing

• Agreement on what will not be governed in wave one

These are not cosmetic advantages. They reduce rework. They also lower the risk that the first go-live becomes a half-finished operating model that the service desk has to carry.

What lengthens an IGA program

Longer deployments usually have the opposite pattern:

• Vague scope or an attempt to govern everything at once

• Poor HR or directory data

• Multiple forests, tenants, or acquired environments

• Custom or legacy applications

• Large or poorly owned groups

• Complex role engineering or SoD decisions

• Privileged access, cloud access, or external identities added too early

• Bundle scope that mixes connector delivery with ITSM redesign

• Security, licensing, or change-control delays

• Training and adoption treated as an afterthought

The technical work is only part of the answer. Organizational readiness matters just as much. A connector can be live while managers do not know how approvals work, reviewers do not respond, and the service desk still uses the old process in parallel.

A realistic way to plan a 90-day foundation

A 90-day milestone can be legitimate, but only as a foundation. It is not full maturity.

A realistic 90-day outcome usually includes agreed scope and ownership, cleaned identity data, mapped priority applications, initial workflows, a first review or pilot, and a decision on what happens next. That is enough to prove direction and reduce uncertainty. It is not enough to claim that the enterprise is fully governed.

For many CIOs, that is the right milestone to target. It creates a decision point without pretending the entire identity program is done.

The practical takeaway for CIO planning

The safest planning model is simple: separate first value from full governance. Use the faster band when the scope is narrow and the systems are modern. Use the 3–6 month band when legacy integration, ownership complexity, or process redesign is involved. Then assume additional waves for broader governance, not a one-time finish line.

If you are mapping your own environment, start with the identity sources, priority applications, cloud accounts, populations, policies, and owners. That gives you a real scope conversation instead of a generic timeline promise. If you want a platform like Citadel Identity360 to support the work, use it as the structure for lifecycle automation, access reviews, risk analytics, SoD, and integrations. Do not use product features as a substitute for planning.

FAQ

Can a company implement IGA in 30 days?

Only for a tightly bounded first use case with clean data, standard integrations, and quick access to owners. A 4–12-week first production range is more defensible than a blanket 30-day promise.

Should Workday or Active Directory be connected first?

Usually Workday comes first when it is the authoritative HR source, then the directory or Entra layer, then the highest-value applications. But the actual sequence should be confirmed during discovery.

Why can an out-of-the-box connector still take weeks?

Because the connector is only one piece of the work. Authentication, mappings, scopes, tests, approvals, reconciliation, and rollback still have to be designed and validated.

What should a CIO ask before accepting an IGA timeline?

Ask what the estimate includes and excludes, whether it covers first go-live or full rollout, which applications and populations are in scope, which connectors are standard or custom, what customer-side effort is required, and what assumptions would move the date.

The right IGA implementation timeline is the one that reflects scope, data quality, integration complexity, policy decisions, testing, and adoption. Once those variables are visible, the timeline becomes manageable. Without them, it is just a guess.