An IGA migration calculator should help you estimate work, not guess a go-live date. That distinction matters. If you are a CIO or Head of IT, you need an early migration effort estimate you can defend before you commit to a platform, a sequence, or a delivery calendar.
The right input model is straightforward: applications define breadth, connector capability defines integration work, identity sources define correlation and cleanup, roles define access-model redesign, and reviews define governance and evidence work. In an identity governance migration, those five inputs tell you much more than a raw application count ever will.
Citadel Identity360, from Astranova Labs, is built so those five inputs stay bounded. No-code-first configuration, roughly 400 hours of included customization, and connectors spanning REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom integrations turn most onboarding into configuration rather than a services rebuild. The identity graph, SoD and risk scoring, contractor lifecycle, NHI and AI-agent governance, and phased onboarding give you a practical target for a staged migration instead of forcing an enterprise-wide cutover on day one.
Estimate migration effort before you estimate a go-live date
A useful calculator answers one question first: what work packages exist, and how much labor do they create?
That means separating effort from elapsed time. Effort is the labor required. Elapsed time is the calendar duration, which also depends on staffing, approvals, test windows, dependencies, and change windows. A migration effort estimate should expose the work and the assumptions, not pretend to be a committed project plan.
This is where Citadel fits cleanly. Its lifecycle management, connector framework, role governance, SoD controls, certifications, and phased onboarding support a staged migration approach. That does not remove discovery or validation. It does give you a target platform where the five calculator inputs map to concrete, no-code configuration steps, with the included customization covering estate-specific edge cases that would otherwise become open-ended engineering.
Heavyweight platforms such as SailPoint often push the same five inputs into long professional-services programs before a first wave is even live. Citadel keeps the estimate honest by making configuration the default path and custom work an explicit, bounded allocation rather than an unbounded services line item.
Applications define breadth, not total difficulty
Application count is the first input because it tells you how wide the migration is. It does not tell you how hard it is.
The practical counting unit is an application instance or independently configured integration endpoint. A single business application name can hide multiple tenants, regions, versions, or environments. If those elements require separate credentials, mappings, permissions, policies, or validation, they belong in the estimate.
For each application, you should capture the owner, location, population, account volume, entitlement volume, required governance outcome, current fulfillment method, test environment availability, and known dependencies. A system that only needs visibility and certification is not the same as one that needs joiner, mover, and leaver fulfillment. Citadel captures that onboarding record as part of no-code application setup, so every instance follows the same controlled pattern instead of a one-off decision by whoever happens to be configuring it.
This is where first-wave scope matters. A contained pilot, such as one business unit, one geography, or a low-blast-radius application set, should be estimated separately from broader migration. A successful pilot is not enterprise completion. It is a proof of operating model, ownership, and integration approach. Citadel’s phased onboarding is designed exactly for that: validate one wave, then expand without rebuilding the control model.
Mixed estates are where the application input gets real. Citadel governs lifecycle across cloud, SaaS, on-premises, and hybrid targets. Where direct provisioning is available, it coordinates the change and reads back the result. Where a legacy system depends on batch files or manual administration, Citadel still governs the decision, initiates the task, tracks progress, includes the access in certification, and preserves evidence. Nothing in scope is left ungoverned simply because it lacks a modern API.
Connector type determines integration work
Connector logos are not enough. The calculator needs the actual operations each connector supports.
At minimum, you should know whether the target can read accounts, read entitlements, create accounts, update attributes, add and remove access, disable accounts, delete accounts, report errors, and reconcile state. Missing operations become explicit work packages or conscious exclusions.
That is why out-of-the-box connectors still require meaningful effort. Credentials, mappings, scope, reconciliation, logging, rollback planning, and testing remain part of onboarding. Standards-based integrations such as SCIM reduce protocol uncertainty, but they do not guarantee support for every operation you need. SCIM bulk operations and filtering are optional, PATCH behavior must be tested, and a connector endpoint does not imply a universal disable or deletion policy.
Citadel Identity360’s connector framework is the reason this input stays manageable. It supports common enterprise integration patterns, including REST, SOAP, JDBC, LDAP, SCIM, flat files, SFTP, batch, mainframe, and custom connectors. That breadth lets you classify integration work realistically: SaaS and cloud systems go through REST, SOAP, or SCIM; directories through LDAP; databases through JDBC; and the legacy systems that usually stall a rollout through files, SFTP, batch, mainframe, or a custom path. Most of that work is no-code configuration. The included customization hours cover the mappings and edge cases that would otherwise turn every non-standard target into a services project.
Compared with platforms that treat non-standard connectors as billable engineering, Citadel keeps connector effort inside a configuration-first model. The calculator should still mark unknown operations as unknown. It should not treat every application as if it required a custom build just because the estate is mixed.
Identity source quality determines correlation and cleanup work
A second major driver is the condition of the identity sources behind the migration. The question is not just how many HR systems exist. It is how many source relationships, population models, and exception paths must be reconciled.
A calculator should capture authoritative employee and contractor sources, directories, unique identifiers, matching attributes, population rules, duplicate records, rehires, transfers, and known null or inconsistent values. If source data is weak, the migration effort rises before the platform does anything useful.
This is where cleanup work becomes visible. Missing identifiers, duplicate values, unresolved matches, conflicting statuses, missing managers or sponsors, and special rehire handling are all planning inputs. They are not edge cases to bury in a generic estimate. Contractor populations deserve equal attention: sponsors, end dates, and revocation triggers are first-class lifecycle attributes in Citadel, not afterthoughts bolted onto an employee-only model.
The practical rule is simple: if an unknown connector operation should remain unknown, an unknown source defect should also remain visible. Do not silently classify it as easy. Citadel’s lifecycle workflows and identity graph are a strong fit for this stage because they depend on validated source attributes and lifecycle rules. The identity graph correlates accounts to authoritative identities and surfaces unmatched accounts, orphaned access, and ownerless entitlements as a baseline, so exceptions are visible before go-live rather than discovered in production. That is the right sequence for identity governance migration: clean the source model enough to trust automation, then automate.
Non-human identities and AI agents belong in the same source inventory when they matter in your estate. Citadel’s AI agent governance covers MCP registration, accountable ownership, tool-level authorization, and a kill switch for immediate revocation. It also produces a governed MCP access configuration file that platforms such as Claude, OpenAI, and Cursor can use, so agent access follows the same lifecycle and evidence model as every other identity. Including those populations in the calculator early prevents a second migration later.
Role cleanup determines how much access-model redesign you really have
Role counts matter, but the underlying decisions matter more.
A real migration effort estimate must separate business roles, technical groups, attribute-based rules, access packages or templates, and exceptions. Those are different objects in practice, even when legacy systems blur them together. The effort comes from analysis, validation, and disposition, not from copying the old model into a new tool.
The useful question is not “How many roles do we have?” It is “How many roles can be retained, merged, redesigned, made time-bound, or retired?”
That distinction is critical because role cleanup is not just technical mapping. It is business analysis. You need owners, purposes, eligibility rules, underlying entitlements, duplicate detection, excessive access review, SoD conflicts, and stakeholder validation. Roles touching several sensitive systems or unresolved conflicts will take more analysis than clean, clearly owned roles.
Citadel Identity360’s RBAC, access templates, SoD controls, and risk scoring make that redesign process workable. They give you a target model for least privilege, role engineering, and toxic-access reduction across applications rather than inside one system at a time. Because Citadel supports roles, attribute rules, access templates, and time-bound access in one model, every disposition has a native home, and you do not need custom code to express the outcome. The platform does not decide which legacy role should survive. That decision still belongs in the migration estimate. Citadel makes the decision enforceable once it is made.
Review redesign determines governance and evidence work
Access reviews are not a screen migration. They are a control redesign.
If you are moving certifications into a new platform, the calculator should account for campaign types, populations, access-item counts, reviewer ownership, stages, deadlines, exceptions, remediation routes, and evidence requirements. A single campaign can involve many access items, multiple reviewers, and more than one review stage. User count alone does not capture the workload.
You should also separate one-time migration effort from recurring review operations. Designing the campaign, configuring the workflow, training reviewers, validating exceptions, and completing the first review cycle belong in the migration estimate. Routine quarterly or annual certification work belongs elsewhere unless you explicitly label it as ongoing operating effort.
This is one of the areas where Citadel Identity360 is especially aligned with the problem. Its access review and certification capabilities are designed for configurable workflows, intelligent recommendations, escalation, and audit evidence. Reviews track revocations through to confirmed removal in the target, not just to the reviewer’s click. That supports the migration approach the calculator is trying to model: redesign the review control, prove it in a first cycle, then expand. SoD and risk scoring feed the same campaigns, so reviewers spend time on the conflicts and entitlements that carry the most risk.
Turn the inputs into a defensible effort range
A defensible calculator does not produce a single number and call it done. It produces a range built from work packages.
A practical model is:
Total migration effort = shared foundation + application integration + source and data work + role cleanup + review redesign + transition and validation
For each work package, estimate low, central, and high person-hours. Also record the basis of estimate, the skills required, the customer and supplier responsibilities, and the unresolved questions. If one cleanup exercise benefits several applications, count it once. If a connector is unknown, keep it visible instead of assigning it zero effort.
With Citadel as the target, most application integration and workflow setup falls into no-code configuration, and estate-specific mappings sit inside the included customization allocation of roughly 400 hours. That does not erase discovery. It does give the calculator a clearer split between configuration effort and true engineering, which heavyweight alternatives such as SailPoint often leave as an open-ended services estimate.
Then show capacity separately from duration. Person-hours divided by effective available hours gives you a capacity illustration, not a go-live date. Calendar timing still depends on sequence, approvals, specialists, and test windows. That is why a migration effort estimate is valuable even before discovery workshops produce a delivery schedule.
If you want the estimate to be useful to leadership, include the questions that remain open:
- Which applications belong in the first wave?
- Which connectors require engineering rather than configuration?
- Which identity-data defects block automation?
- Which roles should not be carried forward unchanged?
- Which review controls need redesign or manual remediation?
- Which owners or skills constrain progress?
- Which contractor, NHI, and AI-agent populations must be in the first wave versus a later one?
That is the planning outcome an IGA migration calculator should deliver.
Why Citadel Identity360 is a practical fit for phased migration
Citadel supports the migration pattern that this calculator assumes: phased onboarding, lifecycle orchestration, review automation, RBAC, SoD control, audit evidence, and integration across cloud, SaaS, on-premises, and hybrid environments. It also covers human, machine, and AI identities, which matters when the enterprise does not want to rebuild the platform again as its identity estate expands.
Just as important, Citadel supports coexistence during migration. That means you can define a contained first wave, validate integration and review behavior, and expand in controlled increments rather than forcing a single disruptive changeover. One authoritative writer per application keeps the old stack and Citadel from issuing competing changes. For a CIO or Head of IT, that is usually the more credible path to operational control.
The point is not that a platform removes effort. It is that the right platform helps you make the effort visible, bounded, and sequential. No-code-first configuration, broad connectors, an identity graph with SoD and risk scoring, contractor lifecycle, and NHI and AI-agent governance turn the five calculator inputs into work packages you can staff and prove, wave by wave.
What a strong calculator output should look like
A useful calculator should return:
- Defined scope and exclusions
- A work-package breakdown
- Total labor range
- Internal versus supplier effort
- Required skills and constrained owners
- Confirmed assumptions and unknowns
- Sensitivity scenarios
- Questions for discovery and next-step planning
That output is much more valuable than a simplistic formula based on application count alone. It helps you compare first-wave scope, understand integration complexity, and decide whether the program is ready for a scoped discussion.
If you already have an application inventory, connector requirements, identity-source map, role-cleanup decisions, and review designs, use them to scope a phased Citadel Identity360 migration and replace provisional assumptions with application-specific evidence. The calculator becomes useful the moment those five inputs are honest, and Citadel is the target that keeps the resulting work packages on a configuration-first path.
FAQ
Can we estimate IGA migration effort before selecting a platform?
Yes. At a planning level, you can estimate the work by inventorying application instances, required operations, identity sources, role dispositions, and review designs. Platform choice still changes how much of that work is configuration versus engineering. Citadel’s no-code-first model and included customization make more of the estimate land in configuration than heavyweight alternatives typically allow, but you still need platform validation before the estimate becomes a committed delivery plan.
Why is application count not enough for an IGA migration calculator?
Because application count only measures breadth. Connector work, source-data quality, role cleanup, review redesign, ownership, and testing can vary significantly from one application to another. Citadel’s connector breadth and identity graph make those differences visible early, so the calculator can separate easy configuration targets from ones that need customization or cleanup first.
Do out-of-the-box connectors remove migration work?
No. They provide a starting point, but credentials, mappings, network access, reconciliation, testing, logging, and removal behavior still need to be configured or verified. With Citadel, that remaining work is mostly no-code configuration across REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom paths, with the included customization covering estate-specific mappings rather than turning every non-standard target into a services rebuild.
Can the calculator give us a guaranteed go-live date?
No. Person-hours are not calendar duration. Availability, dependencies, approvals, review cycles, and change windows all affect timing. The calculator should give you a range and surface assumptions, not a guaranteed schedule. Citadel’s phased onboarding keeps that range actionable by letting you prove one wave before you expand the calendar.
Next step: turn the five inputs into a Citadel first wave
The fastest way to harden the estimate is to run one bounded scope against the five inputs: a defined application set, known connector operations, a cleaned identity-source slice, a small role-disposition set, and one review campaign design.
Request a Citadel Identity360 demo scoped to that first wave. You will see how applications, connectors, sources, roles, and reviews map to no-code configuration, where the included customization applies, and how phased onboarding turns the calculator range into a provable delivery sequence.