Migrating from SailPoint to Citadel Identity360: Key Planning Considerations

Migrating from SailPoint to Citadel Identity360 is not a configuration export. It is an identity governance operating-model change. If you are considering an IGA migration, the first question is not which screens look similar. It is what your current SailPoint estate actually governs, what behavior must be redesigned, and how you will preserve access control, remediation evidence, and audit continuity during coexistence and cutover.

For CIOs and Heads of IT, that means planning around identities, roles, certifications, connectors, policies, and historical records before you move a single workload. Citadel Identity360 may be a strong candidate for organizations that want governance across human, machine, and AI identities, but the decision should be validated against your own estate, not assumed from a feature list.

Start with the migration boundary, not the platform

The first planning decision is what SailPoint environment you are replacing. “SailPoint” can mean IdentityIQ, Identity Security Cloud, formerly IdentityNow, or a mix of both. That matters because the detailed object behavior in the research is primarily about Identity Security Cloud, and the architectural guidance is not universal across every SailPoint estate.

Before any mapping begins, build a source-of-truth inventory of what exists today: identity sources, accounts, entitlements, roles, access profiles, lifecycle rules, workflows, certifications, SoD policies, audit reports, and manual procedures. Include non-human identities as well, including service accounts, API identities, cloud roles, workloads, bots, and AI agents.

This is the moment to classify each item as retain, redesign, retire, replace, or validate in proof of value. That classification keeps dormant roles, obsolete scripts, unused applications, and technical debt from being carried forward simply because they already exist.

For a decision-stage IGA migration, the boundary questions are straightforward:

• Is the scope IdentityIQ, Identity Security Cloud, or both?

• Will Citadel be the governance system only, or also the provisioning and deprovisioning control plane?

• Which source remains authoritative for each identity attribute?

• Which applications are mission-critical, regulated, high-risk, or hard to reverse?

• Which historical records must remain available to auditors after SailPoint is retired?

• Which manual tasks are controls, and which are just workarounds?

• Which machine and AI identities are currently outside the governed population?

The answer to those questions determines whether you are replacing a platform or redesigning an operating model.

Reconcile identities and lifecycle behavior before you move access

The next step is to preserve the relationship between identity, account, ownership, lifecycle state, and access history. That is the part teams often underestimate when they migrate from SailPoint.

In SailPoint Identity Security Cloud, identity profiles define lifecycle-state behavior. New profiles include pre-hire, active, leave-of-absence, terminated, and archived states. Those states can enable, disable, or delete source accounts, remove access, and grant access profiles. The lifecycle-state attribute is mapped to a source attribute, and the value must match the configured technical name.

Citadel Identity360 is positioned for Joiner-Mover-Leaver automation, provisioning and deprovisioning orchestration, and governance across connected and disconnected applications, including human and non-human identities. Those are capabilities to validate with real test data, not assumptions to carry over from the old platform.

Your migration inventory for each identity class should include:

• Stable identity key and source-system identifier

• Legal name, display name, email, manager, department, location, job code, employment type, and organizational unit

• Worker status and lifecycle-state value

• Start date, end date, leave status, rehire behavior, and transfer behavior

• Duplicate and alias rules

• Account identifiers for every connected source

• Correlation keys and fallback logic

• Account ownership and sponsor information

• Privileged status and elevated-account relationships

• Service-account, workload, application, bot, and AI-agent ownership

• Required access at each lifecycle state

• Access that must be removed, disabled, or deleted during termination

• Exceptions, manual approvals, and application-specific termination tasks

Then test the lifecycle outcomes directly. A good migration should prove that a new hire gets baseline access and nothing more, a mover loses obsolete permissions, a leave-of-absence follows the intended disablement policy, and a termination actually removes or disables access in the target application, not just in the governance layer.

The important discipline is simple: do not assume “deprovisioned in the IGA platform” means “removed from the target system.” The target application must confirm the actual state.

Translate roles and entitlements by behavior, not by name

Role migration is where many IGA programs drift into false equivalence. A role name rarely tells you how access is granted, inherited, removed, or left behind. That is why role translation needs business logic, not object copying.

