Artifactory self-managed end of life: upgrade or replace

Replace Artifactory or upgrade it before the 7.111.x end of life date?

The decision depends on which formats your 7.111.x estate hosts. Container images and Helm charts have a clear path to self-hosted Harbor, while Maven, npm, Python, RPM and Debian content may fit Pulp, and every other format needs a check before you commit. JFrog supports each self-managed Artifactory minor version for 18 months, so 7.111.x reaches end of life on October 23, 2026. That date comes from a vendor support policy, and no regulation requires you to move on it. The practical risk is running an unsupported server that falls outside vendor fixes, which your security team and assessors will ask about. Confirm the date and any paid extended support terms with JFrog before you plan around them.

The short answer is that Harbor can take Docker and Helm content. Harbor stores images and charts as OCI artifacts, since v2.8.0 dropped ChartMuseum, and its latest stable line, v2.15.4, was published on October 9, 2026. Pulp can take some package formats: pulp_rpm, pulp_python, pulp_container and pulp_deb are past version 1.0, while pulp_maven and pulp_npm are still 0.x releases. Formats such as Gem and Rust need confirmation against the specific plugin, because pulp_rust is a tech preview whose APIs may change. If most of your estate sits in formats without a mature replacement, another upgrade cycle buys time, but it does not resolve the architecture question.

Start with an inventory of what the 7.111.x instance serves, by format and by repository type (hosted, remote or virtual). Container and Helm repositories are the lowest-risk first move, so Harbor is the natural place to test while Artifactory keeps serving traffic. Plan for Harbor's own upgrade work too: v2.15.2 migrates the bundled database from PostgreSQL 15 to PostgreSQL 18 on container startup and recommends a backup first, and v2.15.3 blocks webhooks to internal network addresses by default. For each format where the Pulp plugin is still 0.x or in tech preview, decide whether upgrading Artifactory to a supported line is the cheaper bridge. Ask JFrog to confirm the supported upgrade path from 7.111.x in writing before you set a cutover date.

What a support deadline forces you to decide

A support end date turns a routine upgrade into a decision about what the registry must do for the next several years. The five requirements below cover version support, OCI conformance, package coverage, access control and recovery, and each one applies whether you upgrade Artifactory or move content to Harbor and Pulp.

A supported version path

Confirm which Artifactory minor version you will run after the current one reaches end of life, and how many upgrade steps the move requires. Each self-managed minor version receives support for 18 months, so an upgrade now buys a fixed window before the next decision. For Harbor, check the release line you plan to adopt: the latest stable release is v2.15.4, and older lines such as 2.14 and 2.13 still receive patch releases. Ask JFrog and the Harbor maintainers how long each line stays supported.

Registry API conformance

Test whether the replacement speaks the OCI Distribution Specification, which requires pull support and defines pull, push, content discovery and content management APIs. Check the referrers API as well, since signatures and SBOMs attached to images depend on it. Harbor's repository runs the OCI distribution conformance tests in its CI, but you should still run the conformance suite against your own deployment and against the clients your build and cluster tooling use.

Package format coverage

List every package type your teams pull today, not only Docker and Helm. Artifactory natively supports more than 60 package types and technologies, while Harbor handles container images and Helm charts only. Pulp covers Maven, npm, Python, RPM, Debian and other formats through plugins, but several plugins are still 0.x or tech preview. Any format without a mature replacement needs its own owner and its own cutover plan.

Identity and access controls

Map every Artifactory group, permission target and token your pipelines use to a role in the replacement. Harbor provides projects with role-based access control, LDAP/AD and OIDC single sign-on, and audit logs. Pulp exposes its controls through the REST API, and its Maven deploy feature does not use authentication, so that path needs compensating controls. Confirm with each platform whether service accounts and robot credentials cover your CI needs.

Backup and rollback plan

Plan how you restore the registry if an upgrade or migration fails, and test the restore before cutover. Harbor v2.15.2 upgrades its bundled PostgreSQL from version 15 to 18 on container startup, and its release notes recommend a backup before upgrading. Keep Artifactory and the replacement running in parallel until your team has rehearsed rollback, and record which clients point at which registry at each stage.

