Stabilizing and Modernizing a Legacy IAM Platform

The problem

The organization ran a large, heavily-customized on-prem Oracle Identity Manager deployment that had accumulated years of ad hoc changes: unpatched stack bundles, one-off UI customizations, and connectors that failed intermittently without clear ownership. Day-to-day operations consumed most of the team’s capacity — patching, environment coordination, incident response — leaving little room for the governance improvements the business actually needed (consistent access certifications, reliable SoD enforcement, audit-ready reporting).

Before any governance modernization could be credible, the platform itself needed to be stable and predictable.

Approach

The first phase was operational: stack bundle patching and version upgrades brought current, sandbox and lower-environment management formalized, and custom OIM UI components rationalized rather than left to accumulate further one-off changes. Recurring manual operations — data cleanup, reconciliation, certification report generation — were automated through reusable SQL scripts and scheduled jobs, reducing the day-to-day operational load.

With the platform stable, the second phase shifted to governance: defining Joiner-Mover-Leaver workflows more rigorously, building custom access certification and compliance reporting for audit readiness, and eventually authoring the enterprise Request for Bid (RFB) to evaluate next-generation IGA platforms — SailPoint IdentityIQ, Saviynt, and Oracle IDM — against the organization’s actual requirements, rather than assuming a lift-and-shift to a newer platform would solve problems that were really about process and data quality.

Key decisions

• Stabilize before modernizing. Governance improvements built on an unreliable platform don’t hold up — provisioning failures and connector issues undermine trust in the certification data itself. Operational stability came first, deliberately, even though it delayed visible governance wins.
• Automate operational toil before adding new process. Reusable SQL scripts and scheduled jobs for recurring cleanup and reporting freed up capacity that would otherwise have made governance work infeasible.
• Treat the platform evaluation as a requirements exercise, not a vendor beauty contest. The RFB was built around the organization’s actual integration landscape and data quality constraints, so platform comparison was grounded in fit rather than feature lists.

Challenges

• Single-person dependencies. Years of customization meant critical knowledge lived with a small number of people. Addressing this required deliberate knowledge transition — runbooks, training, and support model documentation — alongside the technical work.
• Change control in a regulated environment. Every stabilization change needed to go through rigorous testing and change management appropriate to a large financial institution, which slowed the pace of technical remediation compared to a less regulated environment.
• Disconnected and legacy applications. A meaningful share of the application portfolio couldn’t be integrated directly and needed manual, SLA-tracked fulfillment processes rather than full automation.

Outcome

Platform operations moved from reactive (incident-driven) to predictable, with reduced manual intervention through automation of recurring tasks. Certification and compliance reporting became reliable enough to support audit readiness rather than being assembled ad hoc each cycle. That operational foundation is what made the subsequent IGA platform evaluation and governance modernization roadmap credible — the organization was choosing a target-state platform from a position of operational control, not urgency.