In SailPoint, roles can group access from multiple sources, represent job functions or departments, and include entitlements and access profiles. Dynamic roles can grant birthright access based on criteria. Access profiles bundle entitlements from a single source and can be used in roles, lifecycle states, access requests, or automated provisioning. Entitlement records also carry useful migration fields such as source, owner, requestability, assignment type, and whether access is standing or Just-In-Time.

You need to answer the mapping questions in business terms:

• Is this a business role, technical role, application role, access profile, entitlement bundle, group, permission set, or individual privilege?

• Is access assigned directly, through a role, through a lifecycle state, through an access request, or manually?

• Is the access standing, time-bound, or Just-In-Time?

• Who owns, approves, reviews, and remediates it?

• What happens when a user leaves the role?

• What happens when two roles grant the same entitlement?

• Is the role driven by static membership, attribute criteria, or an external calculation?

There is also SailPoint-specific behavior that must be tested, not guessed. Role changes may require an explicit Apply Changes action. When a user leaves a role, access granted only through that role may be removed, but overlapping access from another role can remain. Disabling or deleting a role removes it from the request center, but it does not necessarily deprovision access already granted through that role.

Citadel Identity360 is described as supporting RBAC, dynamic or context-aware role assignment, entitlement discovery, least-privilege recommendations, and identity-to-access relationship visibility. During proof of value, ask Astranova to demonstrate how SailPoint roles and access profiles are imported, transformed, or rebuilt, how overlap is handled, and how access-path visibility is preserved.

Rebuild certification campaigns and preserve the evidence

Certification is one of the clearest places where a naive migration can change governance outcomes without anyone noticing. The reason is simple: not every access item is certifiable in the same way, and not every certification object maps cleanly across platforms.

In SailPoint Identity Security Cloud, certifications may contain entitlement, access-profile, and role data. Roles approved through access requests can be approved or revoked, while roles assigned automatically through criteria can generally be acknowledged. Access profiles obtained by request or detected from entitlements can be certified. Access profiles granted through a role or lifecycle state may not appear individually, and entitlements encapsulated inside roles or access profiles may not be individually certifiable.

That means you need to preserve both the campaign logic and the decision history. Before retiring SailPoint campaigns, export:

• Campaign composition, including IDs, type, dates, filters, included sources, and undecided handling

• Campaign status, including reviewer, identity, item type, decision state, decision, comments, and revocation status

• Remediation status, including completion state and completion date

• Sign-off details

• Supporting evidence such as reassignment history, escalations, tickets, confirmations, and source-side verification

This is not optional documentation work. SailPoint campaign reports can be downloaded as CSV or PDF, but they reflect the most recent campaign status, and deleting a campaign deletes its reports. If you need the evidence later, export it before the environment or campaign disappears.

Citadel Identity360 is positioned to support access requests, approvals, reviews, certification campaigns, risk-based certification, centralized evidence, and remediation verification. The right question is not whether that sounds aligned. The right question is whether it can reproduce your current governance model for direct, inherited, role-based, lifecycle-based, and temporary access, while keeping reviewer assignment, escalation, self-review prevention, and remediation verification intact.

Reassess connectors by operation, not by count

Connector planning is where many teams make a classic mistake: they count integrations instead of testing operations. A connector that can read accounts is not the same as one that can create, update, disable, revoke, reconcile, and verify remediation.

That distinction matters because migration risk often lives in the details of application behavior. A connector that can read accounts is not the same as one that can create, update, disable, revoke, reconcile, and verify remediation.

That distinction matters because migration risk often lives in the details of application behavior. For every priority application, document:

• Application and business owner

• Criticality and regulatory significance

• Identity and account objects

• Entitlement and group objects

• Read or aggregation method

• Correlation and reconciliation method

• Create-account behavior

• Attribute-update behavior

• Enable, disable, delete, and suspend behavior

• Entitlement assignment and revocation

• Password or credential operations, if applicable

• Error, retry, timeout, and rate-limit behavior

• Manual fulfillment steps

• Service-desk dependencies

• Scheduled jobs and aggregation cadence

• Custom code, rules, scripts, and owners

• Rollback method

• Evidence produced for each operation

Citadel Identity360 is described as supporting prebuilt and extensible integrations across cloud platforms, enterprise SaaS, directories, databases, web services, files, batch feeds, mainframes, and proprietary systems. Named examples and integration methods are broad, but that does not mean every named system supports every operation.