Vulnerability scanning and review

Decide which scanner gates images before they reach production. Harbor uses the open-source Trivy scanner when installed with the --with-trivy option, and it can connect to an external Trivy instance or other scanners. Compare findings coverage with what your current Xray or scanning policy enforces, and confirm how exceptions and approvals will be recorded for your auditors.

Which path fits your format mix

Staying on Artifactory keeps every format, the federation and the Xray-based scanning your teams already use, and avoids changing registry endpoints and credentials across CI, clusters and developer machines. The cost is another upgrade cycle on a fixed clock. The 7.111.x line reaches end of life on October 23, 2026, and each self-managed minor version receives 18 months of support, so the question is how many cycles you want to fund over the coming years.

Full format coverage: JFrog's pricing page states that Artifactory natively supports more than 60 package types and technologies, so no format has to be rebuilt.
Scanning gap to close: Xray-style scanning and curation sit in higher tiers or add-on bundles. Trivy inside Harbor does not replace them one for one, so document what your security team depends on today.
Upgrade path: confirm with JFrog the supported target minor version, the upgrade steps from your current release and whether your license tier covers the version you move to.
Deployment model: self-managed customers schedule an internal change window, while SaaS customers have the platform maintained by JFrog under the consumption model already in place.
Staging test: restore a production-sized copy of key repositories into a staging instance and run your real pipelines against it before scheduling the change.

Get the supported versions, tier entitlements and upgrade documentation from JFrog in writing before you commit a change window.

What another Artifactory upgrade cycle buys and costs

Staying on self-managed Artifactory keeps the workflow your teams already know, along with its universal repository model and the integrations built around it. JFrog says Artifactory natively supports more than 60 package types and technologies, which is the breadth that a Harbor and Pulp split has to match format by format. An upgrade cycle preserves that coverage, existing repository layouts, CI credentials and access rules without a rebuild. The cost is that each upgrade is set by a support clock rather than by your own roadmap. With 7.111.x reaching end of life on October 23, 2026, the decision is not whether to upgrade once, but whether you want to sign up for the next cycle on the same schedule.

Before committing, confirm three things with JFrog and your own team. First, the target minor version and its support window, since the 18-month policy applies per minor line. Second, the testing effort: list every remote and virtual repository, custom plugin, webhook, reverse proxy rule and CI pipeline that touches Artifactory, then run the upgrade against a copy of production metadata and storage. Third, the licence tier, because self-managed pricing is by server count, so high availability nodes, disaster recovery sites and non-production instances may all be billed. Ask for the written quote to show how each server is counted and whether the price changes if you add nodes later.

Record the answers in one table: upgrade work per cycle, number of servers in scope, and recurring subscription cost. Compare that recurring line with the one-time migration effort and the ongoing cost of operating Harbor and Pulp, including the staff who will own them. The upgrade path is cheaper to decide quickly when the next cycle is only a few months away, but a planned exit gives you more time to test. Review the Harbor release notes and Pulp plugin maturity before you choose, since a container-only move may leave non-container formats on Artifactory for longer.

How to cut over without breaking CI and cluster pulls

This sequence moves container and package traffic from Artifactory to Harbor and Pulp in an order that keeps builds and cluster pulls working, with a rollback path until Artifactory is retired after a backup.

