Migrate from JFrog Artifactory to Pulp

Start by inventorying what sits in Artifactory before moving anything, because hosted artifacts and remote definitions travel by different paths. Hosted content (the Maven, npm and Python packages your teams published into local repositories) can be downloaded with the JFrog CLI command jf rt download, which is also available as jf rt dl. The command accepts wildcard patterns or JSON file specs, verifies checksums by default and keeps the repository folder hierarchy unless --flat is set. Keep the hierarchy for migration so that Maven group and artifact paths and npm tarball names stay recognizable when you upload them into Pulp. Run the download against a test repository first and compare file counts and checksums with the source.

Remote definitions are not files, so they do not come out with the download. Capture each remote's URL, package type and any credentials from the Artifactory repository configuration, either through the Artifactory UI or the REST API. Record which upstreams each remote points at, such as Maven Central or registry.npmjs.org, and whether it uses a proxy or stored credentials. Those credentials are secrets, so move them into your secrets manager rather than a spreadsheet. Internal npm packages are different again: once you have the tarballs, republish them into the Pulp npm repository with npm publish or yarn publish, using a token issued by Pulp. Confirm which package metadata, such as versions and dist-tags, you need to preserve.

Export options differ between SaaS and self-managed deployments, so confirm your tier's capabilities with JFrog before you plan the cutover. Ask whether your subscription includes system or repository export, what metadata it carries, and whether your deployment is in scope for those features. If the export tooling is not available to you, the CLI and REST API download path described above is the fallback, and it will not carry permissions, properties or build information. Write those gaps into the migration plan and decide who will recreate access rules in Pulp. Note also that Pulp's Maven deploy path does not use authentication, so the republish step needs its own access control design.

Once the packages are in Pulp, every client request runs through three services that you size and scale separately: pulpcore-api, a Django REST application served by gunicorn that handles uploads, remote and repository configuration and the REST API at /pulp/api/v3/; pulpcore-content, an aiohttp server that answers the Maven, npm and Python download requests from your build tools; and pulpcore-worker processes that run the sync, publish and cleanup tasks. All three rely on PostgreSQL as the single source of truth for tasks, so the database is the component most likely to become a shared bottleneck, and it needs its own sizing, backup and failover plan. Pulp documents that each service scales horizontally for high availability, but the number of workers and content replicas that your traffic needs is something to measure in a pilot, not assume.

Pulp's pull-through model works differently from Artifactory's remote repositories. A pulp_maven or pulp_npm remote points at the original upstream, such as Maven Central or registry.npmjs.org, and content is cached on first request. Your clients never talk to the upstream directly, but the first fetch of each artifact still depends on upstream availability, so confirm how your builds behave during an upstream outage. Before cutover, decide which internal packages are published with npm publish or the Maven Deploy Plugin into hosted repositories, and remember that the Maven deploy path does not authenticate and does not separate SNAPSHOT and release repositories, so access control has to sit in front of Pulp.

Content reaches clients through a distribution. After a sync or upload creates a repository version, a publish step produces the metadata that a client needs, and a distribution maps a base path to that publication so that clients resolve it as a normal repository URL. Plan one distribution per repository you migrated and test that a version rollback is visible to clients. Storage is the other sizing decision: artifacts and published content live in the backend you configure, so choose between local filesystem and object storage before loading data, and confirm the options in the Pulp storage configuration guide. Ask your team to estimate artifact volume from the Artifactory storage report, then size object storage and database growth from that figure.

A DeployOpen engagement for this migration starts with a written scope that names the Artifactory repositories in question, the Pulp plugins that will serve them, the upstreams each remote will point at, and the cutover window agreed with your teams. Work begins only after that scope, its deliverables and its timeline are confirmed in writing. The first working phase is an inventory: every local, remote and virtual repository, its package type, its download volume and the consumers that pull from it, including CI jobs, build agents and developer machines that hold repository URLs in configuration files such as settings.xml or .npmrc.

From that inventory, DeployOpen builds Pulp remotes for Maven, npm and Python content against the original upstreams, then tests each one with the same package requests your builds make today. Maven remotes are checked against the deploy behavior documented for pulp_maven, since that deploy path does not use authentication and does not separate SNAPSHOT and release repositories. Your security team should decide in advance how those gaps are handled, whether through network controls, a separate publish path or a different internal workflow. Each plugin's maturity is also checked against the version your team has approved.

During the parallel period, builds can point at both systems while the team compares checksums and resolution results. DeployOpen supports the cutover itself, including repointing build configuration and rolling back if a consumer fails. Ongoing support, upgrades and recurring testing are available as a retainer, which is usually the right choice for teams that will run Pulp without a dedicated plugin maintainer. Ask any provider to confirm the response terms, upgrade approach and who holds administrator access in your environment before signing.