So do not ask whether Citadel “integrates with” a tool. Ask what operations are supported for that tool. In many programs, a read-only integration may be enough for discovery, while a high-risk application may require full provisioning and verified revocation. That is the level at which connector validation belongs.

Translate policy and SoD controls with their operating context intact

Policy migration is not just about copying the conflict rule. You need to preserve the rule, its owner, its risk rating, its exception path, its remediation guidance, and its evidence trail. Otherwise, the policy may exist in name only.

SailPoint’s SoD model uses two lists of access, and a violation occurs when a human identity has access in both lists. Policies can include entitlements, roles, and access profiles. Policy records also carry the owner, co-owners, violation owner, risk classification, mitigating controls, mitigation advice, remediation advice, schedule, subscribers, and violations.

SailPoint also has specific limits that matter for planning, including 500 total policies per organization, up to 50 access items on each side of an access-based policy, and up to 10 co-owners where the configuration supports them. Those are SailPoint constraints, not Citadel constraints, so do not carry them over by assumption.

Your migration inventory should capture:

• Policy name and business purpose

• Regulatory or control reference

• Enabled status and schedule

• Risk level

• Access items in each conflict list

• Whether matching is direct, inherited, role-based, or lifecycle-based

• Policy owner, co-owners, and violation owner

• Mitigating controls and exception approvals

• Remediation instructions

• Notification recipients and escalation rules

• Current and historical violations

• Evidence of policy runs and control operation

Citadel Identity360 is positioned for cross-application SoD controls, real-time toxic-combination monitoring, policy enforcement, risk analytics, and remediation workflows. The migration team should validate parity with known positive and negative cases, rather than assuming feature labels tell the full story.

Plan audit continuity before you cut over

Audit continuity has two parts: historical evidence and forward evidence. The first is what SailPoint already recorded. The second is what Citadel will record after each population, application, or process moves.

SailPoint Identity Security Cloud audit reporting tracks activity across access requests, authentication, password updates, provisioning, source activity, application configuration, certifications, identity and user management, SoD policy activity, and workflows. Default reports include All Events, Access Request Activity, Authentication Activity, Password Changes, Provisioning Activity, and All Source Activity excluding provisioning. Audit data is retained for one year plus the current month, and older data up to five years may be requested through support.

That means evidence export is a control requirement, not a cleanup task. Before migration, identify every report required by internal policy, auditors, and regulators. Export campaign reports, policy definitions, violations, exceptions, remediation records, access-request histories, provisioning activity, and relevant account and entitlement activity. Preserve timestamps, time zones, identifiers, decision comments, and report-generation dates. Store everything in a controlled, searchable evidence repository.

During coexistence, be explicit about which platform is authoritative for each application and identity population. Avoid dual-write conflicts unless the operating model controls them. Preserve mappings between old and new identity, account, role, entitlement, policy, and campaign IDs. Reconcile SailPoint and Citadel results for the same test population.

After cutover, confirm that Citadel records requests, approvals, provisioning, revocation, certifications, policy decisions, exceptions, and remediation verification. Keep the legacy evidence repository read-only where appropriate, and close out open SailPoint certifications and policy violations before retiring the old process.

Citadel Identity360 is described as supporting audit-ready evidence, access-path visibility, and centralized records of access and remediation. Still, you should confirm retention, export formats, chain of custody, immutable-history behavior, API access, and auditor permissions before making it authoritative.

Choose phased cutover and define rollback conditions

A controlled phase is safer than a broad replacement. For a SailPoint migration, practical phase boundaries might be a low-risk application group, a business unit, a source system and its dependent applications, a lifecycle process such as contractor onboarding, or a governance domain such as access reviews for a defined application set.

Do not choose the phase solely by application count. A small privileged system can be riskier than a larger set of ordinary SaaS applications.

A phase should not start until these conditions are met:

• Identity source and correlation are understood

• Owners and approvers are confirmed

• Entitlement inventory is reconciled

• Connector operations have been tested

• Lifecycle behavior has passed positive and negative tests

• Roles and policies have an approved target design

• Certification and audit evidence requirements are documented

• Manual fallback and rollback procedures are assigned

• Service desk and application teams know the cutover boundary

A phase should not close until you can show:

• No unexplained identity-correlation differences

