Documentation
Migrating to Cloudsmith
Migrating to Cloudsmith from your current solution is realistic and achievable. Organizations of every size have moved their packages, containers, teams, and pipeline configurations across. This guide describes the key steps involved, drawn from previous customer migrations.
Why migrate from an existing solution?
Many organizations considering a move to Cloudsmith often arrive at the same realization: their existing artifact management solutions are holding them back. Across industries and company sizes, a familiar set of problems consistently surfaces. High operational costs, stemming from complex infrastructure, licensing fees, and the overhead of dedicated support, drain both budgets and bandwidth.
Tooling fragmentation compounds the issue, leading to inconsistent workflows, frustrated developers, and mounting inefficiencies. Security blind spots emerge when visibility is limited, making it nearly impossible to govern what's flowing through your pipelines.
Legacy and self-managed systems also carry an operational cost. Performance issues, particularly around scalability and availability, demand manual intervention to keep the platform running, which is effort spent on infrastructure rather than on the software your teams ship.
Cloudsmith is a managed platform, so that maintenance work disappears, and the Cloudsmith team supports you through the migration itself and afterwards.
Understanding the problem
| Problems with legacy solution | Understanding the problem |
|---|---|
| High costs | Managing your own artifact repositories is costly; including software licensing and server provisioning, dedicated headcount or productivity tradeoffs. |
| Fragmentation | The more fragmented your tooling becomes, the less developers want to use it. Workarounds accumulate and productivity slows. |
| Security blind spots | You can't secure what you can't see. Customers need to be able to get control and visibility over all the software flowing into their teams and pipelines. |
| Performance issues | Scaling a self-managed solution means adding nodes, replicating databases. Getting to high speed, high availability is a constant struggle. |
| Missed opportunities | While you're fighting with your artifact management solution, your competitors are shipping products to customers. Shifting focus to what matters is key. |
| Vendor relationship | Artifact management is critical infrastructure, yet customers often report waiting hours or days for support from their previous vendors. |
Proof of concept
Before beginning a full migration, you might want to do a hands-on trial of Cloudsmith. You will need:
- A Cloudsmith account with the appropriate privileges
- A means to authenticate requests: Basic Auth, an API key or token, or OpenID Connect
- A repository and its URL, whether you're pushing or pulling artifacts
Then you could complete these tasks:
- Create a repository, and add the upstreams you depend on so third-party packages keep resolving.
- Authenticate with Cloudsmith, using an API key to get going, or OpenID Connect for pipelines, which removes key rotation and plaintext secrets entirely.
- Point one project at Cloudsmith by replacing the registry URL in its configuration file, following the setup guide for your format.
- Publish and resolve a package from the command line, your IDE, or the API.
- Do the same in one pipeline, for example GitHub Actions authenticating with OIDC to confirm the change end to end.
The full migration is described in the phases below.
Phases of a typical migration
Phase 1. Project initiation
Assemble the onboarding team, and agree the scope, success criteria, and milestones.
Phase 2. Discovery and migration planning
Document your current state, design the target state and plan your migration in detail.
Phase 3. Migrating your artifacts
Choose a migration strategy and move your packages, containers, pipelines, teams.
Phase 4. Validation and decommissioning
Complete your configuration of Cloudsmith and retire the legacy platform.
Other settings to consider during migration
As part of your move to Cloudsmith, you may want to consider other configuration options:
Endpoints and tooling
- Update your build tools and configurations to push and pull from the new Cloudsmith endpoints. You may have a configuration file for every package format in your code base — you will find instructions on how to set up Cloudsmith for each supported format here.
- Confirm Cloudsmith is reachable from your build infrastructure. See configuring your firewall to accept Cloudsmith and AWS CDN IP ranges.
- Give teams the tooling they will actually use: the command-line interface, the Visual Studio Code extension, and the API bindings.
Identity and access
- Set up single sign-on (SSO) and group mapping if that is how your users will sign in. Cloudsmith supports Okta, Microsoft Entra ID, Google, JumpCloud, OneLogin and Ping Identity.
- Automate joiners, movers and leavers with SCIM provisioning.
- Set up your service accounts for pipelines and automation, and decide your API key rules.
- Decide how access is granted: teams, workspace privileges and per-repository privileges. The permissions guide covers the model end to end.
- Require two-factor authentication for users who do not sign in through SSO.
- Restrict where packages can be pulled from with geo/IP rules.
Dependencies and upstreams
- Set up your upstreams, which will set up Cloudsmith to fetch and cache your third-party dependencies hosted on public repositories like NuGet Gallery, RubyGems.org or Maven Central.
- Where an existing repository is not reachable over the internet, use the upstream proxy agent.
- Decide what you will accept from public sources with upstream trust.
Security and policy
- Set up signing keys so consumers can verify what you publish.
- Turn on vulnerability scanning, malware scanning and malicious package detection.
- Define your vulnerability, license and deny policies, or express them as policy as code.
- Consider block until scan and package quarantine for artifacts that must be held until they are approved.
Distribution
- If you distribute software, set up entitlement tokens for third-party access.
- Enforce an end user license agreement on download where you need one.
- Set up custom domains, so your own brand and domain appear when consumers use native tooling against your Cloudsmith Workspace.
- Tell consumers what has changed with broadcasts.
Observability and housekeeping
- Set up your log exports to S3, or to Azure, and know where to find audit logs and usage.
- Define retention rules so the history you migrate does not grow unchecked.
- Push events into the tools your teams already watch: webhooks, Slack, Microsoft Teams and Datadog.
Infrastructure and data residency
- Choose your storage region if you have data residency requirements.
- Manage repositories, teams and privileges as code with the Terraform provider.
Next steps
See Migration support to talk through your migration with the Cloudsmith team.
