How We Modernized a Saudi Technology Provider's Live IdentityIQ Estate: Eighteen Applications and One Platform Migration in Eight Months

A SailPoint IdentityIQ estate upgraded to the newest release, extended from twelve applications to eighteen, moved to new servers in a single transition, and put behind a documented role model, all inside an eight-month engagement.

Agency and system names anonymized for security. Full briefing available under mutual NDA.

6 min read

Client
Technology company serving government and private-sector clients in Saudi Arabia (anonymized)
Domain
Identity and access management
Engagement
SailPoint IdentityIQ enhancement, expansion, server migration, and platform upgrade
18
Applications under access governance, up from 12
12
Live integrations enhanced in production
8 months
Assessment to production handover

The situation

The client is a technology company in Saudi Arabia whose platforms support services used by government and private-sector customers. Identity and access management sits underneath all of it, and the deployment, not the product, had become the problem. The version in place trailed the current release, which meant running without the performance and security improvements, features, and modules that ship with it. Six applications sat outside the platform entirely, so access to them was handled without identity governance. And while access levels differed by employee type across the workforce, no detailed role model existed to govern them: access was assigned without a documented structure behind it.

The remaining scope was just as concrete: the twelve applications already connected to SailPoint IdentityIQ needed enhancements to their functionality and user experience, and the platform itself needed new servers, because performance and reliability had outgrown the old ones.

Every workstream changed a platform the organization was depending on that same day.

The challenge

What made this engagement hard was not the task list; it was that every item on it touched a live platform the whole organization depended on for access, where every change landed directly in production.

  1. The existing integrations had to be enhanced in place while the people using those applications kept working.
  2. Each new application came with its own connector and configuration requirements and had to be onboarded into that same production platform.
  3. The role model had to be designed from requirements rather than refined from an existing one: access levels differed by employee type, nothing documented governed them yet, and those levels had to be maintained through the change.
  4. A full server migration and version upgrade sat on top of it all, with production expected to keep running through the transition.

The approach

ExeQut structured the engagement in three phases across eight months, so assessment, execution, and stabilization each got dedicated room.

Assess before touching anything

The first two months went to evaluating the existing identity and access management estate, identifying the key areas for improvement, and designing the integration and enhancement plan application by application. That upfront design set the scope and sequence for the four-month execution window that followed.

Execute in one concentrated phase

The four-month execution phase carried all the workstreams. The team enhanced the functionality, configuration, and user experience of the twelve existing integrations, working from the specific gaps the assessment had identified in each application, brought the six new applications into IdentityIQ, and built role-based access control procedures covering the client's employee types while preserving the access levels people already held.

The riskiest work, the migration and the upgrade, was sequenced to keep the change to production singular: the new IdentityIQ servers were built first, the newest release was deployed on them, and only then did the platform move off the old environment. ExeQut resolved issues as they arose during implementation rather than deferring them to the end.

Upgrades succeed in the assessment phase, long before anyone touches a server.

Stabilize and hand over

The final two months were the safety net for the changes: monitoring the upgraded system in production, resolving what surfaced, and transferring ownership deliberately. Documentation and training went to the team responsible for running the system, so the client's own people operate the platform, with expert consultation available as operational needs evolve, an option rather than a dependency.

The outcome

Eight months separated the initial assessment from handover in production, and the estate ended in a different state on every axis the engagement targeted:

  • The six applications that had sat outside the platform entirely, where access was handled with no identity governance at all, are now managed through IdentityIQ alongside the rest of the estate.
  • Access assignment moved from undocumented practice to documented role-based access control procedures, and the access levels people held before the change were carried through it intact.
  • The platform runs on new servers and on the newest IdentityIQ release, closing the version gap and restoring access to the features and modules the trailing version had locked away.
The move off the old environment happened once, onto new servers already running the newest release.

For an organization whose platforms serve government customers in the Kingdom, that end state maps directly to obligation. Access-control expectations there are set by national frameworks, including the National Cybersecurity Authority's Essential Cybersecurity Controls, which call for identity and access management grounded in documented, role-based authorization. The documented role model and the governance coverage across all eighteen applications are the controls that requirement describes, and the client's own team now operates both.

What we took from it

  1. Enhancement engagements need assessment discipline. Improving a live platform is riskier than greenfield work; the two months of evaluation and planning are what made a four-month execution window realistic.
  2. Run enhancement and expansion together. Enhancement, new integrations, and the RBAC build ran in the same execution phase, so access was designed once across the full application estate and workforce.
  3. Migrate and upgrade in the same motion. Deploying the newest release on the new servers before leaving the old environment kept the change to production to a single transition, with a dedicated monitoring phase behind it to catch what only production reveals.
  4. Hand over deliberately. Documentation, training, and post-delivery consultation are what turn an upgrade into a capability the client's own team carries forward.

Want the unredacted briefing?

Agency, systems, architecture, vendors, and outcomes. We walk you through the full engagement under mutual NDA.

Request a private briefing โ†’