Inventory repositories by format and consumer
Platform engineering lists every Artifactory local, remote and virtual repository, its package format, its upstream source and which CI pipelines, clusters and developer machines pull from or push to it. Record image pull secrets, CI service credentials and webhook targets alongside each repository. The step is done when every repository has one owner, one target (Harbor or Pulp) and a named list of consumers, so nothing is cut over by guesswork.
Confirm Pulp plugin maturity for each format
For each non-container format, the team checks the Pulp plugin's release maturity against its own usage. Plugins past version 1.0 and plugins still in 0.x or tech preview carry different stability expectations, and Rust and Cargo support is a tech preview with authentication and full registry syncing not yet supported. Any format without a suitable plugin stays on Artifactory or moves to another tool. Confirm these details with the plugin maintainers and in your own test environment before you commit.
Deploy Harbor and Pulp under the chosen HA model
Platform engineers install Harbor and Pulp in your infrastructure using the high availability model your team selected, and they take a backup of the Harbor database before any upgrade, as the Harbor v2.15.2 release notes recommend. Pulp runs its API, content and worker services as separate components, so scaling and failover are planned per component. The step is done when both services pass health checks, storage and backup jobs run, and a test image and test package can be pushed and pulled.
Replicate and sync content from Artifactory
For Docker and Helm content, the team registers Artifactory as a Harbor replication endpoint and creates pull-based replication rules filtered by repository and tag. For packages, Pulp remotes point at the original upstreams and hosted artifacts are uploaded from Artifactory through the JFrog CLI or REST API. Bandwidth limits and schedules are set so replication does not slow production. The step is done when replicated item counts match the inventory and spot checks of digests and checksums agree.
Run proxy cache during cutover
Harbor proxy cache projects are created for upstream registries and pointed at Artifactory during the transition, so a pull that Harbor cannot serve from its own copy still succeeds. Harbor caches serve the cached copy if the upstream is unreachable, which covers short outages during the switch. Monitor cache hit rates and pull errors per consumer. The step is done when no consumer depends on a direct Artifactory address and error rates return to baseline.
Repoint CI credentials and image pull secrets
Pipeline owners update CI registry credentials, Helm repository references and Kubernetes image pull secrets to the Harbor or Pulp endpoints, one environment at a time, starting with non-production clusters. Helm charts use oci:// references in Harbor. Each change is recorded so it can be reverted. The step is done when a build, a deployment and a node pull succeed in every environment and no workload still references the Artifactory hostname.
Retire Artifactory after a verified backup
Before shutdown, the team takes a final backup of the Artifactory instance and confirms it can be restored in a test environment. Read-only mode is enabled for a defined observation period agreed with stakeholders, then the instance is decommissioned and its licenses and access are removed. Ask your JFrog contract owner which data export and termination terms apply to your subscription. The step is done when the restore test passes, owners sign off and the decommission record is filed.

Evidence to keep for the decision and the cutover

A replace-or-upgrade decision is only defensible if its dates, inventory and controls are written down before anything moves. The six items below connect the decision record to the evidence an auditor or CISO will ask for once Harbor or Pulp is running alongside Artifactory.

Upgrade or retirement decision record

Record the current Artifactory version, its support end date of October 23, 2026 for the 7.111.x line, the options considered, the owner who signed off and the date of each decision. Include the reason for choosing another upgrade cycle or moving containers to Harbor and packages to Pulp. Revisit the record if the vendor's support dates or your scope change. Ask JFrog to confirm the end-of-life date for your exact deployment.

Format and repository inventory

List every repository by package type, whether it is local, remote or virtual, its upstream, its consumers and its owner. Mark which formats Harbor covers (OCI images and Helm charts) and which need Pulp or another tool. Gaps such as Maven deploy authentication or tech-preview plugins belong in this inventory with a named owner for each.

Replication and sync logs

Keep the replication rule definitions, trigger settings and run logs from each Harbor replication or Pulp sync, along with the Skopeo copy records used for air-gapped transfers. Compare object counts and digests between source and target for a sample of artifacts. These logs show whether content moved completely, which an auditor may test by sampling.

Vulnerability scan configuration

Document which scanner runs in Harbor, how it was enabled at install time, its scan-on-push settings and the scanner version bundled with the release you deploy. Record the policy that blocks or flags vulnerable images and who reviews the findings. Confirm whether the scanning covers all projects and what coverage Pulp provides for non-container content.

Access control and audit log settings

Export the role assignments, SSO configuration (LDAP/AD or OIDC), service account inventory and audit log retention settings for each new registry. Map who can push, pull and delete in each project to the access model in Artifactory. Auditors commonly test whether privileged accounts are reviewed on a schedule, so store that review record with these settings.

Restore test results

