A SailPoint migration is a handover of control, not a file transfer. Three things change hands: the authority to decide access, the right to write changes into target systems, and custody of the evidence auditors will request. If you lead IT and plan to move off SailPoint IdentityIQ or Identity Security Cloud, you need phases in a fixed order, a risk register with named mitigations, and a checklist that proves each phase is complete. This runbook provides all three, with Citadel Identity360 as the destination.
Citadel Identity360, from Astranova Labs, is designed to take over a SailPoint estate one phase at a time. Configuration is no-code-first, and about 400 hours of customization come included alongside installation, deployment, and hypercare. Connectors cover REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, batch, mainframe, and custom patterns. Employees, contractors, non-human identities, and AI agents sit on a single identity graph, governed with SoD controls, risk scoring, and verified deprovisioning. A typical services-led re-platform asks partners to rebuild years of custom rules before the business sees any governed outcome; Citadel moves the governed outcome to the first pilot wave.
Definitions used in this SailPoint migration guide
- SailPoint migration: Moving lifecycle, access request, certification, SoD, and evidence responsibilities from SailPoint IdentityIQ, Identity Security Cloud, or both, to Citadel Identity360.
- Control parity: Citadel produces the same or better access outcomes as the outgoing platform, proven on real targets.
- Writer of record: The single platform allowed to create, change, or remove accounts and entitlements in a given application during a given phase.
- Verified deprovisioning: A removal that stays open until the target system itself reports the account or entitlement gone.
- Coexistence: A bounded period in which Citadel governs migrated applications while SailPoint keeps the rest, each application with exactly one writer of record.
In scope / out of scope
In scope: A phase-by-phase SailPoint migration runbook to Citadel Identity360, the risks that break control parity, the Citadel mitigation for each, and a planning checklist. Every Citadel claim here is first-party. References to SailPoint are limited to its publicly documented product structure, such as IdentityIQ and Identity Security Cloud being separate products, and carry no invented metrics.
Out of scope: The object-level inventory of SailPoint roles, access profiles, campaigns, and policies, covered in migrating from SailPoint to Citadel Identity360: key planning considerations; the general control-transfer method in the safe legacy IGA migration plan; licence pricing; and ranking SailPoint products against each other.
SailPoint migration to Citadel Identity360 at a glance
| Planning area | Citadel Identity360 migration path | Typical services-led re-platform |
|---|---|---|
| Target model | Lifecycle, reviews, SoD, risk scoring, NHI, AI agents, and evidence governed in one platform | Capability often spread across suites, add-ons, and separate modules |
| Rebuilding custom logic | No-code-first configuration, backed by about 400 included customization hours | Custom rules and workflows commonly rebuilt through partner services |
| Connector reach | REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe, and custom connectors, with tracked fulfillment covering disconnected apps | Difficult targets often fall back to manual tasks or extra services work |
| Contractor lifecycle | Named sponsor, engagement end date, time-bound access, and automated expiry on the identity graph | Contractor expiry commonly rebuilt as custom rules or separate workflows |
| Coexistence | One writer of record per application, configured and visible on the identity graph | Parallel control planes that are harder to reconcile and unwind |
| SoD and risk | SoD rules evaluated on effective access, with risk scoring ranking conflicts before grant | Conflict rules re-implemented and re-tuned during the rebuild |
| Access reviews | AI-assisted review recommendations carrying risk context, with each revocation followed to verified removal | Campaign logic rebuilt; remediation proof depends on configuration depth |
| NHI and AI agents | MCP registration, ownership at registration, tool-level authorization, and a kill switch inside the same migration plan | Machine and agent governance commonly scoped as a separate workstream |
| Evidence | Decision-to-verified-state evidence chain from the first pilot wave | Evidence continuity left to export projects and reporting work |
What the Citadel target looks like during a SailPoint migration
Every migrated application lands on the same Citadel governance layer:
- HR, contractor, directory, and cloud registry events are matched to identities on the identity graph.
- Policy, roles, SoD rules, and risk scoring work out the access each employee, contractor, non-human identity, and AI agent should hold.
- No-code workflows route requests, approvals, exceptions, and certifications.
- Connectors and tracked fulfillment tasks apply changes to API, directory, database, file, batch, mainframe, and disconnected targets.
- Verification rereads the target and closes each action only on confirmed state.
- Evidence keeps the full decision-to-outcome chain, exportable for auditors.
Citadel runs as SaaS, on-premises, or hybrid on one product line, and existing IT or IAM staff can be trained to administer it. For a SailPoint migration, that means the platform you rehearse on in read-only mode is the same platform that remains when the old stack is switched off.
The seven phases of a SailPoint migration to Citadel
Each phase has an exit test. Do not start the next phase until it passes.
Phase 0: Set the boundary and freeze scope
Decide whether you are replacing IdentityIQ, Identity Security Cloud, or both, because they are separate products with different operating models. Name a program owner and an audit sign-off owner, and freeze non-essential SailPoint changes so the estate you inventory is the estate you migrate.
Exit test: a signed scope statement listing products, populations, applications, and the date each control must transfer.
Phase 1: Inventory and classify the estate
Record every source, application, connector, rule, workflow, role, SoD policy, certification, and report, then mark each one move, redesign, or retire. Long-running IdentityIQ estates tend to accumulate custom rules that no longer earn their keep, so retiring dead logic here is the cheapest work in the program. Include contractors, service accounts, API keys, workloads, and AI agents, so every identity type is counted before Citadel takes it over.
Exit test: every item has an owner and a classification, and every retire decision is approved.
Phase 2: Configure Citadel and rebuild the access model
Load authoritative sources first so identities exist on the Citadel identity graph before any application depends on them. Rebuild roles by behavior, not by name, and recreate segregation of duties rules against effective access, with Citadel’s risk scoring ranking the conflicts that matter most. Configure the contractor lifecycle with a named sponsor, an engagement end date, and automated expiry. Citadel’s no-code workflows and included customization hours absorb redesign work during configuration, not in a separate services project.
Exit test: joiner, mover, leaver, rehire, and contractor-expiry scenarios pass on test data, including a mover whose old-role-only access is removed.
Phase 3: Rehearse in read-only mode
Connect Citadel to pilot applications read-only while SailPoint remains writer of record. Compare correlation, account, and entitlement results for the same population and explain every difference. Citadel’s access-path discovery on the identity graph traces how each entitlement was granted and who approved it.
Exit test: no unexplained correlation differences, and an approved baseline of accounts and entitlements for each pilot application.
Phase 4: Pilot wave with Citadel as writer
Pick a bounded wave by risk, not application count: one modern SaaS target and one legacy or disconnected target. Transfer writer of record to Citadel for those applications only, and turn off SailPoint provisioning for them the same day. Run real joiners, movers, and leavers, force one target failure, and run one access review with a revocation. NIST SP 800-53 control AC-2 sets the bar for account management when people are terminated or transferred.
Exit test: every revocation is verified on the target, the forced failure is escalated and closed, and evidence is complete and retrievable.
Phase 5: Expand in risk-based waves and transfer governance
Move the remaining applications in waves grouped by integration pattern and risk. Move certification campaigns with their applications, and run one full review cycle on Citadel for a high-risk application before the next audit. As each owning application moves, bring its service accounts and AI agents under Citadel’s AI agent and MCP governance: each MCP server is registered, each agent gets an owner when it is registered, every tool call is authorized individually, and a kill switch can stop an agent at once. Citadel AI governance produces a configuration file that Claude, OpenAI, and Cursor MCP clients can use.
Exit test: each wave meets the same pilot exit test, and open SailPoint campaigns and violations for moved applications are closed.
Phase 6: Retire SailPoint with evidence intact
Export SailPoint campaign decisions, remediation records, SoD violations, exceptions, provisioning history, and audit reports before shutting anything down, because retention windows are finite. Store the exports read-only, then retire SailPoint in stages: provisioning, then reviews, then infrastructure.
Exit test: auditors can retrieve historical SailPoint evidence and current Citadel evidence for the same control.
SailPoint migration risks and how Citadel reduces them
| Risk | Citadel Identity360 mitigation | What goes wrong without it |
|---|---|---|
| Custom logic carried forward | No-code-first rebuild, with about 400 included customization hours for the logic that must stay | Years of rules and workflows are copied instead of retired or redesigned |
| Duplicate writes | One writer of record per application, visible on the identity graph | Two platforms change the same application at once |
| Correlation drift | Correlation on the identity graph, rehearsed read-only before any write | Accounts attach to the wrong identity or become orphans |
| Mover access left behind | Mover recalculation strips access that only the previous role justified, and SoD checks run before any new grant | New access is granted but old access is never removed |
| Toxic combinations carried over | SoD rules rebuilt on effective access, with risk scoring putting the highest-risk conflicts first | Conflicts migrate silently with the roles that create them |
| Contractor access outlives the engagement | Sponsor, end date, time-bound access, and automated expiry for every contractor | Contractor accounts stay active after the work ends |
| Ticket closed, access still live | Verified deprovisioning closes actions only on confirmed target state | Deprovisioning is marked done in the governance layer only |
| Disconnected apps fall out of scope | Connectors for JDBC, LDAP, files, SFTP, batch, mainframe, and custom targets, and owned, evidenced fulfillment tasks for the rest | Applications without APIs drop out of governance during the move |
| Certification gap | Campaigns move with their applications; AI-assisted reviews with revocations tracked to completion | A review cycle is missed during cutover |
| Evidence loss | Export plan in Phase 6, and Citadel’s evidence chain from the first pilot wave | Historical decisions disappear when the old platform is retired |
| Machine and agent blind spot | NHI lifecycle with accountable owners, MCP registration, tool-level authorization, and a kill switch | Service accounts and AI agents stay ungoverned |
Test the machine and agent row against the OWASP Non-Human Identities Top 10, with improper offboarding as the first case.
SailPoint migration planning checklist
Give every item an owner and a date.
Before Phase 0
- Confirm which SailPoint products are leaving: IdentityIQ, Identity Security Cloud, or both.
- List certification campaigns and SoD reports that must run without a gap, with dates.
Inventory and design
- Complete the object-level inventory of roles, access profiles, campaigns, and policies using key planning considerations for migrating from SailPoint to Citadel Identity360.
- Add sources, applications, connectors, rules, workflows, and reports to the same inventory.
- Classify each item as move, redesign, or retire, with owner approval.
- Give every contractor a sponsor and end date, and every service account, API key, workload, and AI agent an accountable owner.
- Map each SoD rule to effective access and agree the risk-scoring thresholds in Citadel.
- Write the authority matrix: identity source, approver, SoD evaluator, writer of record, and evidence system per application.
Rehearsal and pilot
- Run joiner, mover, leaver, rehire, and contractor-expiry tests on test data.
- Rehearse read-only and explain every correlation difference.
- Pick a pilot of one modern and one legacy or disconnected application.
- Switch writer of record and turn off SailPoint provisioning for the pilot on the same day.
Waves and retirement
- Move campaigns with their applications and run one full review cycle before the next audit.
- Register MCP servers and AI agents in Citadel as their owning applications move, and test the kill switch.
- Export historical evidence to a read-only repository before retirement.
- Retire SailPoint in stages: provisioning, then reviews, then infrastructure.
How long a SailPoint migration to Citadel takes
Duration depends on application count, connector type, identity source quality, role cleanup, and review redesign. Plan in months for a first wave, and size it with the IGA migration calculator inputs and realistic IGA implementation timelines. Citadel shortens the critical path three ways: no-code-first configuration instead of custom code, included customization hours instead of a separate services contract, and one platform for every identity type. CISA’s Zero Trust Maturity Model and NIST SP 800-207 treat identity as the foundation of mature security, so the migration should end with stronger verified controls, not just a new console.
To compare the platforms criterion by criterion, read Citadel Identity360 vs SailPoint for enterprise IGA and the Citadel vs SailPoint comparison table.
FAQ
How do we migrate from SailPoint to Citadel Identity360 without disrupting access?
Run the phases in order with one writer of record per application. Citadel takes over each application only after a read-only rehearsal and a passed exit test, and SailPoint provisioning for that application is switched off the same day.
Can SailPoint IdentityIQ rules and workflows be imported into Citadel?
Treat them as behavior to classify, not code to copy. Retire logic nobody uses and rebuild what must stay with Citadel’s no-code workflows and included customization hours.
What are the biggest SailPoint migration risks?
Duplicate writes, correlation drift, mover access left behind, toxic combinations carried over, contractor access that outlives the engagement, closed tickets with live access, disconnected applications dropping out, a missed review cycle, and lost evidence. The risk table maps each to a Citadel mitigation.
Can we run SailPoint and Citadel in parallel during migration?
Yes, as bounded coexistence. Both platforms run, but never as competing writers to the same application, and Citadel shows the writer of record for every application on the identity graph.
How do we keep audit evidence when we retire SailPoint?
Export SailPoint decisions, remediation records, violations, and provisioning history to a read-only repository before retirement. Citadel records the chain from decision to verified target state from the first pilot wave. See revocation tracking in access reviews for how removals are proven.
How should we govern non-human identities and AI agents during a SailPoint migration?
Move them with the applications that own them. Citadel gives every service account, API key, and agent an accountable owner, registers MCP servers, authorizes each agent tool by tool, and can halt any agent with a kill switch, all in the same plan as human identities.
Next step: book a Citadel Identity360 migration pilot
Book a Citadel Identity360 demonstration scoped as a migration pilot: one modern SaaS application and one legacy or disconnected application, run read-only alongside SailPoint and then with Citadel as writer of record. The pilot is scored on verified joiners, movers, leavers, and contractor expiry, one review revocation, one registered AI agent stopped by the kill switch, and complete evidence.