Sonatype’s page for an Artifactory team’s move to Nexus Repository is a guide to the steps. It names Artifactory’s own import and export feature and Nexus Repository’s import process, and it names no separate migration tool (Sonatype’s Artifactory migration page, read 2026-10-23). Whichever server you choose, your builds, credentials and lockfiles still need changing. This page sets out what Sonatype offers, what the move involves with either server, and what CloudRepo moves, with every Sonatype and JFrog fact quoted from its page and dated.
What Sonatype offers an Artifactory team
Sonatype’s page is titled “Migrate to Nexus Repository from Artifactory”. It gives two ways to move the content: “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” (Sonatype’s Artifactory migration page, read 2026-10-23).
On moving in phases, the page says “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” (Sonatype’s Artifactory migration page, read 2026-10-23).
How Sonatype maps the repositories
| Artifactory | Nexus Repository |
|---|---|
| Local | Hosted |
| Remote | Proxy |
| Virtual | Group |
The mapping is Sonatype’s, as its page lists it: local to hosted, remote to proxy, virtual to group (Sonatype’s Artifactory migration page, read 2026-10-23).
The export and import steps
For the data, Sonatype’s page says “Export the local Artifactory repositories using the Artifactory Import/Export functionality” and, if that functionality is not available with your deployment, “you may request a backup to be taken and made available to you” (Sonatype’s Artifactory migration page, read 2026-10-23). JFrog’s Import and Export page says “Importing repositories is supported for all users but exporting repositories is only available for non-SaaS users” (JFrog’s Import and Export page, read 2026-10-23).
The import step reads “Import the exported data into the hosted repository’s storage folder using the Nexus Repository import process” (Sonatype’s Artifactory migration page, read 2026-10-23). The import process is a Nexus Repository task that “takes content from a directory on the server and imports to a repository in Nexus Repository”, and its page marks the task as available only in Nexus Repository Pro (Sonatype’s Repository Import page, read 2026-10-23).
What the import task carries
- Artifacts only: “Import is limited to artifacts and does not include server configurations or tags” (Sonatype’s Repository Import page, read 2026-10-23).
- New metadata: “Metadata and checksums are generated automatically on import and do not maintain exported attributes” (Sonatype’s Repository Import page, read 2026-10-23).
- Formats: the page lists Raw, Maven, npm, NuGet, Docker, PyPI, RubyGems and Yum (Sonatype’s Repository Import page, read 2026-10-23).
Community Edition
For Community Edition, the migration page says “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)” (Sonatype’s Artifactory migration page, read 2026-10-23). The page does not name or link the script. If Community Edition is the plan, our article on its usage limits sets out what Sonatype’s pages say about them.
What stays your work
Sonatype’s page says “Build integrations that use custom scripts and staging workflows need to be redesigned for Nexus Repository” (Sonatype’s Artifactory migration page, read 2026-10-23). On your Artifactory virtual repositories it says “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” (Sonatype’s Artifactory migration page, read 2026-10-23).
What the move involves with either server
Your files are one job. The addresses and credentials in your builds are the rest.
- Repositories. List each Artifactory repository by type (local, remote or virtual) and package type, then create a counterpart of the same format on the new server. CloudRepo’s terms page maps an Artifactory local, remote or virtual repository to CloudRepo’s.
- Formats. Check each format you host against what the tool you choose says it moves. CloudRepo’s tested set is in the next section, and Sonatype’s import formats are listed above.
- Credentials in every build. Every build that signs in to Artifactory holds an Artifactory credential, in a file such as
settings.xml,.npmrcorpip.conf, in a CI secret, or in adocker login. Each one needs a credential for the new server. - URLs in every build. The repository address sits in
pom.xml, Gradle scripts,.npmrc,pip.confand Docker image names, and each one changes. - Lockfiles. A lockfile can record the address a package came from. npm’s docs say a
package-lock.jsonentry holds “resolved: The place where the package was actually resolved from. In the case of packages fetched from the registry, this will be a url to a tarball.” (npm’s package-lock.json page, read 2026-10-23). A lockfile written against your Artifactory host still names that host, so search for it with the rest.
For a move to CloudRepo, Change every Nexus and Artifactory URL in your builds, lockfiles included maps Nexus 2, Nexus 3 and Artifactory URLs to CloudRepo’s, shows how to find every one in your builds, and covers regenerating npm, Yarn, Poetry and uv lockfiles. Step 5 of Migrate from JFrog Artifactory shows the files to change for each build tool.
Switch one build at a time, and keep Artifactory up until every build has passed against the new server.
CloudRepo as the other option
CloudRepo hosts Maven, npm, Python (PyPI) and Docker/OCI repositories, and plans start at $99/month billed annually. Each self-serve plan starts with a 14-day free trial. JFrog lists its plans on its pricing page, Sonatype lists its Nexus Repository plans on its pricing page (both read 2026-10-23), and ours are on our pricing page.
cloudrepo-migrate artifactory moves an Artifactory server’s local Maven repositories and reads each file back from CloudRepo to check it, and it has been tested against a real Artifactory server for local Maven repositories. Copy other formats with the commands you already use.
Install it, then do a dry run, which lists what would move and uploads nothing.
pipx install cloudrepo-migratecloudrepo-migrate artifactory --artifactory-url https://artifactory.example.com/artifactory --org your-org --dry-runRun the same command without --dry-run to move the repositories. The source is only read, never written. It reads your Artifactory token from ARTIFACTORY_ACCESS_TOKEN and your CloudRepo token from CLOUDREPO_TOKEN: set them in your shell, never on the command line.
Create each target repository in CloudRepo first, with the same format as its Artifactory repository, and a repository token that can write to it. The Artifactory migration guide has the steps. The run’s report lists every repository moved and every one skipped, with the reason.
Every Sonatype, JFrog and npm page this article cites was read on 2026-10-23. Vendors change their documentation, so check each page before you decide.