Migrate midPoint to the native PostgreSQL repository

Evolveum states that the schema changes required for the native PostgreSQL repository are too large to apply as a SQL update. For an existing midPoint deployment, this means the data cannot simply be converted in place. It has to be exported from the current repository, the target database has to be prepared, and the data has to be imported back. Plan the project around that fact before you schedule anything, because the export and import steps are the core of the change, not a side task.

The documented path starts with the source system. Your current midPoint must first be upgraded to 4.4 on the original SQL configuration. Confirm this step with your own version inventory and with the Evolveum migration documentation before you touch the database. Skipping it or running a different version at export time moves the risk into the import, where it is harder to diagnose. Record the exact version you export from, because it determines which steps you follow and which checks you run afterward.

The export and import steps depend on Ninja, the command-line tool that the documented migration uses to move repository data out and back in. Ask your engineers to confirm the Ninja version that matches the midPoint release on each side, and to test the export command against a copy of production data. Keep the exported files under access control, since they contain the full identity and configuration data of the deployment. Treat the export output as an artifact to be verified, not just a file to be moved.

The target native PostgreSQL repository must be initialized before any data goes back in. The documented sequence is to initialize the new repository, switch the midPoint configuration to point at it, then import with Ninja and start midPoint. Decide in advance who owns the target database, what its sizing and backup arrangements are, and which PostgreSQL major version you will run. The PostgreSQL support window on your chosen version affects how long this database stays supported, so check it against the versioning policy when you pick the version.

Audit records follow a different route. Evolveum documents that audit records can be migrated while midPoint is already running on the native repository, so audit history does not have to block the main cutover. Agree with your compliance owner which audit data must be retained, how the audit migration will be verified, and how you will show that no records were lost. Whatever the schedule, ask the implementation team to write down the verification steps for both the core data and the audit data before the cutover window begins.

Audit records can be migrated while midPoint is already running on the native PostgreSQL repository, according to Evolveum's migration documentation. That is useful, but it does not remove the need for a cutover plan. The main migration moves the operational data through Ninja export and import, and midPoint has to be stopped and restarted on the new repository at a defined point. The audit history is a separate workstream that the team should plan, measure and verify on its own track, with its own owner and its own acceptance checks.

Before the team starts, it should settle four questions. The first is how much audit history must be kept on the new repository. Compliance, legal and internal audit owners should state the retention period in writing, because it decides how much data moves and how much storage the target database needs. The second is how long the audit migration will take in your environment. This duration cannot be taken from the documentation or from another deployment. It has to be measured in a pilot against a copy of your production audit data, on comparable hardware and with the same database configuration. The third is how completeness will be verified, and the fourth is who is accountable for the audit trail during the move.

Completeness checks should be agreed before the pilot runs. A practical approach is to compare record counts per table and per time window between the source and the target, sample individual events and confirm that their fields, timestamps and references match, and record the results in a signed reconciliation report. The team should also confirm which audit events are written during the move, such as the export or import activity itself, so that the trail explains its own gap or overlap. Ask the Evolveum documentation and your own test results to confirm the exact table names, the ordering guarantees and any filters before relying on them in a checklist.

Accountability needs a named owner, not a shared mailbox. In most organizations this is the identity governance lead, with the security or compliance team approving the reconciliation results and the platform team operating the database. The owner signs off on the retention scope, the pilot results and the decision to start the production audit move. If audit records are needed for an access review or an audit engagement during the migration window, the owner must know which data source is authoritative at each point in time. DeployOpen can help plan and document these checks, but it does not issue audit reports or attestations, and the independent auditor decides what evidence is sufficient.

Plan the cutover as the controlling event. Audit migration can run alongside production, but the team still needs a rollback decision, a freeze window for configuration changes and a verified starting point for the target repository. Record which audit data is copied before cutover, which is copied after and how any delta is reconciled. Treat a failed audit check as a stop condition for the cutover, and keep the source repository available until the reconciliation report is accepted. Cost and effort depend mainly on the audit data volume, the pilot scope and the number of reconciliation rounds, and should be stated in a written scope before work starts.

Choose the target PostgreSQL major version by checking its end-of-support date against your go-live date and the period you expect to run the system. PostgreSQL supports each major version for five years after its initial release. The versioning policy lists version 14 as supported until 12 November 2026, version 15 until 11 November 2027, version 16 until 9 November 2028, version 17 until 8 November 2029 and version 18 until 14 November 2030. Version 14 leaves support on 12 November 2026, which may fall before your go-live. Confirm the go-live date with the business owner first, then select the newest version that stays inside its support window for the expected life of the repository and that your hosting platform and backup tooling already support.

The midPoint release decision follows the same logic, and the midPoint releases page is the reference for it. Version 4.8 is a long-term support release supported until 17 October 2028, which suits a deployment that needs a long gap between upgrades. Version 4.9 support ends on 18 October 2026, so it should not be the target for a new migration. Version 4.10 is supported until 26 November 2027, and the same page plans version 4.11 for 21 October 2026. Feature releases need upgrades sooner than long-term support releases, so weigh the upgrade effort against the features you need. Check the release list again on the day you freeze the target, because planned dates can change.

The Java runtime is set by the midPoint release, so pick the release first and then confirm the JDK. midPoint recommends Java 25 for version 4.11 and later, with Java 21 also supported. For version 4.10 and older, midPoint recommends Java 21, with Java 17 also supported. Confirm the JDK on every midPoint node and on any administration host where you run the Ninja export and import commands, because those commands need the same runtime. Check that your operating system packages or container base image provide the required JDK before the build starts. A missing runtime found during the cutover window can delay the go-live.

midPoint recommends that PostgreSQL run on a separate database server, ideally isolated from the application nodes. Decide the topology before the build starts. Settle whether the database runs as a single instance or as a highly available pair, where backups are stored, and how network access from the midPoint nodes is restricted. PostgreSQL does not detect a failed primary or fail over on its own, so any high-availability design depends on external tooling that a named team must own and test. Confirm these decisions in writing with the infrastructure and security teams, and record the PostgreSQL version, midPoint release, JDK and topology together so the cutover runbook refers to one agreed baseline.