Nexus Repository Database Migration: OrientDB, H2 and PostgreSQL

Nexus Repository database migration is highly version-dependent. Supported paths, utilities, database engines, and licensing requirements can change between releases. Treat vendor documentation for the exact source and target versions as the authority before running any converter.

Define the supported path first#

Record the current Nexus version, edition, Java runtime, database type, data-directory layout, installed plugins, repository formats, and target architecture. Confirm whether the intended migration requires an intermediate application upgrade or an intermediate database conversion.

Migration readiness checklist#

• Verify the vendor-supported source and target versions.
• Read release notes for database and format changes.
• Measure database size, blob-store size, and expected downtime.
• Take application-consistent backups of the database, blob stores, configuration, and secrets.
• Test that backups can be restored before changing production.
• Provision enough temporary disk space for exports, logs, and rollback.

Never migrate the database alone#

Repository metadata and blob content must remain consistent. Copying only database files, or only blob stores, can create missing components and checksum errors. Stop writes at the documented point and preserve one coherent recovery set.

Use a staging rehearsal#

1. Clone production data into an isolated environment.
2. Install the exact supported migration utility and runtime.
3. Run prechecks and capture complete logs.
4. Execute the documented migration path.
5. Start the target version and inspect application logs.
6. Validate repositories, components, permissions, tasks, and integrations.
7. Measure duration and refine the production runbook.

Validation after conversion#

Production cutover#

Announce the freeze window, stop clients and scheduled writers, take a final recoverable backup, execute the rehearsed steps, and retain migration logs. Open access only after technical and business validation. Keep the original environment intact until the acceptance window closes.

Rollback criteria#

Define time and integrity thresholds that trigger rollback. Rollback should restore the application, database, blob stores, and configuration as one matched set. Do not allow writes to both old and new environments during an uncertain cutover.

Nexus Repository documentation