Migrate from SailPoint Identity Security Cloud to midPoint

How a SailPoint Identity Security Cloud to midPoint migration actually runs

A move from Identity Security Cloud to midPoint is a rebuild, not a copy. Identity, account and entitlement data can be extracted from the tenant, but connectors, roles, access profiles and certification schedules have to be recreated on the midPoint side, and the feasible way to do this is a planned parallel run in which both systems answer the same questions until the new one matches. Teams usually start this scoping after a renewal, a data residency or lock-in concern, or a licensing change, and the work is normally carried out by an internal identity team with an implementation partner. midPoint is open source under EUPL-1.2 with Apache 2.0 as a secondary license and has no license fees, so the budget question shifts to infrastructure, connector work, migration and operations staff.

Effort depends on three things: the number of sources and target systems, the amount of custom logic in the tenant (sources rules, transforms, workflow steps and provisioning logic that the team wrote itself), and the audit calendar. Start by inventorying every source and target, marking which ones use a Virtual Appliance and which ones need a ConnId connector that already exists. Then list the access profiles and certification campaigns that auditors actually rely on. Ask your vendor and your own administrators to export what the tenant allows, and confirm in writing which objects are exportable and in what format before you commit to a timeline. Connector coverage for each system is the first thing to verify against the Evolveum connectors documentation.

Plan the cutover around an audit cycle, not a go-live date. Run midPoint in parallel for at least one full certification cycle so reviewers can compare decisions from both platforms, and treat any difference as a defect until someone explains it. Pick the midPoint releases page carefully when choosing a version, since the support windows differ between long-term and feature releases and affect how long you can stay on a given build. Ask any implementation partner for a fixed-scope written plan that lists sources, connectors, roles, campaigns, test evidence and the cutover checklist, so that the scope and the acceptance criteria are agreed before the first connector is built.

Which SailPoint capabilities map cleanly to midPoint and which need rework

This table compares each Identity Security Cloud capability with its midPoint equivalent and marks whether the move is clean, needs rework, or leaves a gap. Read the third column first, since it shows where the migration effort will concentrate. Items marked for confirmation depend on the current release and on your own test cases.

Identity Security Cloud capability	midPoint equivalent	Migration note
Identity and account aggregation	Resource reconciliation and import tasks through ConnId connectors	Clean for supported connectors. Confirm each source system has a supported connector and test correlation rules against your own identity data.
Provisioning and deprovisioning	Provisioning through object mappings and resource outbound rules	Needs rework. Tenant-side source configurations must be rewritten as midPoint mappings and tested per target system.
Lifecycle events (joiner, mover, leaver)	Lifecycle state and object-driven policies within identity lifecycle	Needs rework. Event triggers and timing must be redesigned from the tenant's lifecycle rules, not copied.
Access profiles and roles	Business and IT roles with inducements and assignment rules	Needs rework. Profiles usually become roles, and role hierarchies must be modeled again in midPoint.
Access requests and approvals	Self-service access requests with approval workflows	Needs rework. Confirm approval chains and escalation paths against your current request process before cutover.
Certification campaigns	Certification definitions, stages and reviewers	Confirm before committing. Map each campaign type to a midPoint certification definition and run it against your own test cases on the target release.
Password reset and self-service	Self-service password reset and password policies	Clean for standard policies. Confirm delivery channels and user enrollment flows in your environment.
Role mining and role modeling	Role mining built into midPoint	Confirm before committing. Validate mining results against your own entitlement data on the target release.
Virtual Appliance connectors	ConnId connectors, each a Java component behind a uniform interface	Needs rework. Virtual Appliance deployments are replaced by ConnId connectors you host and maintain, and custom connectors need development effort.
SSO and access management	External identity provider for OAuth2, OpenID Connect or SAML	Gap. midPoint is an identity management system and does not implement the server side of these protocols, so an external identity provider is required.

What to extract from the tenant and which integrations to rebuild

Moving off Identity Security Cloud means deciding what leaves the tenant, in what form, and which connectors midPoint must speak to on day one. The cards below separate the data you can export from the configuration you must redesign, so the migration plan starts from what is actually available.

Identity records and lifecycle data

Start with the identity population: user attributes, manager relationships, employment status and sources of record. Ask SailPoint which identity exports and API endpoints your tenant and contract enable, because that determines whether you pull full history or only current state. Map each attribute to a midPoint user property before extraction, and confirm how your HR feed will populate midPoint after cutover.

Account and correlation data

