Migrate from Omada to midPoint: what the move involves
Moving from Omada Identity Cloud to midPoint is a re-implementation of connectors, authoritative sources and approval processes, not a data copy. Omada's configuration, role model and assignments cannot be lifted into midPoint as they stand, so the work is to rebuild the identity model, the ConnId connectors to each target system and the request and review workflows on the midPoint side, then prove they behave the same way. Most teams do this with their internal platform and IAM staff, supported by an implementation partner for the parts that are new to them, such as the first connector builds or the HR source integration. midPoint is licensed at no fee under EUPL-1.2 with Apache 2.0 as a secondary license, and Evolveum offers optional support subscriptions, so the main cost of the move is the people and time to do it, not software licensing.
Effort and risk concentrate in three places: the inventory of what Omada does today, the data work that establishes correct identities and assignments in midPoint, and the cutover of provisioning to target systems. Start with a written inventory of authoritative sources, target systems, roles, approval chains, access reviews and scheduled jobs, and mark which items are used and which are legacy. Then decide how identities are matched across the HR source and existing accounts, and which attributes midPoint will treat as authoritative. Confirm early which of your target systems have a supported ConnId connector and which would need a custom one, because that single finding often drives the schedule more than anything else.
Plan a parallel run before any provisioning moves. Run midPoint in simulation or read-only comparison against production data, reconcile its computed assignments with Omada's for a representative population, and resolve every difference explicitly. Cut over one target system at a time, keep a rollback path open for each, and agree with compliance reviewers in advance which evidence from Omada must be retained and where it will live. Ask any implementation partner to define these exit criteria in the written scope before work begins.
Which Omada capabilities map to midPoint, and where the work is
This table maps the main Omada Identity Cloud capabilities to their midPoint equivalents and marks each as clean, needs rework or gap. Read the status as a starting point for scoping, not a parity claim. Verify each Omada feature against your own configuration and confirm access review and risk features against midPoint's current release documentation before committing to a migration plan.
| Omada capability | midPoint equivalent | Status and what to check |
|---|---|---|
| Joiner, mover, leaver lifecycle | Identity lifecycle with provisioning and deprovisioning driven by source data | Needs rework: rebuild lifecycle rules from your Omada workflows and confirm HR source mapping for each event |
| Role-based access control | RBAC with roles, assignments and policy rules | Needs rework: map Omada roles and entitlements into midPoint roles, then reconcile assignments before cutover |
| Access requests and approvals | Self-service access requests with approval flows | Needs rework: re-create approval chains and confirm how request forms and approvers translate |
| Access certifications and reviews | Governance review features; confirm current scope against midPoint release documentation | Gap until confirmed: do not promise parity with Omada review campaigns or risk scoring without verifying the current release |
| Connectors to target systems | ConnId connectors, including LDAP, Active Directory, Microsoft Entra ID, SCIM2 and CSV | Needs rework: check each target system against the connector catalog, and build or test any missing connector |
| Auditing and reporting | Auditing of changes and provisioning activity | Clean for core audit trails; confirm the report formats your assessors and compliance team require |
| Password self-service | Self-service password reset | Needs rework: confirm the reset flows, notification channels and policies match your current Omada setup |
| Simulation and role analysis | Simulations against production data and role mining | Clean in concept: use these to validate role design before cutover, but confirm the workflow matches your team's practice |
Which identities, roles and integrations to export and rebuild
A migration from Omada to midPoint splits into a few workstreams that run side by side: source data, role design, the authoritative HR feed, target connectors and workflows. Each one has its own owner and its own checks, and each one feeds the parallel run that proves the new system before cutover.
Identity and assignment export
Pull identities, accounts and their current role or entitlement assignments out of Omada through the export or API paths Omada documents for its tenant. Confirm the exact paths, formats and rate limits with Omada, since the export scope determines what midPoint must load. Reconcile counts per source system, flag orphaned accounts and duplicate identities, and keep a dated snapshot as the baseline for every later comparison.
Roles and entitlement rebuild
Translate Omada roles, business roles and entitlement definitions into midPoint roles, assignments and policy rules. Expect the mapping to be a design exercise, not a copy: role names, ownership and inheritance rarely carry over unchanged. Use midPoint's role mining and simulations against exported data to test whether the rebuilt model reproduces the current access before anyone relies on it.
HR authoritative source reconnection
Reconnect the HR system of record as the source for joiners, movers and leavers, and confirm how Omada currently receives and interprets those feeds. Map attributes, effective dates and organizational units explicitly in midPoint, and decide how conflicting or late HR changes are handled. Lifecycle errors here produce the access problems auditors see most often, so test this path with real change scenarios.
Target connectors on ConnId
Rebuild each target connection on the ConnId framework. Documented connectors include LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through the Graph API, SCIM2 and SCIMv1. Connectors for less common targets may be community or experimental, so confirm their status in the connector catalog and test them against a non-production instance before any production provisioning depends on them.
Access request and review workflows
Inventory the approval chains, certification campaigns and review schedules configured in Omada, including who approves what and which escalations apply. Port each one to midPoint's self-service requests and approval processes, and document what changes in reviewer experience. Gaps in review reporting or certification features should be found during this inventory, not after cutover.
Migration sequence from inventory to decommission
This sequence moves identity governance from Omada to midPoint in controlled stages, so each target system is switched over only after its access data has been reconciled and its evidence is retained. Each step produces a named artifact that the next step depends on.
Inventory Omada configuration, sources and targets
Document everything Omada does today: authoritative HR and other identity sources, the target systems it provisions to, the connectors and their versions, the role model, approval and review workflows, scheduled jobs, and the notifications and reports that auditors or managers rely on. Your team should export what the product allows and record the rest from the administration console and from interviews with system owners. This step is done when you have a written inventory that maps every source, target and business process to an owner, and when the gaps (anything Omada does implicitly or through custom code) are listed with a decision for each. Ask Omada and your integrator to confirm which configuration exports are supported in your deployment, since export formats differ by version and by the private or SaaS variant.
Pilot one target system and one population
Choose one low-risk target system, such as a directory or a single business application, and one bounded population, such as a single department or a set of contractors. Build the midPoint connector for that target through the ConnId framework, load the identities, roles and assignments for that population from the inventory, and run provisioning in a test copy of the target. The pilot is complete when the connector can read and change accounts in the test target, the role assignments produce the same entitlements that Omada produced, and the owners of the pilot population have reviewed the result. Record every mismatch and its root cause, because those findings set the scope of the later stages.
Build the midPoint environment on PostgreSQL
Install midPoint on Linux in a virtual machine or from Docker images, using the Java version that matches your chosen release: Java 25 for 4.11 and later (Java 21 supported) and Java 21 for 4.10 and older (Java 17 supported). Use PostgreSQL as the native repository database, ideally on a separate database server, and for more than one node plan the sticky HTTP load balancer, shared database, inter-node cache invalidation over HTTPS and Quartz scheduling described in the system requirements. Confirm the release you pick against the support dates in the release documentation, because 4.9 support ends on 18 October 2026, 4.10 on 26 November 2027 and 4.8 on 17 October 2028. This step is done when a non-production environment runs the pilot configuration, backups of the database restore successfully, and your operations team has a runbook for it.
Run parallel simulations and reconciliation reports
Keep Omada authoritative while midPoint runs in parallel against production data. Use midPoint simulations to show what changes it would make to accounts, roles and assignments if it were in control, and compare those results with the Omada state through reconciliation reports for each population. Review every difference with the system owner and classify it as a midPoint defect, an Omada rule that was never documented, or a legitimate policy change that needs approval. The step is complete when the differences for each in-scope population are either resolved or accepted in writing, and when the access request and review workflows have been tested with the same approvers who use Omada today.
Cut over provisioning one target system at a time
Switch provisioning for one target system at a time, starting with the system that passed the pilot and reconciliation. For each target, stop Omada's provisioning for that system, let midPoint take ownership of the accounts and entitlements, run a reconciliation to confirm that the target matches the expected state, and keep a documented rollback path to Omada until the owners sign off. Repeat the sequence for the next target only after the previous one has run cleanly through its normal joiner, mover and leaver cycle. The output for each target is a signed cutover record listing the date, the reconciliation result and the rollback decision.
Decommission Omada after retaining audit evidence
Once every target is running under midPoint and the review cycles that were in progress in Omada are closed, export and archive the audit evidence you must keep: historic access reviews, approval records, provisioning logs, role definitions and attestation results. Confirm the retention period with your compliance and legal teams, since it depends on your regulatory obligations and is not set by this migration. Then disable Omada's connectors, revoke its service accounts in the target systems, and remove its scheduled jobs before you terminate the subscription or the Azure resources, following the terms in your Omada agreement. The step is complete when the archive has been checked for readability by someone other than the people who produced it, and when your auditors have confirmed in writing that the evidence they need is available.
What drives cost and duration in an Omada to midPoint move
This table lists the factors that change the cost and effort of moving from Omada Identity Cloud to midPoint, and how to keep each one under control. midPoint has no license fee, so most of the budget sits in infrastructure, people, implementation work and an optional Evolveum subscription. Use the drivers to shape a written scope before asking for a quote.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Number of target systems and connector types | Each target needs a ConnId connector or a custom build, plus mapping, testing and reconciliation. Less common targets take longer than directory or database targets. | Inventory every target first, rank by business value, and confirm which connectors are supported, community or experimental in the midPoint integration catalog. |
| Number of HR sources and data quality | Each authoritative source needs its own mapping, joiner, mover and leaver logic. Inconsistent employee IDs or duplicate records create cleanup work before any migration. | Choose one authoritative HR source where possible and clean identifiers before export. Ask the implementation partner to scope data remediation separately. |
| Volume of roles and exceptions | Omada roles, business roles and per-user exceptions must be translated into midPoint roles, assignments and policy rules. Undocumented exceptions multiply testing. | Export assignments, identify roles that duplicate each other, and retire unused roles before rebuilding. Agree a rule for handling exceptions. |
| Number of access request and review processes | Each request flow, approval chain and certification campaign needs to be rebuilt and tested with its approvers. Review logic is often the largest share of workflow effort. | Group processes by type, prioritize the ones that carry audit obligations, and retire low-use flows instead of porting them. |
| Custom Omada workflows and integrations | Custom scripts, bespoke forms and external calls have no direct equivalent and must be redesigned in midPoint's model, then verified by the team that owns them. | Document each custom workflow with its purpose and owner. Remove those no longer needed and estimate the rest in the written scope. |
| Compliance evidence needs | Assessors may ask for evidence from both systems during parallel running, including review records, change history and provisioning logs. Preparing that evidence takes planning and time. | Define the evidence list before cutover. Ask your auditor which artifacts they expect. DeployOpen prepares controls and evidence but does not issue audit reports. |
| Team skills in midPoint | A team familiar with midPoint, Java, PostgreSQL and ConnId works faster and needs less outside help. Skill gaps add ramp-up time and raise the value of vendor support. | Ask for knowledge transfer and documentation in the scope. Decide early whether to buy an Evolveum support subscription, which adds bug-fix SLAs, or to rely on your own staff. |
| Infrastructure and operations (recurring) | midPoint runs on your own Linux servers or Docker, with PostgreSQL and multi-node components. Hosting, backup, patching and monitoring are recurring costs that Omada's SaaS model otherwise handles. | Confirm sizing against the system requirements, reuse existing platform tooling, and cost the operations team's time alongside the hardware. |
| Parallel running and cutover (one-time) | Running Omada and midPoint side by side means paying for two systems and reconciling their outputs during the overlap period. Length depends on how many systems you cut over and how many reviews run in parallel. | Cut over in waves by target system or business unit. Agree in writing the reconciliation method and the criteria for ending parallel running. |
What usually goes wrong when replacing Omada with midPoint
Most failed identity migrations fail in the same few places: roles copied without review, account edge cases the connectors handle differently, cutovers without reconciliation, weak HR data, and lost audit evidence. Each card below names one risk and the check that prevents it.
Copying roles without review
Exporting Omada roles and assignments one for one into midPoint often reproduces years of overlapping, unused or ambiguous roles, which is role explosion in a new system. Before import, run midPoint's role mining and simulations against exported assignment data to find roles with near-identical membership. Agree a naming and ownership model for roles with business owners, and retire roles that no longer match a job function before any provisioning is switched on.
Unverified connector behavior for edge accounts
Orphan accounts, disabled accounts and accounts created outside governance can be handled differently by a ConnId connector than by Omada's connectors. Test each connector against a copy of the target system with orphaned, disabled and locked accounts, and document what midPoint does with each state. Confirm the exact behavior of the Microsoft Entra ID and Active Directory connectors in your version, since connector status varies across the integration catalog.
Cutover without reconciliation
Switching provisioning to midPoint without first reconciling its view against each target system can create mass changes, duplicate accounts or silent removals on the first run. Run midPoint in read-only or simulation mode against production data, compare results with Omada's current state, and resolve every mismatch with an owner before enabling write operations. Keep a rollback path for each target system during the parallel run.
Underestimating HR data quality
midPoint derives lifecycle events such as joiners, movers and leavers from the authoritative HR source, so inconsistent employee IDs, missing manager fields or late status changes flow straight into access decisions. Profile the HR feed before design begins, measure duplicate and incomplete records, and agree with HR which system is authoritative for each attribute. Treat HR fixes as a prerequisite workstream, because midPoint cannot correct data that the source does not hold.
Losing certification history and evidence
Omada's access review records, approvals and campaign results are often the evidence an auditor asks for, and they do not move automatically with the roles. Export review history and approval records from Omada before decommissioning, store them in a read-only archive that you control, and map each retained artifact to the control it supports. Confirm with your compliance team and auditor which evidence period they need, because DeployOpen prepares evidence but does not issue audit opinions.
Assuming midPoint provides SSO
midPoint is an identity management system and does not implement the server side of OAuth2, OpenID Connect or SAML, so applications that relied on identity features in the governance layer still need an access management or SSO service. Inventory which applications authenticate through your current stack, decide which product issues tokens for them, and test sign-in paths separately from provisioning. midPoint's own user interface can authenticate against an external SSO service, which should be validated in your environment.
How the move differs by starting point
When Omada Identity Cloud runs as the vendor-hosted SaaS on Azure, there is no database or server you control to copy from. Your export depends on what Omada exposes through its interfaces and what your contract allows, so that conversation comes first. midPoint must then reach your target systems and HR source from your own network, which makes network paths and hosting decisions part of the plan from day one.
- Export is an extraction project: Ask Omada which exports of identities, roles, entitlements, assignments and request history are available, and in which formats. Confirm this in writing because the data sits in the vendor's tenant.
- Connectors are rebuilt: Omada's connectors do not carry over to midPoint. Inventory each target and map it to a ConnId connector, or plan custom development where none exists.
- Hosting is your decision: midPoint runs on a Linux VM or from Docker images, in your Azure subscription or on-premises. Check the midPoint system requirements for supported Java and PostgreSQL versions.
- Parallel running depends on access: Use midPoint simulations against exported data while Omada stays authoritative, and confirm how long Omada tenant access remains available.
- Access requests move last: Port approval flows and review campaigns after provisioning is stable.
Confirm with Omada what the contract provides for data return and tenant access during the parallel run.
Identity Cloud Private runs in your own Azure tenant, so your operations team may already hold the subscriptions, network controls and logging that midPoint will need. That can simplify access for the export, but the supported export path still matters. Direct reads from the underlying data store may miss the logic that calculates assignments, so treat them as a supplement to the vendor's export rather than a replacement for it.
- Direct access helps the inventory: Use your existing Azure access to document resources, configuration and logs, then confirm with Omada which of these are safe to read.
- Residency stays in view: Keep the midPoint database and its backups in the same jurisdiction as the identity data, whether midPoint runs in the same Azure region or elsewhere.
- Mirror the operating model: Run midPoint on a VM or Docker host with PostgreSQL on a separate server. A multi-node layout adds a sticky HTTP load balancer and a shared central database.
- Decommission in phases: Keep Omada read-only during parallel running, then retire its Azure resources only after cutover is verified.
- Preserve evidence first: Export review history, certification records and provisioning logs before any shutdown, since auditors will ask for them.
Confirm with Omada which Azure resources, logs and data remain yours after the subscription ends.
An organization with a few target systems, such as a directory, an HR source and one or two applications, has a much smaller rebuild. The connector inventory is short, the parallel run can cover a few reconciliation cycles, and a single migration wave is workable. The hosting choice is simpler too, because a single midPoint node may be enough for a modest identity population.
- Check each connector against the catalog: midPoint documents LDAP, Active Directory, CSV, DatabaseTable, ScriptedSQL, Microsoft Entra ID through Graph API and SCIM2. Confirm the status of any other connector before you commit.
- Single-node hosting is an option: One midPoint node on a Linux VM or Docker host, with PostgreSQL on a separate server, covers many small deployments. Choose Java 21 for 4.10 or Java 25 for 4.11 and later.
- Short parallel run: Use simulations against exported data, then compare midPoint's planned changes with Omada's actual results for each target.
- Test the governance scope: If your main need is provisioning and self-service, compare the feature set before you build the full governance stack.
- Keep the cutover list small: Move each target in turn and keep a rollback path for the directory until its results match.
Confirm the connector status and the Java version for your chosen midPoint release before the build starts.
An estate with dozens of target systems, mixed protocols and many application owners makes connector rebuilding the largest part of the work. Parallel running has to be staged by target group, and the production design usually needs a multi-node midPoint deployment. Each target group becomes its own cutover, with its own verification and rollback steps.
- Rank connectors by protocol and support status: Sort targets into supported, community and experimental connectors, and mark custom work early because it drives the schedule.
- Cut over by target group: Move provisioning for one group at a time, and keep Omada authoritative for the rest until each group matches.
- Design the multi-node layout: A sticky HTTP load balancer, a shared central PostgreSQL database, HTTPS cache invalidation between nodes and Quartz for distributed task scheduling are the documented building blocks. Validate them against the ConnId connector documentation and the release notes for your version.
- Budget for custom connectors: Each custom ConnId connector is Java code behind a uniform interface, so it needs development, testing and ownership.
- Set up monitoring early: Watch task scheduling and connector errors across nodes during the parallel run.
Ask for a per-system cutover plan and confirm which connectors need custom development before you schedule any wave.
Questions buyers ask before moving from Omada to midPoint
How much does it cost to move from Omada to midPoint?
The migration cost is driven by the work, not by a license fee, because midPoint is published under EUPL-1.2 and Apache 2.0 and has no license charge. The cost sits in four components: the discovery and mapping of your identities, roles and approval processes, the connector work for your target systems, the HR source integration, and the parallel run and cutover. Each one is paid for as labor, either by your own staff or by a partner under a written scope. Recurring costs are infrastructure (application servers, a PostgreSQL database, backups, monitoring), the team that operates the platform, and an optional Evolveum support subscription. Ask any quote to split one-time migration effort from recurring run costs, and to name the connectors and integrations it assumes. Compare that against your current Omada subscription and its implementation program, which Omada prices on its own terms.
How long does an Omada to midPoint migration take?
The timeline depends on scope more than on the platform itself: the number of authoritative sources, the complexity of your role model, how many target systems need new or rebuilt connectors, and how many access request and review processes must be ported. Organizations with a clean HR source and a limited set of targets move faster than those with many legacy applications and manual approval chains. Parallel running adds time by design, because you compare midPoint's provisioning decisions with Omada's for a period before cutover. Your scope document should set phases, deliverables and a cutover window in writing before work starts. DeployOpen works on fixed-scope engagements agreed in writing, so the timeline comes from that agreed scope rather than from a generic estimate.
What does the migration require from our own team?
Your team supplies the knowledge that the platform cannot infer. In practice this means a named owner for the HR source data, owners for each target system who can confirm account attributes and entitlements, and approvers who can confirm the current access request and review rules. Your security and compliance leads need to define which controls and evidence must survive the move, and your infrastructure team must provide hosting, database, network paths to target systems, and identity for administrators. Expect them to test provisioning outcomes in a non-production environment and to sign off on parallel-run differences. Without these people available, connector and role work stalls, so confirm their time commitments before the scope is signed.
Can our internal team migrate from Omada to midPoint alone?
An internal team with Java, LDAP or directory administration, database and Linux skills, and prior identity governance experience can carry much of the work, particularly the operations side. The harder parts are usually the initial data model, the mapping of Omada's business logic into midPoint's role and policy concepts, and building or testing connectors for less common systems. midPoint's connector framework, ConnId, uses Java code behind a uniform interface, so a team without that background will need training or help. Evolveum offers training and professional services, and DeployOpen implements, customizes, integrates and documents open-source platforms inside your own infrastructure under a fixed scope. Many organizations choose a split: internal staff own operations, while an implementation partner handles the migration sprint. Assess the skills gap honestly before deciding.
Can midPoint replace Omada's access reviews and risk features?
midPoint covers role-based access control, auditing, self-service access requests and password reset, and simulations against production data, along with role mining, so the core of certification-style governance is present. Whether it matches every Omada access review workflow, risk scoring, or analytics feature is a question to confirm against the current midPoint release documentation for the version you plan to run, since feature coverage changes between releases. Map each Omada review and risk capability you use to a midPoint feature or a documented gap, and decide how to close gaps through configuration, custom development or a separate tool. Do this mapping before the cutover plan is fixed, because missing review features affect your compliance evidence, which DeployOpen can help prepare but auditors and certification bodies must assess.
Does midPoint need a separate SSO product?
Yes, you should plan for a separate single sign-on or access management product if you need one. Evolveum states that 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 you connect it to your existing identity provider rather than replacing that layer. Confirm which protocols your applications require and which identity provider they already use before you finalize the target architecture. The Identity and SSO pillar covers open-source options for that layer.
How do we run midPoint in parallel with Omada before cutover?
A parallel run means both systems compute access decisions for the same population while only one of them writes to target systems. You compare the entitlements each system would grant or remove, investigate every difference, and classify it as a defect in midPoint, a defect in the legacy Omada configuration, or an intended change. Start with a read-only comparison against a representative set of identities and sources, then extend it to joiner, mover and leaver events. Cutover should move provisioning ownership one target system at a time, with a rollback path documented for each step. Keep Omada's audit trail available during the run so you can reconcile evidence. The exact sequence should be fixed in the written scope.
What DeployOpen does in a midPoint migration
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted midPoint inside your own infrastructure, whether that is your Azure subscriptions, your data centers or an air-gapped network. For an Omada migration, that work starts with the decisions that are hardest to reverse: which Omada objects map to midPoint roles, assignments, policies and resource definitions, which HR source is authoritative for joiners, movers and leavers, and how the midPoint nodes, PostgreSQL database and load balancer are laid out. Most engagements are fixed-scope, so the export and mapping of identities, roles and assignments, the connector rebuild for each target system, the access request and review port, the parallel run and the provisioning cutover are each defined with deliverables and acceptance criteria in writing before any work begins. Ongoing support, upgrades and continuous testing can follow as a retainer once the cutover is complete.
Compliance work is where readers most often need precision about roles. DeployOpen prepares systems, controls and evidence for compliance assessments, such as documented provisioning procedures, access review records, change logs and proof that deprovisioning ran. It does not issue audit reports, attestations or certifications. Those come from your independent auditor or certification body, and you should confirm early which control frameworks they will test against, since that determines which evidence the parallel run must produce. A practical first step is to ask for the evidence list in the written scope, so that Omada's current audit trail can be compared with what midPoint records during parallel running before Omada is switched off.
How DeployOpen scopes, runs and supports the migration
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the migration from Omada to midPoint runs in your cloud accounts or data centers. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory of Omada identities, roles, entitlements, access request workflows and review campaigns in scope for the migration.
- Written list of target systems, connectors and HR source feeds that midPoint must reach before cutover.
- Agreed decisions on parallel running, cutover sequence and the acceptance tests that close each phase.
How we build
- Export and transformation scripts that map Omada identity and role data into midPoint objects, with reconciliation reports.
- midPoint deployment on Linux or Docker in your environment, with PostgreSQL configured as the repository database.
- Connector configuration through ConnId for each target system, tested against non-production copies before any live provisioning.
How we hand over
- Runbooks covering deployment, connector configuration, role design decisions and the parallel running results.
- Documented evidence of access reviews and provisioning tests that your compliance team and auditors can inspect.
- Knowledge transfer sessions so your administrators can operate midPoint, backed by the written handover package.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after cutover.
- Upgrade planning that tracks midPoint release support dates, so your platform stays on a supported release.
- Confirm with Evolveum whether a support subscription suits your operating model, since DeployOpen does not replace the vendor's own subscriptions.
