Migrate from Saviynt to midPoint

Privileged access management covers vaulting shared and administrative credentials, brokering sessions, recording privileged activity and approving elevation. midPoint manages identity lifecycle and role assignment, but it is not a session broker or credential vault, so teams that use Saviynt's privileged access module usually need a dedicated tool. Options to evaluate include Teleport, which brokers access to servers, Kubernetes and databases with short-lived certificates, and JumpServer, a bastion host with session recording. Secrets managers can cover application credentials that PAM tools do not vault.

• Account onboarding: Confirm whether privileged accounts are created in midPoint and pushed to the PAM tool, or created in the PAM tool and read back into midPoint for certification.
• Role mapping: Map midPoint roles to PAM access policies so that a revoked role removes privileged sessions, not only directory group membership.
• Session evidence: Decide where session recordings are stored and who can retrieve them for an audit.
• Break-glass accounts: Define how emergency accounts are inventoried, reviewed and rotated outside the normal workflow.
• Vendor scope: Check the tool's own certification and support terms against your regulatory scope.

Before cutover, test a full leaver scenario in a non-production environment and confirm that privileged access ends within the window your policy requires.

Application access governance covers entitlements inside business applications such as ERP modules, financial systems and SaaS tenants, where roles and permissions live in the application itself. midPoint reaches many of these through ConnId connectors, but connector coverage varies by application, and some entitlement models are too fine-grained or too application-specific to model as midPoint roles without significant design work. Keeping application access governance on its own tooling is a valid choice when the application estate is large or highly customized.

• Connector inventory: List every Saviynt application connector and classify each as supported, community, experimental or not available in midPoint.
• Entitlement depth: Determine whether application roles can be expressed as midPoint roles, or whether they must remain as application-side data.
• Ownership of reviews: Decide whether application owners certify in the separate tool, with results fed back to midPoint for the central record.
• Reconciliation: Schedule regular comparisons between midPoint's view and the application's actual permissions.
• Gap register: Record each application without a supported connector and the manual or custom control that covers it.

Confirm with the application vendors and your own environment which entitlement types each connector reads and writes.

Consolidation means midPoint becomes the single place where identities, roles, requests and certifications are recorded, and the other tools feed it rather than acting as separate authorities. This works where the number of target systems is manageable, entitlements map cleanly to roles, and privileged access can be governed through certification and provisioning rather than live session control. midPoint's role-based access control, auditing and role mining capabilities support this model, but the design effort sits in role engineering and connector development.

• Role engineering: Use role mining and simulations against production data to test whether proposed roles reduce the number of direct assignments.
• Certification scope: Include privileged and application accounts in midPoint campaigns so that reviewers see one consistent record.
• Connector build: Plan custom ConnId connectors for applications without a supported connector, and budget for their testing and maintenance.
• Audit trail: Confirm that midPoint's audit records meet your retention and evidence needs before retiring the Saviynt history.
• Operating model: Assign owners for each connector and role set, since the consolidated design depends on them.

Before committing, prove the design with a pilot application and confirm that midPoint can express the entitlement model without workarounds.

A single-region Saviynt tenant with a small connector set is the most direct case. The governance scope is usually bounded: a handful of directories, a few business applications and one set of certification campaigns. That makes it practical to move the whole identity governance function in one wave, provided the team inventories every connector and every scheduled job before building anything in midPoint. Most of the effort sits in mapping existing entitlements to midPoint roles and in proving that the new provisioning results match what Saviynt produced.

• Connector inventory first: list each Saviynt connector, its target system, its sync direction and its schedule, then check it against the ConnId connectors midPoint documents, such as LDAP, Active Directory, Microsoft Entra ID, SCIM2 and CSV.
• Role mapping: convert existing access rules into midPoint roles and assignments, and test them in simulation against exported production data before enabling provisioning.
• Parallel run: keep Saviynt in read-only or reporting mode for a defined period and compare entitlement outcomes for the same identities.
• Certification history: export past campaign decisions and reviewer records into an archive you control, since midPoint will not import them as live certification state.
• Cutover window: a small footprint allows a short, scripted cutover with a documented rollback path.

