--- title: "Cloudsmith | Migrate to Cloudsmith" description: "Every migration is different, and documentation alone only gets you so far. We’re your partners before, during, and after migration. " canonical_url: "https://cloudsmith.com/switch/migrate-to-cloudsmith" last_updated: "2026-10-16T12:35:27Z" --- # Cloudsmith | Migrate to Cloudsmith Move to a unified, secure artifact management platform ## **Enterprise migration** to Cloudsmith - 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 [Book a migration consultation](/book-a-migration-consultation) ## 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 problem | Cloudsmith solution | | --- | --- | | Migration feels risky. Registry endpoints appear in pipelines, developer tools, and production environments, and teams worry about disruption. | Move 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. | | Large 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. | The 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. | | Developers should not have to relearn their tools. A new platform often means new workflows and new habits. | Developers keep their tools. Same formats, native tooling. Each format keeps its native package manager tooling. The core change is the registry endpoint. | | It is unclear what moves and what does not. Surprises late in a migration are the expensive ones. | A 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 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 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 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 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. [Browse case studies](https://docs.cloudsmith.com/migrating-to-cloudsmith/case-studies) [View all migration docs](https://docs.cloudsmith.com/migrating-to-cloudsmith) 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. 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 ### Do my developers have to change how they work? 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. ### What happens to our pipelines during the migration? 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. ### Do we have to migrate everything? 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. ### What do we need to get started? 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. ### Can Cloudsmith pull from our current repository without moving everything first? 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. ### What if we need to go back? 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. ### Who does the work? 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. [Book a consultation](/book-a-migration-consultation) [Plans and pricing](/pricing)