Upgrade Planning, Version Support, Breaking Changes, Java Runtime Upgrades, and Rollback Strategy: Configuration, Design Choices, and Tradeoffs

1. Latest supported versus conservative supported

“Conservative” must still mean supported. Staying on a sunset line to avoid change simply converts upgrade risk into security/support debt.

2. Bundled Java versus managed external JVM

The bundled runtime minimizes compatibility drift and is the default recommendation for most installations. An external JVM can be justified when the platform has a controlled Java lifecycle, but then the team owns compatibility checks, override variables, CA/truststore behavior, JVM observability changes, and upgrade sequencing.

3. Standalone versus rolling upgrade

A Community/single-node lesson uses a maintenance window: stop, checkpoint, replace binaries/container image, start, migrate/rebuild, validate. Rolling/zero-downtime upgrade is an HA capability and has mixed-version rules, database-finalization semantics, and supported path limits; it is not “start two independent Community servers and upgrade one at a time.”

4. Plugin removal versus delayed upgrade

Community plugins are not supported by Sonatype. If a plugin blocks a supported upgrade, evaluate the business function it provides. Often the long-term answer is supported REST/UI automation or product functionality, not pinning Nexus indefinitely. If postponement is unavoidable, document owner, expiry, security exposure, and replacement plan.

5. Database and blob topology

An upgrade should preserve the existing supported database/blob topology unless the documented version gate specifically requires change. Combining Nexus version, database engine, blob backend, reverse proxy, and identity-provider changes increases the number of possible failure causes and weakens rollback clarity.

6. S3-compatible object stores require version-aware testing

Earlier 3.87.x release notes changed the AWS SDK generation used by Nexus and warned that non-AWS S3-compatible implementations can be affected. This is the pattern to learn: a Nexus version can be compatible with “S3” in general while a specific third-party S3 implementation breaks. Rehearse real APIs against a disposable equivalent rather than trusting a label.

7. Rollback probability versus schema/data changes

Before the target writes or migrates persistent state, rollback may be as simple as aborting and keeping the source untouched. After persistent mutation, rollback cost rises because a coherent restore is required and post-cutover writes may have to be replayed. Set the go/no-go decision point before irreversible change.

8. Worked scenario

9. Production policy template

upgradePolicy:
  target: latest-supported-after-rehearsal
  require:
    - release-notes-reviewed
    - crossed-thresholds-evaluated
    - backup-restorable
    - plugins-compatible-or-removed
    - java-and-truststore-validated
    - database-and-blob-supported
    - format-client-smoke-tests
  rollback:
    method: restore-pre-upgrade-checkpoint
    forbid: start-old-binaries-on-upgraded-data

Knowledge check

Summary and next step

Good upgrade design reduces simultaneous variables, keeps unsupported extensions out of the critical path, and aligns target choice, runtime ownership, availability mode, and rollback mechanics with observable state.

Lesson 4 now diagnoses what happens when those assumptions fail.

Official references and version notes

• Sonatype: Upgrade Nexus Repository — standalone upgrade workflow, backups, install/data separation, vmoptions, TLS/custom configuration, and validation.
• Sonatype: Nexus Repository Upgrade Paths — version-crossing actions and compatibility gates.
• Sonatype: Nexus Repository 3 Versions Status — support status and community-plugin guidance.
• Sonatype: Nexus Repository 3.95.x Release Notes — current-line changes, known issues, and upgrade guidance.
• Sonatype: System Requirements — current Java 21 and operating requirements.
• Sonatype: Upgrade Nexus Repository Java Version — bundled Java behavior and external-JVM considerations.
• Sonatype: Java Runtime Compatibility Matrix — release-specific external Java compatibility.
• Sonatype: Prepare a Backup — coherent database/blob/configuration recovery preparation.
• Sonatype: Upgrading to 3.71.0 and Beyond — legacy OrientDB/H2 gates.
• Sonatype: Rolling Upgrades in High Availability — Pro/HA mixed-version and finalize-upgrade semantics.