Confirm with Evolveum and your own environment which connectors you need are at supported status rather than community or experimental, and which midPoint release line you will standardize on before you set the plan.

Organizations that use Saviynt for privileged access as well as governance face a split decision. midPoint covers provisioning, lifecycle, role-based access control, auditing, access requests and certification-style governance, but it is not a privileged access management product. Saviynt's Identity Cloud combines identity governance, privileged access management, application access governance and non-human identity management in one platform, so the PAM functions must be named, scoped and assigned to a separate tool before the governance cutover begins. Otherwise session recording, vaulting and privileged account onboarding can fall out of coverage during the move.

• Function split: write down which Saviynt capabilities are governance (move to midPoint) and which are privileged access (stay in place or move to a dedicated PAM product, such as Teleport or JumpServer for some session and access use cases).
• Shared accounts: identify privileged and service accounts that both platforms touch, and assign one system of record for each before changing provisioning rules.
• Dependency order: keep PAM onboarding and vaulting stable while governance moves, then retire Saviynt PAM last.
• Application access governance: confirm which application-level entitlements midPoint covers through connectors and which need other tooling.
• Evidence continuity: map which audit records come from which platform, so an assessor can trace a privileged grant from request to session.

Confirm with your PAM and governance owners which accounts sit in both scopes, and get the PAM replacement decision in writing before the governance cutover date is set.

Where residency or data sovereignty rules restrict where identity data may be processed, the migration changes shape. Saviynt's platform is delivered from the vendor's cloud, so moving to midPoint means the identity repository, connectors, logs and backups now run in your own data centers or cloud accounts. That shift is the point of the move, but it also means you own the database, patching, backup, monitoring and evidence collection. midPoint runs on Linux in a virtual machine or from Docker images and uses PostgreSQL as its native repository, so sizing, network placement and key management need approval before data is extracted.

• Data flow mapping: document where identity extracts, exports and certification records travel during migration, including any staging systems and transfers.
• Hosting decision: confirm the target location of the midPoint nodes, the PostgreSQL server and the backup store against the applicable residency rules.
• Extraction controls: encrypt and restrict exports, record who ran them, and destroy staging copies once the target is verified.
• Operating model: plan the in-house effort for database administration, high availability and patch cadence, including the sticky load balancer and shared database that multi-node deployments need.
• Support boundaries: if you buy a Product Support or Platform Subscription from Evolveum, check what support staff may access in your environment and under which terms.

Confirm with your data protection and compliance owners which jurisdictions and vendor access restrictions apply, and whether any support engagement must be limited to named personnel.

Audit continuity is the constraint that shapes sequencing in every starting point, and it deserves its own plan. Auditors will ask how access decisions were made before and after the cutover, so the team must show that approvals, certifications and provisioning events have a continuous, retrievable trail. Because certification history is not carried over as live state, the sequence should preserve Saviynt's records as an archive while midPoint's auditing begins producing evidence for each change from the first day of operation.

• Archive before cutover: export certification campaigns, approvals and entitlement snapshots in a format you can search and retain for the required period.
• Evidence overlap: run both platforms for a defined window and reconcile entitlement counts for a sample of identities.
• Control mapping: map each existing control to its midPoint equivalent, such as role approval, certification campaigns or separation of duties rules, and note any gap.
• Change records: keep configuration exports for midPoint objects and version them, so each role or policy change can be traced.
• Assessor walkthrough: prepare a demonstration of one joiner, mover and leaver event on both sides before the cutover.

Confirm with your internal or external auditor which evidence formats and retention periods they accept, since DeployOpen prepares controls and evidence but auditors and certification bodies issue any assessment outcome.