Export data from SailPoint IdentityIQ before the contract ends
If your IdentityIQ renewal, licensing change or the IdentityIQ 9.0 decision forces a move, you need to leave with configuration you can actually reuse. Configuration objects such as roles, rules, workflows and applications can be exported as XML through the console export command. Identity data, audit history and logic written as code, such as custom Java classes, BeanShell or rule scripts embedded in external systems, do not come out in a form midPoint can load, so they need a planned extraction or a rebuild. Treat the export as an inventory exercise first: list every object type, every rule and every connector dependency before anyone runs a command.
Start with the XML export and check each file for references to external classes, hard-coded hostnames, service account names and environment-specific values. Roles and applications will usually carry the most business meaning, but their XML maps to IdentityIQ's own object model, so expect to redesign role structures and connector settings for midPoint's object model and ConnId connectors. Confirm the exact export syntax and output for your release against the vendor documentation and your own test instance, since export behavior varies by version. Keep the exported files, a database backup and a record of certification history under change control before any decommissioning step.
Scope this as a fixed-scope exercise and agree the deliverables in writing before work starts: the object inventory, the export procedure, the list of items to rebuild, and the acceptance tests on the midPoint side. Ask the vendor or your implementation partner what the export covers in your release, what it leaves out, and who in your organization owns each rule and workflow. DeployOpen plans and implements these migrations inside your own infrastructure, and the written scope is what sets the effort and the quote. SailPoint IdentityIQ documents the product scope, which is the right starting point for confirming what your contract entitles you to export.
What you can export from IdentityIQ as XML
This table shows which IdentityIQ configuration objects can be taken out as XML through the console export path and what each item still needs before it works in midPoint. Read it as an inventory of definitions, not a copy of identity data. Confirm every command option and size limit against the SailPoint documentation for your installed release before you plan an export.
| Data type | Export method | Format and what it contains | Practical limits to confirm |
|---|---|---|---|
| Roles (bundles and IT roles) | Console export of role objects, by object type or within a whole-configuration export | XML role definitions with membership criteria and entitlement references | Which role types export cleanly in your release, and whether assigned identities are included |
| Rules (BeanShell and Java) | Console export of rule objects | XML containing rule source code as text | Rule language version, and any Java classes or libraries that must be rebuilt outside the export |
| Workflows and lifecycle events | Console export of workflow objects | XML workflow definitions, steps and variables | Dependencies on custom rules and forms, which must be reviewed before they can be recreated in midPoint |
| Applications and connector settings | Console export of application objects | XML application definitions, schema and connector configuration | Whether passwords and secrets are exported or masked, and what must be re-entered on the target |
| Certification and policy definitions | Console export of certification or policy objects, if present in your release | XML definitions of campaign templates and policies | Whether campaign history and reviewer decisions are exportable, which is usually not a definition |
| Identities, accounts and entitlements (runtime data) | Not produced by the definition export path | Not in the XML definition output; use a separate extraction method | Confirm with SailPoint documentation which data sets can be extracted and in what format for your version |
| Forms, scheduled tasks and custom objects | Console export by object type | XML definitions that reference other objects | Cross-references must be resolved, since the export does not translate them into midPoint objects |
What does not come out as a clean XML export
The console export produces XML for configuration objects, but several kinds of data sit outside that file. Each item below needs its own extraction method, owner and check before the migration plan can be trusted.
Identity records and entitlements
The XML export carries configuration such as roles and applications, not the live population of identities and the accounts and entitlements attached to them. Extract these through reports you define in IdentityIQ, or through a direct read of the underlying database only if SailPoint's guidance for your version permits it. Check record counts, multi-valued attributes and correlation keys against the source before you accept the extract. The identity data owner and the IAM engineering lead should sign off together, because this data drives the first reconciliation in midPoint.
Certification campaign history and sign-off evidence
Campaign definitions can be exported, but the history of who reviewed which entitlement, what they decided and when is held in the product's data store. Run and export the completion and decision reports for every closed campaign, then retain them as read-only audit records with their hashes and the reviewer list. Auditors will ask for this evidence even if midPoint is ready to run new campaigns. Compliance leads should own the retention decision and the storage location.
Scheduled task state and run history
Task definitions may be exported as configuration, but last run times, schedules in flight, failure history and the state of partially completed aggregations do not travel with them. Record the schedule of every task, the most recent successful run and any open failures in a spreadsheet or ticket before cutover. Operations staff should own this inventory, and the new midPoint task schedule should be set from it rather than assumed to match.
Custom code referenced by XML
Rules, workflows and other objects often contain Beanshell scripts or call custom Java classes packaged in plugins or on the application server. The XML holds only the reference, so the code itself must be exported from the source repository or the deployed archive. Inventory every script and class that the exported objects call, then decide for each whether it becomes a midPoint expression, a ConnId connector behavior or a retired control. Developers with IdentityIQ experience should own the review, since this is where logic gets lost silently.
Encrypted and credential-bearing connector settings
Connector passwords, service account secrets and encrypted attributes are stored in encrypted form tied to the source installation's keys, so they cannot be read back and reused in a new system. Plan to re-enter every credential in midPoint, rotate the service accounts where policy requires it, and test each connection before any data is synchronized. Security engineering should own the credential inventory and rotation, and the target application owners should confirm the service accounts still have the rights midPoint needs.
Which exported objects have to be redesigned, not copied
An XML export from IdentityIQ preserves the definition of a role, rule, workflow or application, but not the behavior those definitions depend on. Every object is written in terms of IdentityIQ's object model, its rule language and its certification and provisioning semantics, so a rule that reads an identity attribute, calls a helper class or returns a value that IdentityIQ interprets in a particular way will not carry over as working logic. Treat the export as an inventory and specification, not as a import file. Before anyone plans the move, list every rule and workflow by the business decision it makes, then record which identity attributes, aggregation steps and provisioning outcomes each one relies on.
Role models and correlation logic need the most careful translation. IdentityIQ roles, bundles and their membership criteria should be mapped to the concepts midPoint uses: roles, assignments, object templates and mappings. Correlation and aggregation rules, which decide how an account from a target system is matched to an identity, have to be rewritten as midPoint correlation rules and tested against real account data, because a mismatch there creates orphaned accounts or wrong entitlements that surface only later. Confirm the exact correlation and mapping options in the midPoint release you target against the midPoint releases documentation before you commit to a design.
Approval workflows and provisioning behavior are the second category that cannot be copied. Approval chains, escalation paths and the actions taken when a request is denied or times out must be rebuilt as midPoint processes and policies, with the approvers and evidence requirements agreed with your compliance team first. Connector-level behavior, such as how an application handles creates, updates, disables and entitlement reads, is rebuilt on ConnId connectors, since midPoint talks to target systems through that framework rather than through IdentityIQ connectors. Plan a test for each provisioning action against a non-production copy of the target system, and record which exported objects were retired rather than migrated so auditors can trace every decision.
The export sequence and the checks at each step
This sequence captures everything IdentityIQ holds that a midPoint project will need, from object definitions to identity data and audit evidence, with a check at each stage so nothing is lost silently. Each output lands in version-controlled storage that the migration team can compare against later.
Inventory objects, applications and custom code
The IdentityIQ administrator lists every application, role, rule, workflow, certification definition, form, task and custom class in the environment, with its owner and last-modified date. The output is a spreadsheet or document keyed by object type and name, reviewed by the identity team and the application owners. It is complete when the count per object type matches what the console reports for each type, and any object without an owner is flagged for a decision before export.
Run the full XML export to Git
An administrator runs the console export command for the full object set, writing XML files to a staging directory that is then committed to a Git repository with restricted access. Exported files are kept as-is, without hand edits, so that later diffs show real changes. The check is that the export finishes without errors, that the file count matches the inventory, and that a second export on the same day produces identical output for unchanged objects.
Extract identity and entitlement data
Identity cubes, account data and entitlements are pulled through the reports and database access that SailPoint documents for your version, not through undocumented table queries. The output is a set of CSV or database dumps with a manifest listing source, query, date and row count. The data team confirms row counts against the identity and account totals shown in the product, and checks that sample identities carry the same entitlements in both sources.
Export certification and audit evidence
Completed certification campaigns, reviewer decisions, remediation tickets and audit logs are exported for the retention period your auditors require. Store them read-only with hashes recorded in the manifest, because this evidence will be needed even after the old system is retired. The compliance lead signs off that every campaign in the inventory has an exported result and that the decision count per campaign matches the product report.
Document connector settings and custom code
For each application, record the connector type, host, schema mapping, account and group attributes, correlation and aggregation settings, and any rule or script attached to it. Credentials are noted by location in a secrets store, never copied into the repository. Connector work is mapped to a ConnId or other midPoint equivalent in a separate document. The review is complete when each application in the inventory has a settings record and each custom rule has an assigned owner who has read it.
Compare checksums and object counts after each export
After every export run, compute checksums for each file and compare object counts with the previous run and with the inventory. Differences are investigated and documented before the next step begins, and the comparison report is stored alongside the exports. Only when two consecutive runs agree for all object types, and the evidence manifest is signed off, is the export treated as a valid baseline for the migration.
How to verify each export before you rely on it
Configuration objects are the roles, rules, workflows and applications that define how IdentityIQ behaves. Their XML is the easiest part of the export to check mechanically, because you can count objects and compare files, but a complete file does not mean the logic inside it is understood. Confirm the object inventory first, then read the content with a reviewer who knows the rules.
- Object counts: Compare the number of roles, rules, workflows and applications in each export file with the counts shown in the IdentityIQ console or UI for the same release. Record any object that is present in one and absent in the other.
- Re-export diffs: Export the same objects twice from the same release and diff the results. Differences that are not explained by timestamps point to unstable export output or to changes made between runs.
- Embedded secrets: Search the XML for passwords, keys, tokens and connection strings, especially in application definitions and rules. Remove or vault them before the files move to any shared repository.
- Logic review: Confirm that every rule and workflow has an owner who can state what it does. Logic that only appears in XML is the part most likely to be lost in translation to midPoint.
Before you rely on these files, confirm the export method and the XML structure against the SailPoint documentation for your IdentityIQ version.
Identity and entitlement data describes who holds which accounts and access, and it changes constantly. An export is a snapshot, so the verification question is whether the snapshot is complete and consistent at a stated point in time. Checks here focus on counts, relationships and the difference between what IdentityIQ aggregated and what the source systems show.
- Identity counts by status: Compare the number of identities, including active, inactive and disabled, against the figures in the IdentityIQ UI. Document the timestamp of the export and the last aggregation run it reflects.
- Account linkage: Check that a sample of identities maps to the expected accounts on each application. Orphaned accounts and identities without a correlated account need an explicit decision before migration.
- Entitlement sampling: Pick a set of identities with known access and confirm that their entitlements appear in the export with the same values shown in the UI.
- Personal data handling: Identify which fields are personal data under your privacy obligations and restrict access to the files. Confirm the retention rules for the copies made during the project.
Ask your SailPoint contact and your internal data protection owner how these checks should be recorded, and confirm the method against the documentation for your IdentityIQ release.
Certification campaigns, decisions and audit logs are the records an auditor will ask for after the move. Their value depends on whether they can be read and attributed without the original platform running. Treat this family as evidence, not as configuration, and test whether a reviewer can understand each record on its own.
- Campaign completeness: Confirm that every certification campaign in scope is exported with its definition, reviewers, decisions, comments and completion dates. Compare the count of campaigns and items with the figures shown in the IdentityIQ interface.
- Decision traceability: Pick a sample of revoked and approved entitlements and trace each one to a reviewer, a date and a recorded reason. A decision without an attributable reviewer is a gap to report.
- Readability without the source system: Open the exported evidence on a machine that has no IdentityIQ access. Confirm that a non-technical reviewer can read the campaign, the decisions and the timestamps.
- Integrity and storage: Record checksums for each evidence file and store them in a location with restricted write access, so later changes can be detected.
Confirm with your auditor which formats they will accept and whether the evidence needs an independent integrity check, and verify the export method against the SailPoint documentation for your version.
What to plan before the SailPoint contract ends
Exporting IdentityIQ objects is the easy part. The planning that decides whether the move succeeds sits around the export: what your contract still allows you to take, how long evidence must be kept, how the old system stays available during parallel running, and who will rebuild the logic. Each item below lists what to confirm before the export window opens.
Confirm export rights and support window
Read the subscription terms for what SailPoint permits you to extract, including configuration XML, identity and entitlement data, and reports, and for how long support and tenant access continue after the end date. Ask SailPoint in writing whether exports can be produced with the console tools you run today, and whether any help with the export is included or billed separately. Your legal team should confirm that exported data may be processed by a self-hosted midPoint instance under your own agreements.
Schedule full and delta exports
Plan one full export of IdentityIQ configuration and identity data well before the contract end date, so that problems with the export format surface while the vendor is still available. Plan a second, delta export after cutover to capture changes made during the transition, such as new access requests, certification decisions and role edits. Record the export date, the IdentityIQ version and the console command used so that each export can be reproduced and checked later.
Decide who keeps audit evidence
Certification decisions, approval history, provisioning logs and policy violation records are the evidence your auditors will ask for, and they may not transfer cleanly as XML configuration. Decide which records must be archived in read-only form, which system holds them, and the retention period set by your own policy and applicable regulations. Ask your internal audit team to confirm in writing which evidence they will accept from the old platform and from midPoint for the period that overlaps the switch.
Plan access for parallel running
Running IdentityIQ and midPoint side by side through at least one audit cycle requires read access to the old environment after the switch, and it requires that both systems do not write to the same target accounts. Ask SailPoint which read-only or archival access options exist for your subscription and how long they remain available. Document which system is authoritative for each application during the overlap, and who approves any change made in either one.
Budget staff for rebuilding rules
Exported workflows, rules and custom connector logic are written in IdentityIQ's own constructs and must be redesigned in midPoint, not copied. Identify which people hold IdentityIQ rule and workflow knowledge, which midPoint and ConnId skills you need from your team or an implementation partner, and how much of this work runs in parallel with your normal operations. Ask any partner for a written scope that lists the rules, workflows and connectors in your export inventory before agreeing to a timeline.
Inventory what cannot be exported
Some runtime state, such as in-flight certification campaigns, pending approvals and encrypted credentials, may not be included in a configuration export or may require vendor assistance to extract. List these items early and ask SailPoint which of them it can export, which must be closed out before the end date, and which need to be recreated manually. Confirm with your security team how stored credentials will be re-entered into midPoint without exposing them in exported files.
Questions buyers ask before exporting from IdentityIQ
How much effort does exporting from IdentityIQ take?
The effort depends on how much configuration sits in IdentityIQ and how much of it is custom. The main drivers are the number of roles, the number of rules, the number of workflows, the number of connected applications and any custom Java or BeanShell code that those objects call. A small environment with a handful of applications and standard workflows is mostly a review and packaging exercise. A large environment with years of custom rules and tuned certification logic is a design project in its own right. Ask the team to inventory these object types before agreeing any scope, because the inventory sets the size of the work.
Can our own team run the export without outside help?
Yes, many teams can run the XML export themselves, because IdentityIQ provides an export command in its console for objects such as roles, rules, workflows and applications. The harder part is deciding what the exported files mean. Your team needs someone who knows which rules encode business policy, which workflows approve access and which application settings were changed by hand. If that knowledge is spread across people who have left or who are busy with the IdentityIQ 9.0 upgrade, an outside implementation partner can help with inventory, classification and the design of the midPoint target model. DeployOpen plans and documents this work under a written, fixed scope.
Who do we need on the team for an IdentityIQ export?
Plan for three groups. IdentityIQ administrators know the console, the object model and the way roles, applications and certifications are configured. A database owner needs to understand where IdentityIQ stores its data, how backups are taken and how the export is kept consistent with a point in time. Audit and security sign-off owners must confirm which access rules, certification steps and approval paths have to be preserved, changed or retired. Application owners are also useful for confirming which connected systems are still in use. Name one accountable owner for each group before the work starts, so decisions about migrated policy do not stall.
How long does the export and analysis usually take?
The timeline is driven by the same factors as the effort: the number of objects, how much custom code they contain, how many systems are connected and how many people must review the results. Teams with a clear inventory and a small number of custom rules usually move through export and first-pass review faster than teams that must reconstruct undocumented logic. Confirm the expected duration in the written scope, including the review cycles for audit and security sign-off. A realistic plan separates the mechanical export, which is quick once tested, from the analysis and redesign, which takes most of the time.
Can the exported XML be loaded directly into midPoint?
No. The XML files from IdentityIQ describe IdentityIQ's own object model, including its rules, workflows and application schemas, and midPoint uses its own object model and connector framework. Treat the export as a source of design input: it shows which roles exist, which applications are connected, which attributes are mapped and where custom logic lives. Roles, mappings, connectors and approval flows then have to be rebuilt in midPoint, using ConnId connectors for each target system. Custom rules and workflows need to be redesigned against the business requirement they were written to meet, not translated line by line.
Which parts of IdentityIQ must be redesigned rather than copied?
Expect redesign work in the areas where IdentityIQ logic is tied to its own runtime. These typically include custom rules that call IdentityIQ APIs, workflows that depend on IdentityIQ approval and task services, certification definitions that encode reviewer rules, and connector configurations that depend on IdentityIQ's connector model. Role models usually need review as well, since role mining and role membership logic may have grown organically. Confirm each category with your IdentityIQ administrators and your audit owner, and record which items are retired, which are re-implemented in midPoint and which need a policy decision first.
What should we ask for in a quote for this export work?
Ask for a written scope that names the object types to be exported, such as roles, rules, workflows and applications, and the number of each you expect. Ask who performs each step, which deliverables you receive, such as an inventory, a classification of rules and a list of items to redesign, and what the acceptance criteria are. Confirm how custom code is handled, what testing is included, what the database and backup responsibilities are, and which audit or security reviews are part of the engagement. Ask what is one-time work and what recurring support, if any, is proposed. DeployOpen does not publish prices, so a quote follows from this written scope.
How DeployOpen scopes and delivers an exit from IdentityIQ
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, so an IdentityIQ export becomes a scoped, documented piece of work rather than an open-ended project. We agree the inventory, the target design and the acceptance tests in writing before any export or build begins.
How we scope
- We inventory the IdentityIQ objects in scope: roles, rules, workflows, applications and their XML export files.
- We agree in writing which objects are exported as reference, which are rebuilt in midPoint and which are retired.
- Engagements are fixed-scope, with deliverables and timelines confirmed before work starts, and ongoing support available as a retainer.
How we build
- We run the console export commands against a copy of your environment and keep the XML under version control.
- We map each exported rule and workflow to a midPoint design, flagging logic that must be redesigned rather than translated.
- We test the rebuilt objects against sample identities and document each result for your review.
How we hand over
- We deliver an object inventory, a mapping register and the export archive with checksums and retention notes.
- We document the redesigned role model, connector configuration and open decisions for your architects and auditors.
- We walk your team through the handover so they can read, change and rerun the export and mapping steps themselves.
How we support
- We confirm with you which evidence auditors will expect from the exported data and the retained IdentityIQ records.
- Post-handover support, upgrades and continuous testing are available as retainers, scoped in writing.
- We do not issue audit reports or certifications; independent auditors and certification bodies make those determinations.
