Skip to main content

Data Included, Excluded, and Changed During Nexus Repository 2 to 3 Upgrade Process

The Upgrade Wizard will help guide you through the upgrade process as outlined in Step-by-Step Nexus Repository 2 to 3 Upgrade Wizard Instructions. However, the wizard is only able to include certain configurations in the upgrade.

What is Included in the Upgrade?

The Upgrade capability upgrades the following automatically:

  • Configuration

    • Active Security Realms

    • Anonymous Access Settings

    • Atlassian Crowd Settings

    • HTTP Proxy Settings

    • LDAP Settings

    • NuGet API Keys

    • Privileges

    • Repository Health Check and its corresponding SSL trust store configuration

      • For OSS, only Health Check: Configuration capability settings are included

      • For Pro, existing SSL: Health Check settings are also included

    • Role Mappings for LDAP/Crowd

    • Roles

    • SSL Certificates that have been trusted in SSL Certificates feature

    • Users

    • User Tokens

  • IQ Server configuration

    • IQ Server URL

    • Username

    • Password

    • Request Timeout

    • Analysis properties

    • Trust store usage

    • Enabled Nexus IQ Server connection

    • Repositories configured with the Firewall Audit and Quarantine capability will keep the capabilities as well as the audited and quarantined items


While Nexus Repository 2 can keep running while upgrade occurs, changes to the content will only be upgraded through theSynchronization upgrade step. Changes to audited and quarantined items from the IQ Server are included in this caveat.

  • Repositories in supported formats:

    • Maven2 (excluding staging repositories)

    • npm

    • NuGet

    • Site (called Raw in Nexus Repository 3)

    • RubyGems

  • NuGet API key - The upgrade tool adds all keys from Nexus Repository 2 to Nexus Repository 3 even if the NuGet API Key Realm is not active in Nexus Repository 2

  • The following existing Nexus Repository artifact information is maintained during upgrade:

    • uploaded_by

    • uploaded_by_ip

    • uploaded_date

    • lastModified

Changes to Data During Upgrade Process

Nexus Repository 3 uses a different architecture from Nexus Repository 2; therefore, some core changes to data occur as part of the upgrade process.

Content Storage

In Nexus Repository 2, all content is stored in a filesystem on disk.

Nexus Repository 3, however, uses a blob store format for storing content. This allows Nexus Repository 3 to work with more formats since they no longer have to map directly to a file system. See Storage Planning for more details about how to work with blob stores.

Nexus Repository 3 must iterate over every component stored in Nexus Repository 2. This takes the bulk of the time required for the upgrade process.

Settings and Metadata

In Nexus Repository 2, settings and some component metadata are stored across many files.

Nexus Repository 3 loads equivalent data into the database.


Nexus Repository 2 uses a different URL pattern to expose repositories and repository groups than Nexus Repository 3. During upgrade, Nexus Repository 3 adds a NXRM2 style URLs capability to allow your automated tools and CI to use the old patterns. Configuring Legacy URL Paths covers this in more detail.


Roles upgraded from Nexus Repository 2 are assigned a Role ID that starts withnx2-in Nexus Repository 3. Role descriptions created during the upgrade process have the wordlegacy in their description.

Repository Targets

Repository targets from Nexus Repository 2 are converted to Content Selectors in Nexus Repository 3. Repository targets were based on regular expressions; these are automatically converted to Content Selector Expression Language (CSEL), a performant subset of JEXL.

Repository IDs

Nexus Repository 3 uses the Repository ID defined in Nexus Repository 2 as the Name for the upgraded repository; they define the access URL in both cases. The user-facing Repository Name from Nexus Repository 2 is dropped during the upgrade since there is no equivalent feature in Nexus Repository 3.

IDs of repositories and repository groups in Nexus Repository 2 that differ only by case will not be accepted during an upgrade to Nexus Repository 3 (example version 2 IDs: myrepoid vs Myrepoid). To resolve the ID conflict review and change any IDs in version 2 to distinguishable names.

HTTP(S) Proxy Configuration

Your HTTP or HTTPS proxy settings for Nexus Repository 2 may not be valid for your Nexus Repository 3 environment. You must configure your HTTP or HTTPS proxy settings in Nexus Repository 3 in order to upgrade them.

If HTTP or HTTPS proxy settings are enabled in your source Nexus Repository 2, the upgrade to your target Nexus Repository 3 might fail because the target can not communicate with the source repository manager. This could happen if Nexus Repository 3 could not find a Nexus Repository 2 proxy server in place.

If you enabled Nexus Repository 2 HTTP or HTTPS settings during an upgrade, Nexus Repository 3 would use its original HTTP or HTTPS settings and ignore the settings in place for Nexus Repository 2.

Nexus Repository 3 generates a warning is in the log if this error occurrs. It will also log "Skipping HTTP(S) proxy settings, connection to Nexus 2 failed using new settings. Please manually configure the HTTP proxy settings after the upgrade is done." if something else fails.

What is Not Included in the Upgrade?

The following items are not included in the upgrade:

  • Unsupported repository formats

    • Yum

      • RPMs stored in Yum-enabled Maven2 repositories on Nexus Repository 2 can only be moved to Maven2 repositories in Nexus Repository 3. Any Yum-related capabilities must be disabled on the Maven2 repository first. There is no automatic option to move RPMs in Nexus Repository 2 Maven2 repositories into Yum format repositories in Nexus Repository 3.

    • Maven1

    • p2

    • OBR

  • Capabilities

  • Custom branding

  • Custom log levels or edits to logback.xml configuration files (e.g., custom log file rotation, file naming, log patterns)

  • Environment variables affecting values used to control the repository manager

  • Java VM settings, including custom system properties or variables

  • Jetty server XML configuration files

  • Manual edits to other files under the nexus installation directory, such as edits to nexus/WEB-INF/classes/ehcache.xml

  • Operating system nexus service scripts

  • Operating system optimization, such as increasing allowable open file handles

  • Routing rules

  • Scheduled tasks

  • Staging repositories, settings, or configuration

  • The admin user password from Nexus Repository 2

  • Third-party or custom-developed plugins

  • Virtual repositories