Migrate to Nexus Repository from Artifactory
Migrating from JFrog Artifactory to Sonatype Nexus Repository involves several key steps. Here's a breakdown of the process, covering planning, data migration, configuration, and testing.
Local -> Hosted Repositories: For storing your internal artifacts.
Remote -> Proxy Repositories: For proxying external repositories.
Virtual -> Group Repositories: For aggregating multiple local(hosted) and remote(proxy) repositories.
Create a Migration Plan
Document the migration process and set expectations across your stakeholders. Understand the scope of the planned work to limit downtime. This requires a complete inventory of repositories, access controls, and the build processes where your organization depends on the repository manager.
Choose a Migration Strategy
Content may be migrated in full using a Repository Export from Artifactory or as an incremental migration using proxy repositories in Nexus Repository connecting to the Artifactory instance.
Migrating in phases results in shorter downtime and less disruption to development teams but requires a longer migration window with an overlap of ownership of both products. Build integrations that use custom scripts and staging workflows need to be redesigned for Nexus Repository. Focusing on one team at a time leads to less disruption.
Setup Nexus Repository
Install and configure Nexus Repository with access controls, service configuration, and repositories to store the migrated artifacts.
See Planning Your Implementation for details on designing your infrastructure.
Create proxy repositories to remote URLs used by Artifactory. Proxy repositories are populated as builds are run against the repository. Run test builds to ensure artifacts are resolved and deployed correctly. This is to only proxy artifacts that are actively in use. Alternatively, you may choose to preemptively prefetch every artifact found in the Artifactory remote repository so that they are primed for use in the Nexus Repository as you cannot directly import components into a proxy repository. This preemptive fetch is done using a custom script.
Create proxy repositories connecting to the local repositories on the Artifactory instance. Combine these with hosted repositories using group repositories so that builds may access all their required content from a single endpoint. This provides access to artifacts that have not yet been migrated to Nexus Repository. Once everything has been migrated these proxies may be removed.
Create group repositories matching your virtual repositories. The endpoints are different so we recommend modifying your builds to point to the new endpoints rather than redirecting the traffic.
Begin mapping builds to use Nexus Repository so new artifacts are not deployed to Artifactory. While these builds may experience higher latency as artifacts are fetched from Artifactory, it is harder to keep track of the migrated content once exported from Artifactory.
Migrate the Repository Data
Export the local Artifactory repositories using the Artifactory Import/Export functionality. If that functionality is not available with your deployment, you may request a backup to be taken and made available to you (See Artifactory's documentation).
Import the exported data into the hosted repository's storage folder using the Nexus Repository import process (See Repository Import). Nexus Repository CE users may use a script to push these artifacts to the hosted repository (note that metadata such as created date is not retained using this method making cleanup more difficult).
Test and validate your Nexus Repository
You may loosely compare artifact counts and sizes between Artifactory and Nexus Repository however, these totals may not be consistent between instances. Nexus Repository includes repository metadata and indexes inside the blob store. You should also avoid migrating content to be archived or purged.
Run test builds to ensure artifacts are resolved and deployed correctly.