Phase 3: Artifact migration

Migrating artifacts from JFrog Artifactory

Moving from Artifactory covers two areas: migrating your existing artifacts, and reconfiguring your CI/CD pipelines so delivery continues throughout. For the strategies behind the artifact side, and how to choose between them, see Migrating your artifacts. This page covers getting the artifacts out.

What to migrate

Only local repositories hold artifacts that need moving. Remote and virtual repositories are configuration, and are recreated in Cloudsmith rather than exported.

See Configuring legacy platforms as upstreams if you want Cloudsmith to fetch from Artifactory itself during the transition.

Bulk migration run by the Cloudsmith team

Bulk artifact migration at scale is carried out by the Cloudsmith team on your behalf. Our onboarding and support engineers draw on a range of internal tooling to automate the key steps: indexing your existing repositories, transferring artifacts, migrating subsequent deltas, and verifying what arrived. They work with your Artifactory environment whether that is a single instance or part of a larger deployment.

What you provide:

• Administrative access via an Artifactory admin token
• Network permissions for connectivity between Artifactory and Cloudsmith, see Configuring legacy platforms as upstreams
• The set of repositories to migrate, and how they map to your Cloudsmith repositories
• A schedule, including how often deltas should be migrated after the first pass

What to expect:

• A kick-off where the repository mapping, schedule, and success criteria are agreed.
• A first pass that indexes and transfers every mapped repository, followed by delta passes on the agreed cadence so artifacts published to Artifactory after the first pass are picked up too.
• A count per repository of what was found, what was transferred, and what could not be, after each pass. You can run the same checks yourself; see Verify the import.
• A final pass and sign-off before you cut CI/CD over, as described in Phase 4: Validation and decommissioning.

Exporting artifacts yourself

Artifactory can export a repository through its UI, which writes the repository's files to a folder on the server. See Import and export in the Artifactory documentation. For more control, or to export from a machine that is not the server, the JFrog CLI downloads by repository, path, or pattern:

jf rt download "npm-local/" ./export/npm-local/

See Downloading files for patterns, exclusions, and threading, and Configurations for connecting the CLI to your instance. Before you start, read Running a bulk import.

What matters for the Cloudsmith side:

• Keep the repository's path layout. The default download does. The Maven import pairs POMs with their JARs by path, and the folder script searches subfolders, so --flat is unnecessary. If you do use it, files with the same name from different paths are kept as name (1).tgz, name (2).tgz, and each is pushed as a separate upload.

• Expect files that are not packages. Exports carry checksum sidecars and, for Debian and RPM, generated dists/ and repodata/ trees. The import scripts filter by extension, so these are skipped as long as you pass one.

• Record the file count before exporting, so you can compare it with what lands in Cloudsmith during verification:

  shell

  jf rt search "npm-local/*.tgz" --count

• Properties do not travel. Artifactory properties are not part of the exported file. If you rely on them, see custom metadata for the Cloudsmith equivalent, and plan to set it after import.

Next steps

With your artifacts exported, publish them to Cloudsmith with Importing packages with the CLI, or Importing Docker images for Docker repositories, which need no export.

Updated 1 minute ago