Accounts on each connected system carry the correlation keys that tie them to identities. Export the account-to-identity links with their status and last-known attributes, then verify that the same keys exist on the target side. Orphan and duplicate accounts found during extraction should be resolved before midPoint takes over provisioning, not after.

Entitlements, roles and access profiles

Entitlements and access profiles usually live as tenant objects that do not map one to one onto midPoint roles. Export them as data for analysis, then rebuild the role model deliberately, because each profile's meaning depends on how it was assigned and approved. Treat the export as evidence of what access existed, not as a template to import unchanged.

Source connectors for extraction

midPoint reads source systems through ConnId connectors such as LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1. Match each Virtual Appliance source to one of these, then check the catalog status. Connectors without a supported status need a build or validation step, which should be scheduled and tested before the cutover window.

Target connectors for provisioning

Each target system that SailPoint provisions to needs an equivalent midPoint connector that can create, update, disable and delete accounts with the same entitlement semantics. Test every target against a non-production copy, including the error paths for failed provisioning. Where no supported connector exists, budget for a ConnId connector build and its maintenance.

Business rules, transforms and governance settings

Custom rules, attribute transforms, lifecycle triggers and certification schedules in the tenant encode decisions your organization made. Redesign them as midPoint mappings, policies, and certification definitions instead of copying their logic, and record why each rule exists. Review these with the control owners so that the new configuration still meets the approval and audit requirements you rely on today.

Migration sequence from inventory to decommission

This sequence moves identity governance from the SailPoint Identity Security Cloud tenant to self-hosted midPoint in controlled stages, with each stage producing evidence that an auditor can follow. The order keeps the live tenant authoritative until the new platform has reconciled against it.

Inventory sources, targets and governance obligations
Build a register of every source and target system connected to the tenant, with its connector type, owner, account counts and entitlement model. Record the access profiles, roles, certification campaigns, provisioning rules, custom logic and the audit obligations each one supports, such as which controls and review cycles must continue without a gap. Confirm with your compliance lead and the tenant administrators which items are authoritative. The output is an inventory register signed off by the application owners and the compliance lead, with each item marked as copy, redesign or retire.
Pilot one or two systems through ConnId
Choose one or two low-risk target systems with clear ownership and rebuild their connections in a non-production midPoint instance using ConnId connectors. Where a built-in connector exists, such as LDAP, Active Directory, CSV, DatabaseTable, Microsoft Entra ID or SCIM2, use it first. Where no connector exists or the Virtual Appliance behavior is custom, budget engineering time for a connector build and test it against a test copy of the target. The output is a pilot test report covering account create, update, disable and entitlement changes, plus a list of connector gaps that need a decision.
Run both systems in parallel
Keep the SailPoint tenant as the system of record while midPoint runs in parallel against the same sources, or in read-only mode where writing to targets is not safe. Schedule reconciliation between the two platforms for identities, accounts and entitlements, and investigate every difference until its cause is known. Run certification campaigns on both sides for at least one full audit cycle so reviewers and auditors can compare results. The output is a reconciliation report with difference logs, root causes and sign-off on each open item.
Cut over with a signed plan
Freeze changes to roles, access profiles, connectors and certification schedules in the tenant for the cutover window. Perform a final extract of identities, accounts, entitlements and campaign history, then reconcile it once more against the sources before switching provisioning and certification ownership to midPoint. Confirm rollback steps and who can invoke them. The output is a cutover plan signed by the identity owner, the application owners and the compliance lead, together with a post-cutover check result confirming that provisioning and certifications run on midPoint.
Decommission and retain evidence
Before the tenant access is closed, export and store the evidence set: the final extract, configuration exports, campaign records, approval histories, audit logs and the reconciliation reports from the parallel run. Store them in the organization's own retention system with access controls that match the audit requirements. Confirm with your auditor and legal team which records must be kept and for how long, because retention periods depend on your obligations and are not set by this guide. The output is a retained evidence set with an index, and a decommission record that states when the tenant was closed and who approved it.

How to run SailPoint and midPoint in parallel without splitting authority

During a parallel run, each source system must have exactly one system of record at any given time. If SailPoint and midPoint both provision or deprovision accounts for the same source, you will get conflicting entitlements, duplicate tickets and access that nobody can explain. Assign ownership per source, per application and per population, and write it down as a signed cutover register. Move a source across that line in one step, record the date and the change owner, and reconcile it immediately afterward. Until that register is agreed, do not point any midPoint connector at a production target with write permissions enabled.

