Replacing a legacy IGA platform is not mainly a technology swap. It is a control transfer problem.
If you move too fast, you can interrupt provisioning, weaken access reviews, break SoD enforcement, or lose usable audit evidence. If you move too slowly, you keep paying for two platforms while creating more operational drift. The safest legacy IGA migration plan is phased, bounded, and explicit about who can read, decide, and write at each stage—and it needs a target that can absorb that phased transfer without forcing an all-at-once cutover.
Citadel Identity360, from Astranova Labs, is built for that kind of migration. No-code-first configuration, roughly 400 hours of included customization, and connectors spanning REST, SOAP, SCIM, LDAP, JDBC, flat files, SFTP, scheduled batch, mainframe, and custom paths let you move applications in waves while coexistence stays governed. The identity graph, SoD and risk scoring, contractor lifecycle, NHI and AI-agent controls, and continuous evidence trail are the same layer from the first pilot through final retirement of the legacy stack.
For a CIO or Head of IT, the goal is straightforward: keep access delivery reliable, keep governance intact, and retire the old stack only after Citadel has earned the right to own the controls.
Start with the control paths you must not break
Before you design the target, map what the current platform actually controls. The useful question is not “what applications are onboarded?” It is “what identity events still flow through this stack, and what evidence depends on it?”
Build a baseline of the in-scope people and non-human identities: employees, contractors, partners, privileged users, service accounts, machine identities, and AI agents where relevant. For each application, capture the business owner, technical owner, integration method, sensitivity, availability importance, entitlement catalog, approval path, and any manual steps. Then map joiner, mover, and leaver events all the way to the destination account and permission.
This matters because a successful connector test does not prove control parity. An application can create a test account and still fail on identity matching, role changes, disablement, entitlement removal, reviewer assignment, SoD decisions, or audit records. Citadel’s identity graph and per-application read/write/verify configuration make those gaps visible before you hand over write authority—so you baseline against real control outcomes, not logo-level connectivity.
Take the baseline seriously. Measure current event-to-effective-access time, revocation time, failed and queued provisioning, unmatched or orphaned accounts, review completion, overdue decisions, SoD violations, exceptions, manual interventions, and integration maintenance. You need a real before state if you want to prove the migration improved anything. Citadel’s feed health, fulfillment escalation, and exportable evidence give you the after state to compare against that baseline.
Define ownership before you define cutover
A safe migration depends on a clear authority model. In practice, that means one source of identity facts, one governance owner for reviews and decisions, and one provisioning writer for each destination application during any given phase.
Document the authority matrix per application:
- which identity source is trusted
- who may request and approve access
- which platform evaluates roles and SoD
- which platform may write account and entitlement changes
- which system collects evidence
- what event ends coexistence
This is also where you decide how the old platform and Citadel will coexist. Coexistence is not permission for both systems to issue competing changes to the same target. That is how you create conflicting control planes and hard-to-reconcile failures. With Citadel as the designated writer for each transferred application, coexistence stays bounded: the legacy stack continues for applications not yet in scope, while Citadel owns lifecycle, review, SoD, and evidence for every application that has already moved.
If a legacy workflow currently creates users, adds or removes entitlements, disables accounts, or handles failed API calls, make that explicit. If there are undocumented custom steps, they are migration risks—exactly the kind of estate-specific work Citadel’s included customization hours are meant to absorb during configuration, not details to clean up after cutover.
Compared with heavyweight platforms such as SailPoint, where phased hybrid migration often expands into long professional-services programs and parallel control planes that are hard to unwind, Citadel’s no-code-first model keeps authority and coexistence decisions in configuration you own. You define the writer per application once, then expand waves without rebuilding the control model.
Configure Citadel for control parity, not just feature parity
The target must be designed around the actual applications and policies you run, not around role names copied from the old system.
Map legacy roles and entitlements into Citadel with application-owner approval. Rebuild SoD rules against effective access combinations in destination applications, and use Citadel’s risk scoring to prioritize conflicts that matter most. Preserve special handling for inherited access, exceptions, contractor expirations, and privileged permissions that should be removed during a move. If you cannot remediate a conflict immediately, assign an approver, a compensating control, a review date, and a recorded exception—Citadel keeps that exception in the same evidence chain as every other decision.
This is also the time to design evidence continuity. Future decisions need their own records in Citadel, but the new platform does not automatically inherit the old platform’s complete history. Preserve legacy evidence in a protected archive that remains accessible under retention and legal-hold requirements. Citadel then becomes the system of record for every decision, approval, remediation, and reconciliation from the pilot onward, so audit readiness does not reset when the legacy stack is retired.
Citadel fits this stage because it is built as an IGA platform for lifecycle management, access reviews, identity risk, SoD, audit evidence, contractor lifecycle, and non-human identity governance—including AI agents with MCP registration, accountable ownership, tool-level authorization, and a kill switch. Citadel’s AI governance also produces a governed MCP access configuration file that agent platforms and MCP clients can consume. Its incremental onboarding approach aligns with phased migration: configure first, prove control parity, then take write ownership application by application.
Rehearse the Citadel control plane before it writes to production
Do not make the first production change the first real test.
In a lower-risk environment, exercise full joiner, mover, and leaver flows in Citadel. Include transfers that both add and remove access, resignations with pending changes, contractor expirations, rehires, duplicate identities, API failures, and manual applications. For sensitive systems, verify the final state in the application itself. A connector response is not proof of success—Citadel’s verify step after every write is what closes that gap.
Where possible, put Citadel into read-only observation mode and compare correlated identities, accounts, entitlements, expected decisions, and SoD outcomes against the old platform and destination systems. Keep a discrepancy register with clear categories: unmatched identity, incorrect owner, unexpected extra access, missing access, unsupported entitlement, delayed event, failed action, and evidence mismatch. The identity graph makes unmatched and orphaned accounts visible early, before they become cutover surprises.
Rehearse access reviews too. Confirm campaign scope, reviewer and delegate resolution, escalation timing, decisions to revoke or retain, remediation execution, and the evidence an auditor can later retrieve. Test SoD before a grant and against existing access. AI-assisted recommendations in Citadel can help reviewers prioritize, but they do not replace accountable human decisions where the control requires them.
Transfer a bounded pilot wave into Citadel
Your first production wave should be representative, not reckless.
Choose an application and identity scope that exercises the real pattern: authoritative feed, account correlation, joins and departures, approvals, reviews, entitlement reconciliation, and a named application owner. Include at least one contractor leaver and one non-human identity where they matter in your estate. Do not choose the most dangerous application first. The purpose of the pilot is to prove the Citadel method—no-code configuration, connector path, verification, and evidence—not to prove your courage.
At handoff, account for in-flight requests and unprocessed joiner, mover, and leaver events. Decide that Citadel is the only writer for the pilot scope. Enable and observe the new path, then confirm both action logs and actual application state. Keep an emergency process for time-critical revocation and access changes if something fails.
A pilot is not successful just because users can still log in. Authentication continuity does not prove governance continuity. The check is whether provisioning, revocation, reviews, SoD, and evidence all still work in the bounded scope under Citadel.
Expand in risk-based waves, not by the calendar
Once the pilot is stable, move the next set of applications into Citadel by risk and readiness, not by arbitrary deadline.
The right wave order combines exposure, criticality, compliance scope, connector maturity, and customization. Citadel’s SoD and risk scoring help separate evaluation from transfer: a very sensitive application may need early assessment and later write cutover after the pattern is proven elsewhere. Those factors do not always point in the same direction—and that is fine. The point is deliberate transfer, not a forced calendar.
Repeat the same sign-offs for every wave. Compare source identities, Citadel assignments, and destination entitlements. Inspect pending requests and departures. Verify review and SoD coverage. Track exceptions with expiry and ownership. Watch the operational cost of coexistence, including service desk load and any extra work created by running two platforms in parallel—then shrink that coexistence window as each wave stabilizes.
This is where migration risk usually becomes visible in practice. A wave that looks clean on paper can still fail if connector behavior differs by application, if manual fulfillment is undocumented, or if a key review path depends on someone’s tribal knowledge. Do not copy bad legacy policies just to make the new system look complete. Citadel’s connector breadth—REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe, and custom—means each target gets the right path, and estate-specific mappings fit inside the included customization scope rather than becoming an open-ended rebuild.
Heavyweight alternatives such as SailPoint often push hybrid estates toward long coexistence and services-heavy remapping. Citadel’s advantage for phased migration is the opposite: configuration-first onboarding, one identity graph across waves, and a clear end condition for each application’s legacy writer.
Stabilize operations before you retire the old stack
Retirement is the last verified control outcome, not the migration milestone.
Before decommissioning, confirm that each in-scope application has Citadel as the designated operational writer, that manual fulfillment has an owner, that failure alerts go somewhere actionable, and that joiner, mover, and leaver outcomes are being reconciled. Finish or transfer open review campaigns into Citadel. Check that historical reviewer decisions, SoD exceptions, approvals, policy versions, and remediation records are still retrievable—legacy archive for pre-migration history, Citadel for everything from the pilot forward.
Revoke unused old-platform service credentials and integrations through an approved decommissioning change. Keep any required archive accessible under retention requirements. Then compare the post-cutover baseline against the pre-migration baseline for access service, governance work, and evidence retrieval. Citadel’s exportable evidence pack is what makes that comparison defensible to security, compliance, operations, and audit.
If open reviews remain unresolved, if exceptions are still active without ownership, or if history cannot be retrieved, the old platform is not ready to switch off. A live Citadel deployment does not automatically mean a complete migration—control parity and evidence continuity do.
Why Citadel Identity360 is the right migration target
If you are replacing a legacy stack, Citadel Identity360 is the sensible target because its capabilities line up with the control areas that matter most in a phased move:
- Joiner, mover, and leaver automation with contractor end dates and sponsors
- Access reviews and certifications with accountable decisions
- Identity graph correlation across employees, contractors, NHI, and AI agents
- SoD management and identity risk analytics
- Audit evidence continuity from request through remediation
- Connectors for cloud, directories, enterprise applications, and protocols including REST, SOAP, SCIM, LDAP, JDBC, files, SFTP, batch, mainframe, and custom
- NHI and AI-agent governance: MCP registration, ownership, tool-level authorization, kill switch, and a governed MCP access configuration file for agent platforms
That combination makes Citadel the clear fit for enterprises that want one governance layer across hybrid environments—not a second control plane that never finishes replacing the first. Configuration is no-code-first; estate-specific work fits inside roughly 400 hours of included customization. The platform supports the migration. Disciplined waves still do the work.
What a safer Citadel migration looks like in practice
A strong legacy IGA migration plan does six things in order:
- Baselines what must stay operational and auditable
- Defines per-application authority and coexistence boundaries with Citadel as the phased writer
- Rehearses Citadel before it writes to production
- Transfers a bounded pilot wave
- Expands by risk-based waves
- Retires the legacy stack only after controls and history are accounted for
That is the safest way to preserve access delivery, governance, and audit readiness while reducing technical debt. It also gives you a clearer way to judge whether Citadel is actually improving operations, rather than simply changing where the complexity lives.
To start, pick a scoped application and control inventory. Map authority and coexistence for that scope in Citadel. Then validate the lifecycle, review, SoD, contractor, NHI, and evidence flows that matter most to your estate—and request a Citadel Identity360 demonstration against them. That gives you a migration plan you can defend to security, compliance, operations, and audit.
FAQ
Can we run both platforms during migration?
Yes, if coexistence is bounded by application and identity scope, if the authority model is documented, and if there is a clear end condition with Citadel as the sole writer for each transferred application. Two uncoordinated writers for the same destination create conflicting control planes.
Will replacing IGA interrupt SSO?
Not necessarily. Replacing IGA does not require replacing the identity provider or authentication service. But changes to accounts and entitlements can still break effective access, so test the application state under Citadel—not only successful sign-in.
What if a connector can create accounts but cannot revoke them?
Treat creation as only one test. You still need to verify disablement, entitlement removal, mover cleanup, correlation, retries, and evidence. Citadel records read, write, and verify separately, and keeps a tracked emergency revocation path—or governed fulfillment with reconciliation—until those functions work.
How long should a migration take?
There is no universal duration. Application diversity, custom integrations, test access, and organizational approvals determine the timeline. Set acceptance criteria from your own risk assessment and service commitments. Citadel’s no-code-first onboarding and included customization hours keep implementation effort bounded; wave order still follows your risk, not a vendor calendar.
Why choose Citadel over a heavyweight legacy-replacement path?
Because phased hybrid migration fails when the target cannot absorb waves without open-ended services and competing writers. Citadel Identity360 is configuration-first, connector-broad, and evidence-continuous—so each wave ends with one clear owner of lifecycle, SoD, risk, and audit for that scope.