midPoint 4.10 to 4.11 upgrade

The direct path to midPoint 4.11 starts only from 4.10, and only when the installation is on the latest 4.10 maintenance version. The 4.11 release notes state that other versions must first move to a release that supports the step to 4.11. For planning, this means the first decision is not which features to adopt but which version you are on today. Check the exact running build, not the version your team last deployed, because a 4.10 installation that has missed maintenance releases does not qualify for the direct step until it is brought up to the latest 4.10 maintenance version.

If you run 4.9 or earlier, the path is longer. midPoint 4.9 support ends on 18 October 2026, and the 4.11 feature release is planned for 21 October 2026 according to the midPoint releases page. That timing leaves little room for a 4.9 installation to wait for 4.11 before moving. midPoint 4.8 (Curie) is a long-term support release supported until 17 October 2028, so a team that wants stability over feature releases may stay on that line instead. Whether that fits depends on your support obligations and on how much change your identity team can absorb, and the sibling topic on the midPoint 4.8 LTS upgrade path covers that choice and the stepwise route through 4.9 and 4.10.

Before you schedule the step, confirm three things with your own environment. First, record the current 4.10 build number from the running system and compare it with the latest 4.10 maintenance release on the midPoint releases page. Second, confirm that your database, Java runtime and container base are compatible with 4.11 as documented in the system requirements, since 4.11 recommends Java 25 while 4.10 uses Java 21. Third, decide whether you will test the step in a non-production copy that is restored from a recent backup, so the direct upgrade is rehearsed against your own connectors and data.

If your installation is not on the latest 4.10 maintenance version, the work to reach it is a prerequisite project, not a footnote. Plan it as its own change with its own testing, rollback point and sign-off. Teams that combine a maintenance catch-up with the 4.11 schema changes, bundled connector updates and container permission fixes in one window make failures harder to diagnose, because it is unclear which change caused a problem. Keep the steps separate where you can, and document the build you started from so that any later audit or support request shows exactly which path was taken.

The midPoint 4.11.0 container images run as the non-root user midpoint with UID 1000. A volume created under an earlier image may be owned by a different user or group, so the new process may be unable to write to it. The failure often appears only after startup, when midPoint tries to write logs, state or configuration files. Before you deploy 4.11.0, inventory every volume mounted into a midPoint container, record its current owner and group, and confirm which mounts the midPoint process writes to. Volumes that hold only read-only configuration may need no change.

In Kubernetes, the first option is setting securityContext.fsGroup to 1000 in the pod spec. The kubelet then applies group ownership to the volume contents and grants group read and write access, so the midpoint user can write through its supplemental group. The change is declarative and leaves existing files in place. Whether and how fsGroup is applied depends on the volume type and storage driver, and some drivers apply it only at mount time or skip it for certain volume types. Confirm the behavior with your storage class before relying on it, and ask your platform team whether pod security admission or a policy engine permits fsGroup on this workload.

The second option is an init container that runs as root, changes ownership of the mounted paths to 1000:1000, and exits before the midPoint container starts. It works on Docker and on Kubernetes without depending on fsGroup support, and it lets you limit the change to the directories midPoint writes to. The trade-offs are that it needs a root-capable image and a security context that many clusters restrict, a recursive chown on a large volume adds startup time on each restart unless you guard it, and ownership changes persist for any other consumer of the same volume. Check that no other process still expects the old owner before running it.

Test both options on a copy of the production volume before changing live data. Restore a recent backup or snapshot to a staging volume, deploy the 4.11.0 image against it, and confirm that the pod starts, logs are written, and a login and a simple reconciliation complete. Use the 4.11 release notes at the Evolveum documentation site, together with observed writes in your own deployment, to confirm which paths the image writes to, then limit permission changes to those paths. Keep the original volume untouched so you can roll back the image and the ownership together if the test fails.

Test the 4.11 upgrade on a restored copy of production data before any production cutover, and settle the rollback approach before the change window opens. The reason is structural. midPoint 4.11 adds database schema changes, including new tables for ApplicationType and ConnectorDevelopmentType, so a rollback after cutover depends on restoring the database backup taken before the upgrade. Starting the 4.10 image again against a migrated database is a step you should only plan on after Evolveum confirms the supported downgrade behavior for this version pair in writing. Record that answer in the change plan with the date it was given.

Login and identity flows. Start with authentication. Test administrator login to the midPoint user interface, ordinary user login, and login through any external SSO service the deployment uses. Because midPoint 4.11 removes deprecated OidcResourceServerAuthenticationModuleType attributes such as issuerUri and jwkSetUri in favour of jwt and opaqueToken token definitions, check that every authentication module in your configuration still loads and that tokens are accepted. Also confirm that a break-glass administrator account works, since a broken SSO configuration can lock out the people who would fix it.

Reconciliation and provisioning. Bundled connector version numbers changed in 4.11, so update each resource's connector reference and then test each connected target system separately. Run a reconciliation on every resource and compare the changes it proposes with the 4.10 baseline from the same data. Then provision a dedicated test account through midPoint and confirm create, modify, disable and delete on each target. Keep these results as evidence, because they are the basis for the go or no-go decision.

Approvals, certification and scheduled tasks. Create an access request that goes through an approval, and confirm that work items reach the right approvers and close correctly. Start a test certification campaign and check that reviewers see their items and that decisions are recorded. Confirm that tasks scheduled under Quartz fire on their expected schedule after the upgrade and that no task runs twice. If the deployment is clustered, test cache behavior across nodes. midPoint invalidates caches between nodes over HTTPS, so confirm that a change made on one node is visible on another, and ask Evolveum how mixed-version nodes behave before you run them side by side.

Containers and the rollback decision. For non-root 4.11.0 container images, the midpoint user with UID 1000 must be able to write to existing volumes. Set securityContext.fsGroup to 1000, or use a chown in an init container, and test that the application starts and writes logs and files in staging. Keep the database major version change for PostgreSQL 18 out of the same window unless you have tested that combination separately. Before cutover, write down the rollback trigger, the person who makes the call, and the criteria for each test. Verify the pre-upgrade backup with a restore test so that the rollback path works when it is needed.