Reconciliation reports, not manual spot checks, are what prove parity. For each migrated source, compare the account and entitlement set held by SailPoint against the set midPoint computes from the same authoritative feed, and keep the diff output with the run date. Run this comparison on a fixed schedule and retain the results, because an auditor will ask how you know the two platforms agree. Certification campaigns usually stay on SailPoint until the first cycle on midPoint has been reviewed, while campaign definitions are rehearsed in midPoint against a copy of the data. Confirm with your audit team whether they accept a split, for example, one review cycle on each platform, before you commit to it.

Choose the midPoint release before you build the rehearsal environment, because the release sets the Java version. Evolveum lists midPoint 4.8 (Curie) as a long-term support release supported until 17 October 2028, and midPoint 4.10 (Braille) as a feature release supported until 26 November 2027. midPoint recommends Java 21 for 4.10 and older and Java 25 for 4.11 and later, so a 4.8 deployment and a 4.11 deployment need different runtime builds. Check the midPoint releases documentation for the current support status before you pin a version, and keep the freeze window for joiner, mover and leaver changes short and written down, with the SailPoint and midPoint configuration exports, reconciliation outputs and approval records retained in both systems for the auditor.

What drives migration cost and duration, and how to keep each down

This table lists the factors that change the effort of moving from Identity Security Cloud to midPoint, why each one matters, and how to contain it. Read it before requesting quotes, because each row maps to a line item a written scope should state explicitly. One-time work (design, connector build, migration and testing) and recurring work (operations, upgrades and support) follow different drivers, so the table separates them in its rows.

Driver	Why it matters	How to contain it
Number and type of connected systems	Each source and target needs a ConnId connector or a custom build. Directory and database sources such as LDAP, Active Directory and Microsoft Entra ID have documented connectors, while less common SaaS targets may need community or experimental connectors or new code.	Inventory every source and target from the tenant, classify each as supported, community or custom, and retire unused applications before the build starts.
Custom rules and workflows in the tenant	Logic written for Identity Security Cloud, such as transforms, lifecycle triggers and approval flows, does not carry over automatically. Each item must be redesigned as midPoint expressions, object templates, policies or workflows.	Export the rule and workflow inventory early, then remove duplicates and obsolete logic so only current behavior is rebuilt.
Role model complexity and role mining need	A large set of overlapping roles or entitlements increases design and testing effort. Role mining can reduce manual analysis, but it adds a discovery phase with its own review effort.	Decide whether to rebuild roles by hand from access profiles or use midPoint role mining on production-like data, and agree the cleanup target in writing.
Certification scope and reviewer model	Campaigns that cover many applications, multi-stage approvals or delegated reviewers need more definitions, reviewer rules and testing. Gaps here often surface only during the first audit cycle.	Start with the campaigns that matter for audit, map each to a midPoint certification definition, and test reviewer assignment with real owners.
Audit calendar and cutover window	Certification and provisioning obligations run on fixed dates. A cutover that lands during a campaign or a close period raises the cost of parallel running and rework.	Plan the migration around the existing campaign calendar, and agree in writing how long both platforms run in parallel.
Data quality of source directories	Duplicate accounts, missing owners, stale identities and inconsistent attributes must be resolved before correlation and reconciliation. Poor data typically extends testing and manual cleanup.	Profile the authoritative source before design, set cleanup rules with the data owners, and budget the cleanup as a separate scope item.
Hosting and infrastructure	midPoint runs on Linux in a virtual machine or from Docker images, uses PostgreSQL as its native repository database (ideally on a separate server), and multi-node setups need a sticky HTTP load balancer and a shared database. Each choice adds build and operations effort.	Confirm the target topology with your platform team, use the documented system requirements, and ask the implementer to state which components are included in the quote.
Evolveum support subscription	A Product Support or Platform Subscription is an optional recurring cost. Product Support covers resolving product bugs with an 8x5 next-business-day or 24x7 SLA, and Platform Subscriptions add feature development and roadmap influence. Evolveum's page lists no prices.	Decide the support level before go-live, request the current subscription price from Evolveum in writing, and compare it with internal on-call capacity.
Upgrades and release cadence	Recurring upgrade work depends on the release line you choose. midPoint 4.8 (Curie) is a long-term support release supported until October 17, 2028, while feature releases such as 4.10 (Braille) have shorter support windows, so the chosen line sets how often upgrades happen (midPoint releases page).	Prefer the long-term support line where possible, budget upgrade testing as recurring work, and confirm the support end dates in the release documentation before signing.

What usually goes wrong in this migration and how to prevent it

Most failed moves off Identity Security Cloud share a pattern: evidence and context stay behind in the tenant, and the new platform inherits data without its meaning. The six risks below each have a specific prevention step, and they should be checked before the first production cutover.

