What midPoint upgrades and support involve
midPoint is a Java identity governance platform that many teams run for years, so the way it is upgraded and supported decides whether the identity service stays current, supported and safe. Upgrades are not a one-time event. Each release line has its own support end date, and the platform sits on a Java runtime, a PostgreSQL repository and a set of ConnId connectors that each change on their own schedule. Plan for the identity team to make these changes repeatedly over the life of the deployment.
The usual triggers are: an end of support date for the release you run, a planned move to a newer long-term support or feature release, a Java runtime change, a database upgrade, a new version of a connector your target systems depend on, or a security finding that requires a fix. Check the midPoint releases page for current support dates before you set a plan, since a release that is supported today may have an end date within your planning horizon. Each trigger changes a different part of the stack, so the test scope differs by trigger.
Short answer on in-house or partner: teams that already have Java, PostgreSQL and midPoint skills, plus spare test capacity, often keep routine upgrades in-house. Teams with few midPoint administrators, or with a strict change calendar that leaves little room for testing, often bring in a partner for the upgrade and support window. Either way, Evolveum offers Product Support and Platform subscriptions, and a partner's work sits alongside those subscriptions, not in place of them.
Confirm before you decide: which midPoint release you run and its end of support date, which Java version the release recommends, how many staff can perform and test an upgrade, and whether your change calendar allows a parallel test environment. Ask any partner to state in the written scope which subscription tier, if any, they expect you to hold, and who opens and tracks vendor tickets during the window.
What the work includes
Each engagement is scoped in writing before work starts. The work runs from release choice through testing and cutover to support, and it ends with a written upgrade plan, test results, updated runbooks, change records and a handover pack.
Release selection by support window
Choose between midPoint 4.8 (Curie), the long-term support release supported until 17 October 2028, and feature releases such as 4.10 (Braille), supported until 26 November 2027. Check the release calendar for 4.11 (Čapek), planned for 21 October 2026, and confirm that 4.9 support ends on 18 October 2026 before you commit to a version.
Impact assessment and Java planning
Review release notes against your custom objects, mappings, connectors and plugins before work starts. Set the Java runtime with the release: midPoint recommends Java 21 for 4.10 and older and Java 25 for 4.11 and later, with Java 21 still supported for 4.11. Confirm which JVM builds your servers and container images use.
PostgreSQL repository upgrade and backups
midPoint keeps its repository in PostgreSQL, ideally on a separate database server. Plan the database version change, take a full backup, and restore it to a scratch server to confirm it is usable before the production step. Record the object counts and checks you performed so the rollback path has evidence behind it.
Rehearsal with regression testing
Run the upgrade in a non-production copy built from a recent production backup, using the same connector versions and test instances of target systems where possible. Test configuration objects, role assignments, approval flows and each connector against representative accounts. Compare results with the pre-upgrade baseline and log every deviation for a decision.
Cutover, rollback and monitoring
Write a cutover runbook with ordered steps, go and no-go checks and named owners for each step. Define the rollback plan: the trigger conditions, the backup to restore, and the node and database steps that return the system to the previous version. After cutover, monitor task execution, connector errors and log output for the period agreed in the plan.
Support, patching and handover
Support covers incident handling within response windows written into the signed scope, review of midPoint patch releases and their effect on your deployment, and maintenance of connectors as target systems change. Knowledge transfer to your administrators keeps routine upgrades and recovery steps inside your own team.
What drives cost and duration
Each row names a factor in the written scope that moves effort, and the table shows why it matters and how to keep it down, with no figures because cost and duration are set by that scope.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Nodes and environments | Each node adds configuration, testing and patching work, and each environment needs its own upgrade rehearsal. | Keep the node count to what load requires, and use a short, documented promotion path from test to production. |
| Object templates, mappings and schema extensions | Large numbers of custom templates, mappings and extensions drive regression risk and rework at every upgrade. | Keep customizations in version-controlled exports and retire mappings that no longer serve a purpose before upgrading. |
| Custom scripts and code | Custom code can depend on internal interfaces that change between releases, so each change needs review. | Inventory custom code, limit its scope, and record which release each piece was tested against. |
| ConnId connectors and target systems | Each connector version and target system needs its own compatibility check, and connector changes can affect account data. | Limit connectors to those in use, record their versions, and test each target system in a staging copy. |
| Release gap and intermediate steps | Each intermediate stop adds a full upgrade and test cycle. Check the release notes for every step on the path. | Start from a supported line, such as 4.8 LTS, and plan the path to the target release early. |
| Java and PostgreSQL changes | Java or PostgreSQL moves add a separate platform upgrade. midPoint recommends Java 25 for 4.11 and later, Java 21 for 4.10 and older. | Align Java and PostgreSQL steps with the midPoint version, and confirm supported combinations in the system requirements. |
| Regression testing depth | Expected coverage of roles, approvals, certifications and connectors sets how many test cycles the upgrade needs. | Agree test cases and pass criteria in writing, and reuse automated checks from earlier cycles. |
| Change freeze windows and approvals | Freeze periods and approval gates set the calendar and can force idle time between test and production. | Book change windows early and bundle approvals so each review covers the full change set. |
| Support level | An 8x5 next-business-day or 24x7 SLA under Evolveum Product Support sets response commitments and cost. | Match the SLA to the business impact of downtime, and confirm current terms with Evolveum before deciding. |
How an upgrade or support engagement runs
The sequence moves a midPoint installation to a supported release through tested steps, with a documented rollback point and a handover the client's team can run.
Inventory the current installation
DeployOpen reviews the running midPoint version, configuration objects, connector versions, custom code, the PostgreSQL version and the Java runtime on each node. The output is a written inventory listing each component, its version and every change that needs a decision before the upgrade. The client confirms the inventory is complete before planning starts.
Select the target release
Compare the current version with the support dates in the midPoint releases documentation: 4.8 is a long-term support release supported until 17 October 2028, 4.10 is supported until 26 November 2027, and 4.9 support ends 18 October 2026. Confirm the matching Java version, 21 for 4.10 and 25 for 4.11 and later, and the database support in the release notes. The output is an agreed target version with its runtime requirements.
Build the test environment and copy data
Build a non-production environment that matches production in topology, Java runtime, database version and connector set, then restore a recent database backup and the connector configuration into it. Connectors point at test endpoints or sandboxed target systems, so provisioning cannot reach live accounts. The output is a documented environment that starts, authenticates and reconciles against test targets.
Rehearse the upgrade and log defects
Run the full upgrade procedure on the test copy as many times as needed to produce a stable runbook, recording every error, deprecated setting and connector warning. Each defect is logged with reproduction steps, and where a bug is confirmed in midPoint itself, a fix is sought through Evolveum, including through a support subscription if the client holds one. The output is a runbook and a defect log with the status of each item.
Run regression tests on identity processes
Test provisioning to each connected target, reconciliation runs, access certification campaigns and approval flows, comparing results on the same data set between the current and target versions. Repeat affected tests after each fix. The output is a regression report listing passed tests, failed tests and differences the client's process owners have accepted in writing.
Cut over production with a rollback point
In a change window agreed with the client, pause scheduled tasks and provisioning, take a verified database backup and a copy of the installation, then apply the upgrade using the rehearsed runbook. If a go or no-go check fails, restore the backup and return to the previous version. The output is a running production system, a confirmed rollback point and a change record of each step taken.
Stabilize, hand over and run support cycles
Monitor task execution, connector errors and reconciliation results through the agreed stabilization period, then transfer runbooks, configuration records and known issues to the client's team. Under a support retainer, the cycle repeats with monitoring, patch review against new releases and support dates, and incident handling. The output is a handover pack and, for retainers, a recurring report of patches, incidents and open defects.
What stays in-house and what goes to a partner
This table compares which midPoint upgrade and support activities usually stay with the internal team and which are usually handled with a partner, with the skills each one needs.
| Activity | Usually in-house | Usually with a partner | Skills needed |
|---|---|---|---|
| Identity data ownership and approval of changes | Sets who approves which attribute, role and entitlement changes and keeps final sign-off | Documents the approval flow and checks that configuration matches the agreed rules | Identity governance policy, HR data knowledge, change control |
| Change calendar decisions | Chooses upgrade windows around business, audit and HR cycles | Proposes sequencing of config, connector and Java changes against the calendar | Release management, stakeholder coordination |
| Release selection | Decides between the LTS line and a feature release based on support dates and risk appetite | Assesses which midPoint changes affect the client's mappings, roles and connectors | Reading the midPoint releases page, product risk assessment |
| Java and PostgreSQL platform administration | Operates the JVM, database servers, patching and access to the repository | Plans required Java and PostgreSQL version changes and tests them in staging | Linux, Java runtime, PostgreSQL administration |
| Connector test accounts on target systems | Creates and owns accounts in directories and applications that midPoint manages | Specifies the accounts, permissions and test cases needed for each connector | Target system administration, ConnId connector knowledge |
| Regression test scripts | Reviews scenarios and signs off results against business rules | Writes and maintains repeatable scripts for provisioning, reconciliation and certification | Test automation, midPoint object model, mappings |
| Upgrade rehearsal and cutover execution | Runs the production cutover and holds rollback authority | Rehearses the upgrade in a copy of production and documents each step and timing | Change execution, midPoint upgrade procedure, database backup and restore |
| Defect triage with Evolveum | Reports issues, confirms reproduction in the client environment and applies fixes | Narrows the cause to configuration or environment, or prepares a reproducible case for Evolveum | Reproduction, log analysis, midPoint internals |
| Day-to-day operations | Monitors tasks, reconciliation runs, failed provisioning and certification campaigns | Provides runbooks, tuning advice and support during incidents | Operations, midPoint task and log knowledge |
What goes wrong and how to prevent it
Each risk below names a cause and the control that prevents it. Use the list as a checklist when you write the upgrade plan and the rehearsal scope.
Runtime versions left behind
Upgrading midPoint without moving the Java runtime or PostgreSQL can stop the application from starting or break repository migrations. midPoint recommends Java 25 for 4.11 and later and Java 21 for 4.10 and older. Record current versions, confirm the target pairing in the system requirements, and rehearse any PostgreSQL major version change as a separate migration.
Skipped releases and end of support
Jumping over an intermediate release can leave schema and configuration changes unapplied, and a long project can outlast a release's support window. midPoint 4.9 support ends 18 October 2026, and 4.8 (Curie) is supported until 17 October 2028. Map the upgrade path release by release and choose a target line whose support end date outlasts the project.
Untested rehearsal and rollback
Rehearsing on an empty or outdated database hides problems that appear with production-scale data and history. Restore a recent copy of production data into a rehearsal environment, run the full upgrade, and measure how long it takes. Test the rollback in the same run by restoring the database backup and confirming midPoint starts on the previous release.
Custom mappings and expressions
Mappings, expressions and object templates written for one release can evaluate differently after a version change, altering attribute values or assignments during reconciliation. Keep customizations in version control, list each mapping and expression, and compare outputs for a set of test identities before and after the upgrade.
Connectors out of step
A connector may require a newer midPoint release, or its support status in the ConnId integration catalog may drop after an upgrade. Check each connector against the target release, confirm its current status with Evolveum, and test provisioning, reconciliation and deprovisioning against a non-production target.
Scheduled tasks left unchecked
Reconciliation and access certification campaigns run on schedules that an upgrade can alter, pause or leave behind, and the gap often surfaces only when a review is due. After the upgrade, list every scheduled task and certification campaign, confirm its next run time and scope, run one reconciliation manually, and check the results before returning to production.
How the work changes by starting point
Support for midPoint 4.9 ends on 18 October 2026, so the upgrade is driven by a support deadline. Start by confirming the version in every environment, including test and disaster recovery copies.
- Target choice: decide between 4.8 LTS and a later feature release before the schedule is fixed, because the choice changes every later step.
- Sequencing: pass through intermediate versions only where Evolveum's upgrade guidance requires it, and confirm that path in writing.
- Testing: run connector jobs and certification campaigns against the target version in a staging copy with production-like data.
- Cutover: freeze configuration changes during the window and keep a verified database backup with a tested restore.
- Confirm: with Evolveum, the supported upgrade path from your exact version and whether your support subscription covers the work.
midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028. The decision is about cadence: staying on the LTS line means fewer upgrades, while feature releases bring new capabilities on a shorter support window.
- Feature need: list the capabilities you need from later releases. If the list is empty, the LTS line usually keeps the plan simple.
- Testing: if you move to a feature release later, test connectors and custom object templates against that release as well as 4.8.
- Operations: apply 4.8 patch releases on a routine schedule so the environment stays on a supported patch level.
- Planning: if you adopt feature releases, plan for more frequent upgrade windows and allocate identity team time for each one.
- Confirm: the current 4.8 patch level and whether your Evolveum subscription covers the LTS line.
midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and it recommends Java 21. Validate the Java runtime first, because the 4.11 path changes the recommended version again.
- Runtime check: confirm the JVM in each environment, including build hosts for custom code, and check that your operating system supports it.
- 4.11 timing: midPoint 4.11 (Čapek) is planned for 21 October 2026. Decide whether to stop at 4.10 or combine the version and Java change in one window.
- Java choice: 4.11 recommends Java 25 and still supports Java 21, so choose one JVM and test that combination end to end.
- Testing: run connector and custom expression tests on the new runtime before any schema or configuration change.
- Confirm: with Evolveum, which Java versions the exact patch release supports and whether custom libraries need updates.
A multi-node midPoint cluster adds coordination to every upgrade. Nodes share one PostgreSQL repository, sit behind a sticky HTTP load balancer, invalidate caches between nodes over HTTPS and schedule distributed tasks with Quartz.
- Upgrade method: confirm with Evolveum whether mixed-version nodes are supported during a rolling upgrade or whether a full stop is required.
- Testing: test failover, session stickiness and scheduled task behavior on a cluster running the target version, not only on a single node.
- Cutover: remove one node at a time from the load balancer, then check task and cache state before moving to the next node.
- Database: take and verify a repository backup before the first node changes, and plan any database upgrade as a separate step.
- Confirm: the Java requirement for each node and whether the load balancer configuration needs changes for the target version.
Docker images, a Linux virtual machine and Kubernetes each change how the new version arrives and how a rollback works. In restricted networks, every package and container image must be staged inside the perimeter before the window opens.
- Docker or VM: for images, pin the tag and rebuild with the target Java runtime. For a virtual machine, plan the package install and the configuration file migration.
- Kubernetes: test manifests, health probes and persistent configuration against the new release, and keep the previous image available for rollback.
- Air-gapped: mirror release packages, container images and connector artifacts into your internal registry and repositories, then verify checksums.
- Testing: repeat the full test cycle inside the restricted network, because external downloads are unavailable during cutover.
- Confirm: with Evolveum, which images and artifacts are published, and whether your internal mirror must include optional connectors.
What you need to provide
Start with a written inventory of the current midPoint version, the Java runtime, the PostgreSQL version, the deployment type (virtual machine or Docker images) and the node count. These five facts decide the upgrade path. For example, midPoint 4.9 support ends 18 October 2026, midPoint 4.10 and older expect Java 21, and 4.11 and later recommend Java 25. Confirm each value on the running nodes and database server, and record the date each value was checked.
Provide read access to configuration exports, including object templates, mappings, roles, archetypes and schema extensions, and to any custom code such as custom connectors or scripts. Provide a non-production environment with a recent copy of the repository so the upgrade can be rehearsed on production-like data. Include connector test accounts on each target system with rights to create, change and disable test identities. Missing test accounts and stale environments are the most common reasons upgrade schedules slip, so confirm both before dates are agreed.
Name an owner for identity data who can state what the authoritative HR and directory records mean and who signs off on data quality after the upgrade. Name a change approver who can sign the production change, and a contact in each target system team who can confirm connector behavior and agree a maintenance window. Share the change calendar and the freeze windows for midPoint and every connected system, so the upgrade window can be placed around them before the plan is fixed.
Decide the release target first. midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, midPoint 4.10 (Braille) is a feature release supported until 26 November 2027, and midPoint 4.11 (Čapek) is planned as a feature release for 21 October 2026. Decide the support hours you need, either 8x5 next-business-day or 24x7 SLA under an Evolveum Product Support subscription. State the Evolveum subscription level you already hold, if any, and confirm with Evolveum what it covers.
Common questions about midPoint upgrades and support
Should we run midPoint 4.8 LTS or a feature release?
For most teams planning a multi-year deployment, the LTS line is the stronger base. midPoint 4.8 (Curie) is a long-term support release with support until 17 October 2028. Feature releases bring newer capabilities but shorter support windows: 4.10 (Braille) is supported until 26 November 2027, and 4.9 support ends 18 October 2026. The feature release 4.11 (Čapek) is planned for 21 October 2026. Choose a feature line only when you need a specific capability, and confirm all dates on the official midPoint releases page before you commit.
How much does a midPoint upgrade cost and how long does it take?
Cost and duration follow the same drivers: how many midPoint versions you cross, how much custom configuration you run (object templates, mappings, schema extensions, custom forms), how many connectors and target systems need regression testing, the database size, and whether the deployment is multi-node. No figure is given here. A fixed-scope quote should list the versions in scope, Java and PostgreSQL changes, environments, configuration and connector test cases, the rollback plan, the cutover window, handover documentation, what your staff provides, and exclusions. Ask which items are one-time and which recur.
Can our own team upgrade midPoint without an outside partner?
Yes, a team can upgrade midPoint itself if it has people who can operate Linux or Docker hosts, PostgreSQL and Java runtimes, plus a staging environment that closely matches production. Your staff needs to inventory configuration, run regression tests on each connector, approve the cutover window and own post-upgrade checks. Most of the risk sits in testing, so plan test time honestly and set rollback criteria before the window opens. A partner can take on any of these tasks under a written scope.
How do Evolveum subscriptions and partner support fit together?
They cover different work and complement each other. Evolveum Product Support subscriptions cover resolving midPoint product bugs, with an 8x5 next-business-day or 24x7 SLA. Platform Subscriptions add feature development and influence over the roadmap. Partner support covers work in your environment: design, configuration, connectors, testing, upgrade execution and handover. Evolveum fixes product defects, while your partner or internal team owns your deployment. The Evolveum support subscriptions page does not list prices, so request current terms from Evolveum.
Which Java version does each midPoint release line require?
Java 25 is recommended for midPoint 4.11 and later, with Java 21 supported. Java 21 is recommended for 4.10 and older, with Java 17 supported. Confirm these details on the midPoint system requirements page before you fix the target version. Treat the Java change as its own test stream covering startup, connector behavior and performance, and run it in the same test cycle as the platform upgrade so you can separate the causes of any failure.
What happens if a connector is not maintained by Evolveum?
The connector's status in the Evolveum integration catalog determines how much vendor support you can rely on, and the catalog ranges from supported to community and experimental. Confirm the status, maintainer, release history and compatibility with your target midPoint line before the upgrade plan is fixed. For a community or experimental connector, assign an owner for fixes, pin the connector version, add it to regression tests and keep a rollback path.
How DeployOpen runs midPoint upgrades and support
DeployOpen plans and carries out midPoint upgrades in infrastructure you control, from release selection and Java changes through configuration and connector testing. Engagements are fixed-scope, and ongoing support is available as a retainer.
How we scope
- Confirm the current midPoint version, support end dates and whether you are on an LTS or feature release.
- Map the Java runtime, PostgreSQL version and deployment model (VM or Docker) that the upgrade will touch.
- Inventory custom object templates, mappings, schema extensions and every ConnId connector in use.
- Record the written scope, deliverables and timeline agreed before any upgrade work starts.
How we build
- Stand up a staging environment that mirrors production topology, including multi-node setups if you run them.
- Run the planned Java change in staging and check midPoint startup, task scheduling and the admin interface.
- Test each connector against representative target systems and compare provisioning results before and after the upgrade.
- Rehearse the production cutover, including repository database backup and a documented rollback path.
How we hand over
- Deliver the upgrade runbook with exact steps, checks, owners and the rollback sequence.
- Document configuration changes, connector versions and any deviations from the default setup.
- Walk your identity and platform team through test results and open items before closing the engagement.
- Record the release and support dates your team needs for the next planning cycle.
How we support
- Agree a support model in writing, covering who handles incidents, how changes are requested and what is in scope.
- Offer ongoing support, upgrades and continuous testing as a retainer if you want a partner on call between projects.
- Plan future upgrades against published support end dates so that releases do not reach end of support unplanned.
- Ask us to confirm how Evolveum Product Support subscriptions would be combined with partner work in your environment.