• Expected accounts and entitlements match the approved baseline

• Joiner, mover, leaver, request, certification, SoD, and remediation tests pass

• Rejected access is removed or handled by documented manual process

• Audit evidence is complete and retrievable

• Owners accept the new workflow

• Open incidents, exceptions, and residual risk are documented

Rollback planning needs the same discipline. Decide which system can safely resume provisioning, how duplicate writes will be prevented, which changes must be reversed, how deltas will be reconciled, who can stop the phase, and what evidence proves the rollback occurred.

That is the practical shape of an IGA migration. It is controlled, observable, and reversible.

Decision table: what to carry forward and what to validate

Workstream	Capture from SailPoint	Validate in Citadel Identity360
Identity and lifecycle	Identity keys, attributes, correlation, lifecycle states, account actions, owners, sponsors, JML rules	Joiner, mover, leaver, contractor expiry, privileged and non-human identity ownership, account disablement and deletion behavior
Access model	Entitlements, access profiles, roles, role criteria, direct versus inherited access, standing or temporary access	Role and entitlement representation, requestability, least-privilege logic, overlap handling, role removal, access-path visibility
Governance and evidence	Campaign definitions, reviewer assignments, decisions, revocations, SoD policies, violations, audit reports and retention	Certification workflow, AI recommendation explainability, SoD parity, remediation verification, export, retention, auditor access, historical-evidence strategy

What to ask before you move from SailPoint

If you are preparing to migrate from SailPoint, the vendor discussion should focus on proof, not promise. The most useful questions are:

• Can Citadel ingest a representative identity, account, entitlement, role, policy, and certification dataset?

• What migration utilities and import formats are available?

• Which SailPoint objects are imported, which are transformed, and which must be rebuilt?

• How are direct, inherited, role-based, lifecycle-based, temporary, and Just-In-Time permissions represented?

• Can the platform show the full access path from identity to resource, including the grant source, approver, policy, and remediation result?

• Which operations are supported per priority application: aggregation, correlation, create, update, enable, disable, delete, assign, revoke, reconcile, and verify?

• How are failed operations retried, reported, escalated, and audited?

• How are disconnected or manual applications governed and evidenced?

• How are SailPoint certification decisions and open remediation tasks handled?

• Can historical SailPoint reports remain searchable without being rewritten as new Citadel events?

• What are the retention, export, access-control, and chain-of-custody guarantees for audit evidence?

• How are SoD exceptions, mitigating controls, policy schedules, and violation owners migrated?

• How are service accounts, cloud workloads, bots, AI agents, and other non-human identities assigned owners and lifecycle controls?

• Can administrators change workflows and policies without product-specific development?

• How are AI recommendations explained, overridden, logged, and reviewed by a human?

• What is the rollback method if a connector or lifecycle process fails after cutover?

Those questions separate a planned IGA migration from a platform swap that only looks simpler on paper.

Closing direction

A successful IGA migration preserves governance outcomes, not just configuration objects. If you plan to move from SailPoint, start with a complete identity and access inventory, redesign roles and policies where needed, test every connector operation, preserve historical evidence, and validate coexistence before expanding scope. Citadel Identity360 may be a fit for organizations that want unified governance across human and non-human identities, but the decision should rest on your own applications, controls, data, and proof-of-value results.

If you are evaluating the next step, begin with your highest-risk applications, lifecycle events, certification campaigns, and audit requirements. That will tell you far more than a feature matrix ever will.

FAQ

Is migrating from SailPoint a lift-and-shift?

No universal lift-and-shift assumption is safe. The source product, custom logic, connectors, role design, policy model, and audit requirements determine what can be reused. Treat configuration as behavior to assess and redesign.

Will SailPoint roles and certifications automatically become Citadel roles and certifications?

That is not established by the evidence. Inventory how each role and access item was granted, decide what to retain or redesign, and preserve historical certification reports independently.

Can every SailPoint connector be replaced directly?

No. Connector capability depends on the target application. Test aggregation, correlation, provisioning, disablement, deletion, revocation, reconciliation, retry handling, and remediation verification per application.

How do we maintain audit continuity?

Export SailPoint campaign and audit evidence, document identifiers and timestamps, store the evidence under controlled access, and confirm when Citadel becomes authoritative for new records.