Keep dated results from restoring the Harbor database and object storage, and the Pulp PostgreSQL database and content store, into a separate environment. Record what was restored, how long it took and which artifacts were verified by digest. Note that DeployOpen prepares this evidence and the control conclusions come from your independent auditors or certification bodies, not from DeployOpen.

What does replacing Artifactory cost and take?

How is the cost of replacing Artifactory split between components?

Replacement cost has five parts: servers, object storage, databases, upgrades and engineering time. The software licenses are zero for Harbor and Pulp, but the infrastructure and people are not. Commercial terms differ by deployment model. JFrog's pricing page describes SaaS consumption billing that counts storage plus data transfer against 25 GB included on its Pro plan, while its self-managed editions are priced by server count. Sonatype's pricing page uses a similar consumption model for Nexus Repository Cloud Pro. Ask JFrog for the current per-server quote for your topology, then compare it against your own servers, storage growth, PostgreSQL and Valkey hosting, backup storage and the staff hours to run upgrades. Infrastructure costs are recurring. Migration and build work are mostly one-time.

Does a price quote follow from a written scope?

Yes. DeployOpen does not publish a price list, and a quote follows from a written scope agreed before work starts. Most engagements are fixed-scope, so the scope document lists the repositories and package formats in use, the number of environments, the upstream sources to proxy, the identity integration, the high availability target, the backup and recovery approach and the cutover window. Each of these items moves the effort up or down. Packages that need a Pulp plugin still at 0.x, or a tech-preview feature, usually add validation and documentation work. Ask for deliverables, timelines and exclusions in writing so you can compare quotes on the same basis.

How long does an Artifactory cutover take, and what drives it?

The duration depends on the scope, not on a fixed rule. The main drivers are the volume of stored images and packages, the number of CI pipelines and Kubernetes clusters that pull from the registry, the number of non-container formats that need rebuilding in Pulp, and whether you run a parallel period. Harbor replication can run on a cron schedule or on push events and can be bandwidth-limited, so large initial syncs take longer than incremental ones. Credential changes in CI systems and image pull secrets in clusters often take more calendar time than the data copy. DeployOpen does not quote a duration before the scope is written. Ask any vendor for a timeline tied to the volumes and pipelines you list.

What must our team provide before a Harbor and Pulp project starts?

Your team provides access, inventory and decisions. Expect to supply:

An inventory of repositories, formats, tags, retention rules and users, exported from Artifactory with the JFrog CLI or REST API
Cloud or data center accounts, networks, DNS, certificates and storage backends where Harbor and Pulp will run
Identity provider details for LDAP, AD or OIDC single sign-on
Named owners for CI pipelines, Kubernetes clusters and any external consumers of packages
Decisions on proxy cache scope, vulnerability scanning with Trivy, and the high availability target

Without this inventory, cutover work is guesswork. Confirm the exact list of inputs in the written scope.

Can our own team replace Artifactory without a partner?

A team with container platform and package management experience can do it in-house, and many do. The work includes deploying Harbor and Pulp with PostgreSQL and object storage, configuring replication and proxy cache projects, rebuilding Maven, npm and Python repositories in Pulp, testing every pipeline, and running upgrades on a schedule. Harbor's 2.15.x releases bring database and cache changes, and 2.15.3 introduced breaking changes to webhooks and content trust, so upgrade testing matters. Pulp's pulp_rust plugin is a tech preview, and pulp_maven deploy does not use authentication. Assess whether your staff can own these components for years, not only for the cutover. Ongoing support, upgrades and continuous testing are available as DeployOpen retainers.

Is upgrading Artifactory cheaper than migrating to Harbor and Pulp?

It depends on what you run and how long you need to run it. An upgrade keeps your current workflows, pipelines and licensing, and it avoids a cutover. It also means another upgrade cycle, because JFrog supports each self-managed minor version for 18 months, and 7.111.x reaches end of life on October 23, 2026. A migration removes the per-server subscription, but it adds one-time build work and a permanent operations burden for Harbor and Pulp. Compare the next two or three years: subscription and upgrade effort on one side, infrastructure, staff time and migration work on the other. Include the formats you would rebuild in Pulp and any JFrog features, such as Xray, federation or curation, that you would need to replace or accept losing.