Certification history left in the tenant

Campaign results, reviewer decisions and remediation timestamps live in the SaaS tenant, and an export of current access does not carry them. Auditors often ask for proof that past reviews happened and who signed off. Before decommissioning, export certification campaign records and reports to read-only archive storage, and confirm with your auditor which periods must remain retrievable. Keep the SailPoint tenant under a contract or export plan until that evidence is accepted.

Orphaned and duplicate accounts

Extraction often pulls the same person in twice, once from the directory and once from a connected application, or leaves accounts whose owner no longer exists. Loaded into midPoint without reconciliation, these become unowned accounts that receive roles they should not hold. Match accounts to identities on a stable key such as employee ID, run a report of unlinked and multiply linked accounts, and resolve each category before any provisioning is enabled.

Entitlements stripped of business meaning

An entitlement export gives group names and role IDs, but not the owner, purpose or approval rule that made them meaningful in Identity Security Cloud. Recreating access from raw lists tends to copy excess privilege into the new model. For each entitlement, record the business owner and the request or approval path it came from, then design midPoint roles and access profiles around those meanings rather than around the raw list.

Connector coverage gaps

Some target systems that a SaaS source connects to through a Virtual Appliance may have no matching ConnId connector, or only a community or experimental one. Discovering this during cutover stalls provisioning for that system. Build an inventory of every source and target, mark each as a documented connector, a catalog connector at a lower support status, or a custom build, and assign an owner and test date to each gap before go-live.

SSO and login dependencies assumed to move

Applications that rely on Identity Security Cloud for sign-in, or on SSO federation through it, do not automatically gain a login path through midPoint. midPoint manages identities and provisioning, and it does not act as an access management or SSO server. Map every application that authenticates through the current tenant, confirm which identity provider will issue its tokens after the move, and plan those federation changes as a separate work item.

Cutover without a tested rollback

Switching provisioning and certifications to midPoint in one step leaves no way back if joiner, mover or leaver events fail on the first night. Run both systems in parallel for a defined period, compare the access state they produce, and rehearse a rollback that restores the previous provisioning source. Write down who decides to roll back, what triggers it, and which steps are needed to return to the prior state.

How the migration changes by starting point and organization size

An organization with one authoritative directory and a handful of connected targets usually has the smallest migration. The main work is extracting identities, accounts and entitlements from the Identity Security Cloud tenant, mapping them onto a small set of midPoint resources and rebuilding a limited role model. Connector work is short because only a few target systems need ConnId connectors, and the certification schedule is often a single recurring campaign.

Data extraction: Exports from the tenant are usually small enough to review by hand, so reconciliation against the directory is a manageable check.
Connectors: Expect a few ConnId connectors, such as LDAP, Active Directory, CSV or Microsoft Entra ID, to cover most targets.
Role model: Access profiles often collapse into a short list of roles that can be rebuilt directly in midPoint.
Certifications: One or two campaign definitions may be enough to replace the existing schedule.
Operations: A single-node deployment on Linux or Docker, with PostgreSQL, is often sufficient, although this depends on your availability targets.

Illustrative example: a company with one Active Directory forest and three SaaS applications would rebuild roughly three connectors and one role catalog. Confirm the full list of connected sources and their owners before assuming the migration is this small.

Questions buyers ask before moving off SailPoint Identity Security Cloud

How much does a migration from SailPoint Identity Security Cloud to midPoint cost?

The cost is set by the written scope, not by a price list, and DeployOpen does not publish one. The main components are: the migration work itself (extracting identities, accounts and entitlements, rebuilding connectors, roles and certification schedules), the target infrastructure in your own cloud or data center, testing and cutover, and ongoing operations. midPoint has no license fee, so the comparison turns on services and staff time. Costs rise with the number of connected systems that lack a ConnId connector, the number of roles to redesign, and how many certification campaigns must run in parallel. Ask for a quote that separates one-time work from recurring items such as hosting, support and upgrades, and that lists each connector and each role set as its own line.

How long does it take to move off Identity Security Cloud?

The timeline depends mainly on the number of sources and targets, how many roles and access profiles must be redesigned rather than copied, and how much audit evidence must be preserved across the cutover. Connector availability matters: midPoint documents connectors for LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID, SCIM2 and SCIMv1, and other systems may need a community or custom connector. Plan for a period where both platforms run, so certification cycles finish on one side while the other is validated. Ask any provider to state the phases, the entry and exit criteria for each, and the dependencies on your own change windows in a fixed-scope document before work starts.

