midPoint 4.8 LTS upgrade path

The direct-upgrade rule decides the order of every step. The midPoint 4.10 release notes allow a direct upgrade only from the latest 4.9 maintenance release. A team running any 4.8 build therefore cannot move straight to 4.10, even though 4.8 is a long-term support line. The supported path has two hops: first from the current 4.8 build to the latest 4.9 maintenance release, then from that release to 4.10. A project plan that shows 4.8 to 4.10 as a single change does not match the path Evolveum documents, so the schedule should give each hop its own preparation, verification and rollback point.

Confirm the target before you plan dates. Open the midPoint releases page on the Evolveum documentation site, locate the 4.9 entry and note which maintenance release is current. Then open the 4.10 release notes and read the upgrade section, which states the direct-upgrade condition. Record the exact version string, the date you checked and the page you used, and attach that record to the change request. Maintenance releases can appear between planning and execution, so repeat the check the day before the change window and update the runbook if the latest 4.9 release has changed. Also check that your planned window falls before midPoint 4.9 support ends on 18 October 2026.

Skipping the 4.9 step puts the upgrade outside the documented procedure. The release notes name 4.9 as the only source for a direct move to 4.10, so a team that starts from 4.8 has no vendor-documented procedure for that jump. If something goes wrong, the support conversation starts from an unsupported path, and the cost of recovery usually lands on the project. If you believe an exception is justified, put the question in writing to Evolveum or to your support subscription provider and wait for their answer before changing the plan. Do not treat a successful test in a lab as evidence that the jump is supported.

Each hop adds work that is easy to underestimate. Take a full backup of the repository database and the midPoint home directory before each hop, and test restoring one of them. Repeat regression tests on the connectors, roles and approval flows your organization uses, because a change that is harmless at the 4.9 stop may matter at the 4.10 stop. Check the Java runtime and repository requirements for each version against the system requirements page. Finally, note that midPoint 4.10 dropped support for repository databases other than PostgreSQL, so any non-PostgreSQL repository must be migrated before or as part of this path.

Treat each hop on the midPoint 4.8 LTS upgrade path as its own change, with its own test pass and its own rollback point. Do not treat 4.8 to 4.10 as one project with a single test cycle at the end. Before any hop leaves a test environment, agree on the checks that must pass: identity and role assignments, approvals, connector reconciliation against target systems, and scheduled tasks. Confirm the test scope for each hop against the release notes for that version, because the risks in a 4.9 hop differ from those in a 4.10 hop, which also carries the PostgreSQL-only repository requirement. Write the scope as a checklist with an owner and an expected result for every item, so that a failed check has a clear meaning and a clear decision attached to it.

Identity and role assignment tests should compare a fixed set of representative users and roles before and after each hop. Choose accounts that cover each HR-driven lifecycle state in use, each role that carries inducements, and each organizational unit with its own approval policy. Export their assignments, projections and effective access from the source version, then run the same comparison on the target. Use the preview of changes where it is available to see what a recomputation would do before it writes anything. For approvals, submit a request of each type that runs in production, approve one and reject another, and confirm that the approver chain, notifications and final assignment match the baseline. A silent change in who approves an access request is as serious as a changed grant, and it is easy to miss if only the final state is checked.

Connector reconciliation needs its own test against each target system, because a version change can alter how attributes are read or written even when identity data looks correct. Run reconciliation against a non-production copy of each connected system, using connector versions that your target systems are documented to support in the Evolveum connector catalog, and compare discrepancy counts and proposed changes with the baseline. Inventory every scheduled task with its schedule and effect, then confirm after the hop that each task runs on exactly one node. If the deployment uses a sticky HTTP load balancer, a shared central database, cache invalidation over HTTPS and Quartz for distributed scheduling, test a rolling restart and a node removed from rotation. Confirm with the vendor whether mixed-version operation is supported during a hop. If it is not, plan a full stop of the cluster as part of the window.

A rollback point has three parts that must match. The first is a database backup taken immediately before the hop, with midPoint stopped or quiesced so the snapshot is consistent. The second is the exact software artifact of the source version, along with the Java runtime that version ran on. The third is the configuration directory and any environment-specific settings, including connector bundles and references to secrets. Record checksums for the artifacts, and restore the backup into a separate PostgreSQL instance to prove it works before the window opens. An untested backup is not a rollback point.

Reverting a binary change is usually a matter of redeploying the old artifact against the same database. A repository migration is harder, because the schema and stored data may no longer be what the older release expects. Once the new version has migrated the repository and users have written new assignments or approval records, restoring the old binary alone may not be enough. The clean return point is then the backup taken before the migration, and every change made after that backup is lost on restore. Decide before each hop how long the system may run on the new version, who holds the authority to call a rollback, and what evidence will drive that call. Confirm the rollback guidance for each release in its release notes and with Evolveum before scheduling the change.