What hidden costs should we budget for beyond licenses?

Four costs are often missed. First, high availability: Harbor and Pulp each scale horizontally, so plan for redundant API, content and worker components plus a highly available PostgreSQL service. Second, backups: Harbor's 2.15.2 release notes recommend a backup before upgrading, and object storage needs its own retention. Third, security scanning: Harbor's Trivy scanning is open source, but findings still need triage, and JFrog Xray's curation and license-policy features have no direct open-source match. Fourth, upstream rate limits and egress: Docker Hub limits unauthenticated pulls to 100 per 6 hours per IPv4 address or IPv6 /64 subnet, so proxy caching has value, and egress from cloud storage still bills. Confirm each cost in your environment before you compare totals.

What does DeployOpen cover in a replacement engagement?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For this change, that can include planning the cutover, deploying Harbor and Pulp, setting up replication and proxy cache projects, repointing CI and cluster credentials, preparing documentation, and supporting operations afterward through a retainer. DeployOpen does not issue audit reports, attestations or certifications, so compliance evidence still goes to independent auditors. Scope, deliverables and timelines are agreed in writing before work starts.

How to decide before the support date

Start by sorting your estate by format, because that decides the path. If most of what Artifactory serves is formats it handles well and your teams need its features now, upgrade within the 7.111.x line or move to the next supported minor version and plan the migration on your own timeline. If OCI content dominates, meaning container images and Helm charts, move those to Harbor. Harbor stores Helm charts as OCI artifacts and has run that way since v2.8.0, so Helm does not need a separate chart server. Confirm which Harbor line you will run: v2.15.4 was the latest stable release at the time of writing, and v2.15.2 changed the bundled database to PostgreSQL 18 and the cache to Valkey, so test the upgrade path before you commit.

Move packages to Pulp only after you check each format against its plugin maturity. The Pulp plugins for RPM, Python, container and Debian are past 1.0, while Maven, npm, Gem, Hugging Face and Ansible are still 0.x, and Rust is a tech preview. Write down every package type in your Artifactory inventory, map it to a Pulp plugin, and record the version you tested. Any format without a mature plugin needs a named owner who accepts the risk, or it stays on a supported Artifactory version. Also check authentication needs: the pulp_maven deploy feature does not use authentication, which is a blocker for many internal teams.

Federation, Xray and curation have no direct open-source match, so decide now whether each one is required. Harbor's Trivy scanning and Pulp's tech-preview vulnerability reports replace some scanning, but they do not replace Xray's policy engine, and nothing in the supplied material replaces curation or multi-site federation. For each feature, either add its cost to the budget (commercial licences, a second scanning product or engineering effort) or drop it with sign-off from the people who depend on it. Ask JFrog in writing which features your current tier includes and what the renewal terms are, so the comparison rests on your contract rather than on assumptions.

How DeployOpen runs a registry move under a support deadline

DeployOpen plans, implements, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For an Artifactory self-managed end of life decision, we start by mapping which content and which support window actually drive the timeline, then build and document the target in your environment.

How we scope

We inventory which Artifactory repositories hold Docker images, Helm charts and other package types before comparing targets.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work starts.
The written scope names the upgrade path or replacement path, the cutover window and each content type in or out of scope.

How we build

We deploy the target registry in your environment, wired to your identity provider, storage and network controls.
We test pull, push and replication paths against the CI jobs and Kubernetes clusters that depend on them.
We run security testing on the new registry, including image scanning configuration, before any credentials are repointed.

How we hand over

You receive configuration, runbooks, backup and restore procedures and an inventory of migrated repositories.
We document each control and the evidence it produces so your internal or external assessors can review it.
Handover sessions walk your platform team through upgrades, garbage collection and day-to-day administration.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainers can cover tracking of upstream release notes and patch releases for the components we deployed.
Ask any provider to confirm in writing which versions, support windows and breaking changes their quote covers.