What does our team have to provide during the migration?

Your team needs to supply knowledge and access that only your organization holds. This includes named owners for each connected application, service accounts with the rights needed to read and write accounts, an inventory of current access profiles and roles with their business meaning, and the approval and certification rules your auditors expect. Someone must also decide which roles survive the move, since many tenants carry legacy profiles that should not be recreated. Security and networking staff are needed to place midPoint, its PostgreSQL database and the connector hosts inside your network. Confirm these responsibilities, along with reviewer availability for test certifications, in the written scope.

Can our own staff migrate to midPoint without outside help?

Yes, some teams do this in-house, but it requires sustained skills in Java-based configuration, the ConnId connector model, PostgreSQL operations, and identity governance design. midPoint is written in Java, recommends Java 21 for 4.10 and older and Java 25 for 4.11 and later, and can run on Linux virtual machines or Docker images. Evolveum offers support subscriptions and training, and professional services are available from partners. The honest test is whether your team already operates a similar IGA platform and can staff the work while keeping day-to-day operations running. If not, ask an implementation partner to state in writing which tasks it performs and which remain with your staff.

Does midPoint have a license fee, and what does an Evolveum support subscription add?

midPoint carries no license fee. It is dual-licensed under the EUPL-1.2 and Apache 2.0, and Evolveum states that it has no enterprise edition, so every line of code is open source. Evolveum funds development through subscriptions, training and professional services. Its Product Support subscriptions cover resolving product bugs with an 8x5 next-business-day SLA or a 24x7 SLA, and its Platform Subscriptions add feature development and roadmap influence. The subscription page lists no prices, so request a quote. Budget the support tier as an optional recurring cost, and confirm which midPoint release line your tier covers, such as 4.8 (Curie) with support until 17 October 2028.

Must we replace our SSO provider at the same time as the IGA platform?

No, the two can be separated, but you must plan the boundary explicitly. midPoint is an identity management system, not an access management or SSO server, and it does not implement the server side of OAuth2, OpenID Connect or SAML. Its own user interface can authenticate against external SSO services, so your existing identity provider can stay in place. Confirm how applications that today rely on Identity Security Cloud for sign-on will keep authenticating, and whether any SaaS app's login flow depends on SailPoint-managed components. Record that decision in the scope so the SSO work is either excluded or priced separately.

What should we confirm about SailPoint export paths before signing a contract?

Confirm in writing what SailPoint can export from your tenant and in what format, because not every object translates directly into midPoint. Ask for the export of identities, accounts, entitlements, access profiles, roles, sources, and certification history, along with the data types and any limits on bulk retrieval. Establish whether the tenant's configuration (such as workflows, custom rules and provisioning logic) can be extracted as files or must be documented and rebuilt. Also confirm that your contract allows data retrieval at exit and states the retention period for certification evidence. Treat the answers as inputs to the scope, and do not sign until the export inventory has been reviewed by the team that owns the audit evidence.

How DeployOpen scopes, runs and supports a midPoint migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from Identity Security Cloud to midPoint, that means agreeing a written scope first, then building and testing in your environment, then handing over documented runbooks and evidence.

How we scope

Inventory every Identity Security Cloud source, application, account type and entitlement that must move, and record which ones stay in scope.
Agree in writing which Virtual Appliance connectors map to ConnId connectors and which ones need custom work.
Confirm the target hosting model, database, Java version and load balancing before any build starts.
Define which access profiles, roles and certification schedules are rebuilt, and which are retired.

How we build

Extract identity, account and entitlement data from the tenant and load it into a midPoint test environment.
Build or adapt ConnId connectors for each target system and test provisioning and deprovisioning against non-production copies.
Rebuild access profiles, roles and certification definitions in midPoint, then compare results against the existing tenant.
Run reconciliation reports between the two systems so the team can confirm that access decisions match before cutover.

How we hand over

Deliver configuration, connector code and deployment documentation stored in your own repositories and systems.
Provide runbooks for cutover, rollback, certification campaign operation and routine connector maintenance.
Walk your administrators and reviewers through the rebuilt roles, approvals and certification workflow before go-live.
Document test results and the control evidence your internal and external auditors will ask to see.

How we support

Support after go-live is available as a retainer covering fixes, midPoint upgrades and connector maintenance.
Plan upgrades around midPoint release support dates, so your team knows when each version reaches end of support.
Continue regression testing of connectors and access rules as target applications change over time.
Confirm with your Evolveum support or platform subscription choices which vendor channel covers product defects.