Move to a unified, secure artifact management platform

Enterprise migration to Cloudsmith

Every migration is different, and documentation alone only gets you so far. We’re your partners before, during, and after migration.

  • Migration consultations: a bespoke plan built around your estate, timelines, and constraints
  • Customer Success: guidance from kick-off to validation
  • Engineering support: experts on hand whenever you need them
  • Dedicated Slack channel

A migration to Cloudsmith is a joint project

Your team decides the scope, the pace, and how repositories are organized. Cloudsmith's Customer Success team provides the plan, the tooling, and hands-on guidance from the first workshop to the final cutover.
The problemMigration feels risky. Registry endpoints appear in pipelines, developer tools, and production environments, and teams worry about disruption.
Cloudsmith solutionMove in steps. Almost every migration starts with one extra publish step in CI. New builds land in Cloudsmith from day one while existing artifacts follow on your timeline.
The problemLarge estates are heavy to move. More than a handful of repositories, or more than a few hundred gigabytes, is a lot to move by hand.
Cloudsmith solutionThe Cloudsmith team runs the transfer. For a large Artifactory estate, the team runs the bulk transfer with an admin token. For other sources, the CLI and API handle bulk upload.
The problemDevelopers should not have to relearn their tools. A new platform often means new workflows and new habits.
Cloudsmith solutionDevelopers keep their tools. Same formats, native tooling. Each format keeps its native package manager tooling. The core change is the registry endpoint.
The problemIt is unclear what moves and what does not. Surprises late in a migration are the expensive ones.
Cloudsmith solutionA clear list before you start. Package files, names, versions, and checksums migrate intact. Users, groups, and permissions are recreated. Platform-specific metadata, build info, and plugins do not transfer.

How your migration works

What moves, what stays the same, and where you’ll be when it’s done.

One home for every artifact

Packages and container images from different tools move into multiformat repositories.
  • Each format keeps its native package manager tooling, so developers keep working the way they do now.
  • Repositories are flat and format-agnostic. You organize them by team, service, language, or environment instead of by nested folders.

Pipelines that keep running while you move

A phased roll-out approach assures minimal disruption to teams or builds.
  • Dual-publishing sends every build to both registries.
  • A registry proxy lets release pipelines keep pulling through your current platform while Cloudsmith becomes the source of truth.
  • Just-in-time upstreams let Cloudsmith fetch from the old repository on demand.

Access you control

SAML single sign-on with group mapping provisions users and roles. Teams and individuals get global or repository-specific privileges.
  • Service accounts and OIDC authenticate pipelines, so no long-lived API key sits in CI as a secret and there is no key to rotate. Geo and IP restrictions, and entitlement tokens for partners and customers, are there when you need them.
  • Access controls you configure during migration: SAML single sign-on, group mapping, teams and roles, service accounts, OIDC for CI/CD, geo and IP restrictions, entitlement tokens, and EULAs for downloads.

One unified, secure environment when you finish

Cloudsmith sits between public registries and your builds. Upstreams fetch and cache third-party dependencies, and policy as code, written in Rego on Open Policy Agent, decides what is allowed through.
  • Every artifact ingested, every pull, every policy decision, and every user action is recorded in an audit trail.
Four phases, one migration team

How we migrate together

We work alongside your team at every stage to deliver a safe, seamless migration.
Phase 1

Project initiation

  • Establish a migration team, guided by Customer Success and led by key stakeholders from your organization
  • Define the scope and objectives of the migration
Phase 2

Discovery and migration planning

  • Build a detailed understanding of your current solution
  • Design a clear target state
  • Develop a migration plan to reach that target
  • Identify key dates, milestones, and risks
Phase 3

Migrating your artifacts

  • Move your artifacts to Cloudsmith incrementally or in bulk, based on your chosen strategy
  • Provision your teams and pipelines with the access they need
  • Test and refine the process
Phase 4

Validation and decommissioning

  • Validate that Cloudsmith is running smoothly for your teams
  • Decommission your previous solution
  • Document any outstanding issues or improvements

Experience helping teams migrate from Artifactory or Nexus

We’ve worked with plenty of organizations to help make the switch from JFrog or Sonatype seamless.
    JFrog Artifactory
    The Cloudsmith Migration Toolkit connects to your Artifactory environment, whether it is one instance or a larger deployment, and automates the transfer of packages. It needs an Artifactory admin token and network access to the instance.
    Sonatype Nexus
    You can configure Cloudsmith upstreams or export key packages for bulk upload. Many customers publish new builds to Cloudsmith while Nexus serves consumers through a remote repository pointed at Cloudsmith.

Migration case studies

Browse migrations by company profile and incumbent platform to find a case study that resembles your migration.

Repository design

Design your repositories to meet your organization's needs

Cloudsmith's multi-format repository structures allow you a great deal of flexibility in how you set up your teams.
Good for
Trade-off
Single repository
Good for
Simple setup and centralization.
Trade-off
Limited isolation and no fine-grained controls.
Language-specific
Good for
Clear organization, isolated package types, familiarity from other tools.
Trade-off
More repositories and lower central visibility of usage, licenses, vulnerabilities, and logs.
Service, product, or team
Good for
Team ownership, granular access, multiformat flexibility, better visibility.
Trade-off
More repositories and some package duplication.
Environment-based
Good for
Automated promotion across development, staging, and production.
Trade-off
Some added promotion complexity.
Hybrid
Good for
Combines environment-based repositories with service, product, or team repositories.
Trade-off
Carries the trade-offs of both.

Also configured during migration: upstreams for third-party sources such as NuGet Gallery, RubyGems.org, and Maven Central; log export to S3 for auditing; signing keys for package authenticity; and custom domains so you can distribute packages under your own brand.

Configured during your migration

Multiformat repositories

Packages and containers in one repository, with native tooling kept.

Upstreams

Fetch and cache third-party dependencies.

Policy as code

Rules written in Rego and enforced at the repository.

SSO and group mapping

SAML sign-in with user provisioning and role assignment.

Service accounts and OIDC

Pipeline access with fine-grained permissions and short-lived tokens.

Signing keys

Sign packages with Cloudsmith's key or a custom key you supply.

Log export

Export logs to S3 for auditing.

Custom domains

Distribute packages under your own brand.

Frequently asked questions

  1. The package format stays the same. Developers authenticate to Cloudsmith and point their tools at the new registry path. The rollout includes documentation and instructions so they can configure their environments quickly and correctly.

  2. It depends on the strategy. With dual-publishing, builds publish to both registries until you switch. With a registry proxy, release pipelines keep pulling through your current platform. For Artifactory, existing CD pipelines keep working through a remote repository until you cut them over.

  3. No. A greenfield migration starts fresh in Cloudsmith and brings over only what you choose. A brownfield migration moves existing repositories, artifacts, and configuration. Unused or outdated artifacts can stay behind in either case, and you can onboard users in waves.

  4. A Cloudsmith account with the right access privileges, a way to authenticate requests (basic auth, an API key or token, or OIDC), and the repository URLs you push to and pull from.

  5. Yes. A just-in-time upstream lets Cloudsmith fetch packages from your existing repository on demand. The existing repository must be reachable over the internet.

  6. The decommissioning checklist includes a documented and reviewed rollback plan. It also has you confirm that artifact transactions flow through Cloudsmith and that no critical dependency remains on the old system before you shut it down.

  7. A joint team. Your side brings DevOps, developers, release managers, security and compliance, and project management. Cloudsmith's Customer Success team guides the project from kick-off through validation.

Talk to us about your migration

In a consultation, you and Cloudsmith's migration experts go through your current setup, dependencies, and access patterns, and leave with a plan built around them.