How to export your data from JFrog Artifactory

How to export your data from JFrog Artifactory before the contract ends

Cloud customers cannot use system or repository export, so they download content instead. Self-managed customers can export system data and repositories. JFrog's documentation states that System Import and Export is not available for Artifactory Cloud users and that repository export is limited to non-SaaS users. If you are renewing, facing a pricing change, or working under a data residency requirement, the first step is confirming which deployment model your contract covers, because that decides which export path exists at all. On self-managed Artifactory, a system export covers configuration, security information, stored data and metadata in the same format as a system backup, written to a path on the Artifactory server's local file system. Repository export must be started from the Platform UI, since JFrog's documentation says the REST API does not support exporting a specific repository. Options include metadata, a ZIP archive and a configuration-only export.

For SaaS tenants, the practical route is the JFrog CLI command jf rt download, which copies files using wildcards or JSON file specs, verifies checksums by default and keeps the repository hierarchy unless --flat is set. Docker and Helm content can also be pulled through the Docker registry API, which keeps image manifests and layers intact. Ask JFrog in writing which repositories, custom properties, permission targets and remote repository definitions are included in your export, because downloading files does not recreate configuration, users or access rules. Confirm with JFrog what happens to your data at contract end and what retention window applies. Nothing in this section should be read as a guarantee of completeness for your tenant.

Verification is the step most teams skip. Compare file counts, total size and checksums per repository against the source before you cancel anything, and keep a record of what was checked. Export does not prove that a restored repository works, so test a sample of pulls from the new registry with the same CI credentials and Kubernetes image pull secrets your workloads use. The migration pages cover those cutover steps in detail. Set a date by which you must hold a verified copy, and do not let the subscription lapse before the comparison is signed off.

What you can export from Artifactory and how

This table compares each category of Artifactory data against the deployment that supports it, the export method and where the output lands. Read it first by deployment: JFrog Cloud customers cannot run system or repository export jobs, so their route is downloading content. The main takeaway is that self-managed exports produce server-side files or archives, while Cloud exports depend on what your client can download.

Data type	Deployment that supports it	Export method	Output format or location	Documented limits
System configuration and security data	Self-managed Artifactory only	System export from the administration area	Written to a path on the Artifactory server's local file system, in the same format as a system backup	Not available to Artifactory Cloud users; the output stays on the server, so you must copy it off
Stored binaries	Self-managed Artifactory (as part of system export) and any deployment (as downloads)	System export for the full filestore, or jf rt download for selected content	Server-side export files, or a local directory on your workstation or CI runner	System export is all or nothing; download speed and egress depend on your network and provider
Repository metadata	Self-managed Artifactory	Repository export from the Platform UI with the metadata option	Metadata export written by Artifactory, separate from the binaries it describes	Repository export cannot be started through the REST API; it must be run from the Platform UI
Repository ZIP or configuration-only export	Self-managed Artifactory	Repository export from the Platform UI, choosing the ZIP or configuration-only option	ZIP archive of the repository, or a configuration-only file	Confirm the archive size and format against your repository volume before scheduling
Downloaded files with checksums	Artifactory Cloud and self-managed	jf rt download with wildcards or JSON file specs	Local directory, with the repository hierarchy preserved unless --flat is set	Checksums are verified by default; flat output can overwrite files with the same name
Container images via Docker registry API	Artifactory Cloud and self-managed, where the Docker repository is enabled	Pull images with a Docker client or skopeo through the registry API	Image layers and manifests written to a local image store or copied to another registry	Pulls are limited by your credentials and network; confirm pull permissions for each repository

What does not export and how to work around it

Artifactory's built-in export tools depend on your deployment model, so the export path you can use is set by whether you run JFrog Cloud or a self-managed server. The cards below cover the three gaps that shape the plan and the documented workarounds for each. Confirm the details of every gap with JFrog before you commit to a cutover date.

No system export on Cloud

JFrog's documentation states that System Import and Export is not available for Artifactory Cloud users. A Cloud customer cannot produce a system backup file that carries configuration, security information and stored data to another environment. The practical workaround is to treat the Cloud instance as a source of content and rebuild configuration by hand in the target registry. Document every repository, remote, permission target and user group before you start, because none of that arrives in an export job. Ask JFrog whether a support-assisted copy is available for your contract.

Repository export limited to self-managed

JFrog's documentation says exporting repositories is only available for non-SaaS users. Cloud customers therefore cannot use the repository export option that bundles metadata or a ZIP archive. Download content instead with the JFrog CLI command jf rt download, which copies files using wildcards or JSON file specs, verifies checksums by default and keeps the repository hierarchy unless --flat is set. Run downloads per repository and log the results, because a large repository may need several passes.

REST API cannot export one repository

JFrog's documentation says repository export must be done through the Platform UI because Artifactory does not support the REST API for exporting a specific repository. Scripts that automate the REST API therefore cannot trigger a per-repository export job on any deployment type. For automation, use the REST API or JFrog CLI to list and download artifacts instead. Confirm with JFrog whether the UI export options and their output formats are stable across the Artifactory version you run before you build a pipeline on them.

Pull images through the Docker API

Container images can move without an export job. Pull each image and tag through the Docker registry API that Artifactory exposes for its Docker repositories, then push it to Harbor with a standard client. Pulling by digest keeps the exact image bytes, while pulling by tag may pick up a retagged image. Record the digests for every production tag so you can verify the copy. Images pulled this way carry their layers and manifests, but confirm whether signatures, attestations and any Xray scan results are kept, since those are separate objects.

Items that may not carry over

Some data does not appear in a file download. Confirm with JFrog whether Xray scan data, access tokens, user passwords and API keys carry over in any export mode, and whether they can be migrated at all. Expect to reissue tokens and reset credentials in the target system. List every CI job, Kubernetes image pull secret and build tool that authenticates to Artifactory so you know which credentials must be replaced at cutover.

Verify the copy before cutover

A download is only useful if you can prove it matches the source. Compare checksums of every downloaded file with the values Artifactory reports, and compare image digests between source and target. Keep a manifest of repository names, file counts and total size from the source so the target can be checked against it. Ask JFrog for the retention and deletion policy on the Cloud instance so content is not removed while the copy runs.

Which export path fits your deployment

JFrog's documentation states that System Import and Export is not available for Artifactory Cloud users, and that repository export is only available for non-SaaS users. Cloud customers therefore cannot run an export job that produces a complete backup of configuration and stored data. The practical route is to download content from the repositories you need, using the JFrog CLI or the REST API, and to rebuild configuration on the target side yourself.

Export method: Download files with jf rt download using wildcards or JSON file specs, which verify checksums by default.
Hierarchy: Repository paths are preserved unless you pass --flat, so keep that default if your target registry expects the same layout.
Configuration: Permissions, remote repository definitions and users are not included in a content download and must be recorded manually.
Docker images: Pull images through the Docker registry API so manifests and tags are retrieved as published.
Scope: Large repositories may require scheduled batch downloads, which adds time and transfer cost on your side.

Confirm with your JFrog account team which repositories are in scope and whether any contract terms affect bulk egress before you start downloading.

Sequence for a complete export and verification

This sequence produces a dated, self-contained copy of your Artifactory content, configuration and permission model, along with evidence that each copy matches its source. Run it in order so that every later step can be checked against the inventory you create first.

Inventory repositories and package types
Start by listing every repository in the Artifactory instance, including local, remote and virtual repositories, and the package type each one holds. Record the repository key, package type, approximate item count and storage size from the Artifactory UI or the REST API. Note which repositories are virtual, because they hold no content of their own and point to other repositories. The inventory is complete when every repository key on the instance appears in one table with its type, and someone other than the author has checked it against the Administration view.
Record configuration and permission model
Capture the repository configuration, the permission targets that grant access to each repository, and the users and groups that hold those permissions. For self-managed instances, this record supplements the system export, which includes security information but is easier to review as a separate file. Store the record in a readable format such as a spreadsheet or JSON export. It is complete when you can answer, for any repository, which groups can read it, which can deploy to it and which are administrators.
Export system data or download hosted content
Self-managed customers run a system export, which covers configuration, security information, stored data and metadata in the same format as a system backup. It is written to a path on the Artifactory server's local file system, so confirm free space there first. JFrog Cloud customers cannot use system or repository export, so they download content with the JFrog CLI command jf rt download, which copies files using wildcards or JSON file specs and verifies checksums by default. Confirm the JFrog product documentation for your tier before you start. The step is done when the export files or downloaded directories exist and match the inventory's repository list.
Decide on the --flat option
The jf rt download command preserves the repository hierarchy unless --flat is set, and --flat drops it and places all matched files in one local directory. Keep the hierarchy for a faithful copy, since paths are the basis for later comparison and for re-uploading into another repository. Use --flat only for a specific extract where directory structure is irrelevant, and record that choice in the inventory. The decision is complete when each download command in your runbook shows whether it preserves or flattens paths.
Pull container images through the Docker registry API
Container images are not part of the repository download path, so pull them through the Docker registry API that Artifactory exposes for each Docker repository. Use a dedicated service account with read permission only, and pull each tag and digest you need to keep, listing them from the inventory. Record the digest of every image as it is pulled so that the copy can be verified later. Confirm with JFrog how your deployment exposes its registry endpoints and which tags or manifests your tier and configuration return. The step is done when every image in the inventory has a pulled copy and a recorded digest.
Compare checksums and file counts
For each repository, compare the number of files and the checksums of the downloaded content against the source. The JFrog CLI verifies checksums during download by default, so note any mismatch it reports and rerun the affected specs. For images, compare the recorded manifest digests against those returned by the registry at the time of verification. Investigate any gap in counts before you proceed, because missing items are harder to find after the source changes. The check is complete when every repository shows matching file counts and no unexplained checksum differences.
Store the export with its inventory
Place the exported files, the downloaded content, the image digests, the configuration record and the inventory in one versioned location with restricted access, because the export contains credentials and permission data. Write a short manifest that lists each repository, its checksum summary and the date of the export. Keep the storage encrypted at rest and confirm the retention rules with your compliance owner. The sequence is complete when someone can restore or review any repository from this location using only the stored manifest.

How to verify that the export is complete

An export is complete only when you can show that the destination matches the source, and you should run that comparison before anyone switches off the Artifactory instance. Start with the repository listing: record every local, remote and virtual repository on the source, then confirm that each one has a counterpart in the export or in your rebuild plan. For each local repository, compare file counts and total size, then sample checksums. The JFrog CLI reports checksums on download by default, and the SHA-256 values for a sample of files can be matched against the source with jf rt search output, so keep those listings as evidence. For container content, compare manifest digests for every tag you intend to keep, not only the tag names, because a tag can move while a digest stays fixed.

Record remote repository definitions and virtual aggregation separately, because neither is content and neither appears in a download. A remote repository holds the upstream URL, credentials reference, cache settings and retention rules, and a virtual repository holds the ordered list of members and their resolution order. Export the configuration for each one from the Platform UI or your configuration backup, store it alongside the content checksums, and note which upstreams each remote points to. Confirm with JFrog which of these definitions your chosen export mode includes, since the documentation for self-managed export and repository export describes different scopes. Verify the resolution order of each virtual repository by listing the members in your own environment, because the order is what determines which copy a build receives.

Some checks need JFrog or your Harbor or Pulp team to confirm rather than a local comparison. You can confirm file counts, checksums and digests yourself, but you should ask the vendor whether any system-level metadata, such as properties, permissions, or internal indexes, is carried into an export and whether it is restored on import. Ask the destination owner to run a test pull of each image and package format from a clean client, and to confirm that signatures or SBOMs attached to images are present through the referrers API if your policy depends on them. Keep the comparison output, the signed-off repository inventory and the vendor's written answers together, because an auditor or incident responder will ask for them later.

What to plan before renewal or termination

Export is the last step of a larger exit, and the order of work matters. The cards below cover the decisions and inventories that determine whether content can leave Artifactory cleanly, from timing against the contract end to the platform choice that the export feeds into.

Contract end and export timing

Work backward from the contract end date, not forward from the first export. Confirm with JFrog whether your subscription allows access to the instance after termination and for how long, and whether any read-only period applies. On JFrog Cloud, export means downloading content, which takes longer than a system export on self-managed servers, so start the download inventory early. Ask JFrog to confirm these terms in writing before you rely on them.

Freeze or read-only window

Decide whether teams can keep publishing during the export. If uploads continue, the final copy will miss the newest artifacts, and the cutover must repeat the sync for them. A short freeze on writes to the affected repositories gives a stable snapshot to verify against. Agree the freeze with build owners in advance, and record which repositories are frozen and when, so later checksum comparisons have a clear baseline.

Access and token inventory

List every user, group, access token, API key and permission target that can read the repositories you plan to export. Tokens created by service accounts are the most common blind spot, because they are rarely reviewed when people leave. Note which identities are used by CI jobs, scripts and the JFrog CLI, and who owns each one. Plan to replace these identities on the new platform rather than copy them, and confirm which permissions the export user needs to download every repository.

CI and Kubernetes credential dependencies

Map every pipeline, Dockerfile, Helm values file and Kubernetes image pull secret that points at an Artifactory host or repository path. Each reference is a cutover task, and a missed one fails only when a build or deployment runs. Search build configurations, deployment repositories and cluster namespaces for the Artifactory hostname. The inventory should name the owner of each consumer so that the switch can be scheduled without guessing.

Target platform decision

Choose the destination for each content type before exporting, because the format of the export determines what must be rebuilt. Harbor fits Docker images and Helm charts stored as OCI artifacts. Pulp fits Maven, npm, Python, RPM and Debian content, but several of its plugins are still 0.x releases and the Rust plugin is tech preview. Content that neither platform covers needs a separate decision, and the migration pages describe each path.

Replication from Artifactory during cutover

Harbor can register Artifactory as a replication endpoint, which lets pull-based rules copy Docker and Helm content into Harbor while Artifactory still runs. Proxy cache projects pointed at Artifactory can also serve images during cutover. This reduces the window in which a download-only export must be complete. Confirm that your Artifactory tier and credentials allow this access before you plan the cutover sequence, and read the migration page for the steps.

What the export work costs and who does it

The biggest cost line is usually your current JFrog subscription, and it keeps running during the export. Self-managed customers pay per server under their Pro X, Enterprise X or Enterprise+ subscription, and SaaS customers pay consumption charges for storage and data transfer against the included allowance on the JFrog pricing page. Ask for the exact end date of the active term and whether you can exit before renewal, because every week of parallel running is a recurring cost. The export itself adds one-time costs: staff time to inventory repositories, write download scripts, check results and cut over CI and Kubernetes credentials, plus storage for the exported copy and the network transfer out of JFrog's environment. Egress is the line most often underestimated on SaaS, since JFrog Cloud customers download content rather than run an export job.

Cost moves with four variables you can measure before you sign anything: repository count, total stored volume, the number of package types in use, and the network path between Artifactory and the destination. More repositories mean more inventory and more verification. Mixed package types mean more tooling, since Docker and Helm content has a different migration path from Maven, npm or Python packages. A slow or metered link turns a large volume into a long, expensive download. Storage at the destination depends on whether you keep deduplicated layers or re-create every file. Verification effort is often the largest hidden item, because checksum checks in the JFrog CLI help, but you still need to confirm counts, tags and digests against the source.

In a written scope, ask the vendor or implementation partner to state the following: which repositories and package types are in and out, how checksums and tag lists will be compared, who runs the download and who owns the destination storage, how network egress is metered on your plan, the exit or overlap period you must pay for, and the acceptance test that closes the work. Ask whether the work is fixed-scope with deliverables agreed before it starts. DeployOpen scopes these engagements in writing and quotes from that scope. Confirm with JFrog the current term, data transfer allowance and any export-related charges for your tier, since these are contract-specific and not published as a single figure here.

Common questions about exporting from Artifactory

Can we export everything from Artifactory ourselves?

On self-managed Artifactory, yes for most of it, but only in parts. A system export covers configuration, security information, stored data and metadata in the same format as a system backup, and it writes to a path on the Artifactory server's local file system. Repository export has to be started through the Platform UI, because JFrog's documentation says Artifactory does not support the REST API for exporting a specific repository. Your team needs enough disk space on the server, access to the file system, and someone who understands how the export is restored into a target instance. Cloud customers cannot run these export jobs at all, so the work becomes a download project instead.

How long does an Artifactory export take?

No supplied figure gives a duration, so the honest answer depends on your environment. The main drivers are the total volume of stored binaries, the number of repositories and files, the speed of the disk or network path that receives the export, and whether you export metadata only or the full archive. A configuration-only export moves far less data than a full system export. Ask your team to measure the stored volume per repository before planning, and ask any consultant to base the timeline on that measurement in the written scope.

What does a consultant need from us to start an export?

A consultant needs a current inventory and access to run the work. Expect to provide the Artifactory deployment type (SaaS or self-managed), a list of repositories with their package types, the storage volume per repository, and read access through an administrator account or a dedicated service account with its own API token. For self-managed systems, you also need shell or file system access to the export path, and a clear decision on where the exported data will live. For Cloud, you need a destination for downloaded content and a rough list of what must be kept, such as Docker images and Helm charts. The written scope should name these items so the work is fixed before it begins.

Can we export Artifactory Cloud data with one click?

No. JFrog's documentation states that System Import and Export is not available for Artifactory Cloud users, and that repository export is only available for non-SaaS users. Cloud customers therefore export by downloading content with the JFrog CLI and REST API, for example with the jf rt download command. That command copies files to a local directory using wildcards or JSON file specs, verifies checksums by default and keeps the repository hierarchy unless --flat is set. Downloads take longer than a single export job, and they do not carry the full configuration unless you capture it separately.

Does an Artifactory export include users and permissions?

On self-managed Artifactory, a system export includes security information, so users, groups and permissions are part of that export. Repository exports offer metadata, a ZIP archive or a configuration-only option, and the scope of each option is defined in JFrog's documentation, which you should read against your version. Downloads with the JFrog CLI move files only. They do not recreate users, group memberships, permission targets, or remote repository definitions in another system, so plan to rebuild those access rules by hand in Harbor or Pulp and record each mapping in the migration plan.

What does verifying an Artifactory export require?

Verification needs a checklist that compares the source with the destination, not just a finished transfer. Compare file counts and total size per repository, and compare checksums for a sample or for everything if the content is regulated. The JFrog CLI verifies checksums during download by default, which gives a first control, but you still need a record of what was copied and when. Confirm that every image tag and Helm chart version you depend on can be pulled from the target, and keep the evidence with your change records. DeployOpen prepares these controls and evidence for your assessments, but independent auditors decide whether they are sufficient.

Can an engineer export images through the Docker registry API?

Yes, for container images. Artifactory exposes a Docker registry API, so tools that speak the standard registry protocol can pull images and their manifests. Tools such as Skopeo copy images between registries without privileges and can write them to a local directory, which suits air-gapped transfers. The result is image content, not Artifactory's internal metadata, so you will need to keep a record of image digests, tags and signatures separately. Pulling by digest is the safest method, because a tag can move after the copy.

Where to go after the export is verified

Once the export is verified, the decision is which destination fits each content type. Containers and Helm charts usually point to Harbor, which stores both as OCI artifacts and has a replication engine that can pull from Artifactory as a source during cutover. Non-container packages such as Maven, npm, Python, RPM and Debian point to Pulp, whose plugins vary in maturity. Check the sibling topic on migrating to Harbor and the one on migrating to Pulp before you choose, because each lists the steps that depend on how your repositories are set up.

Feature coverage is the next check. Build a table from your own repository list, and mark every remote, virtual, federated, scanning and curation feature your teams rely on. The comparison pages on Harbor and Pulp set out where each platform matches Artifactory and where it does not, including SSO and high availability by tier. Confirm any gap with the vendor or your own tests, not from this page alone, and record the owner of each gap so it is not discovered during cutover.

Finally, weigh the cost of ownership against the status quo. Artifactory costs are tied to your JFrog plan and deployment model, so ask JFrog for a written quote that covers your renewal terms. For Harbor and Pulp, the recurring costs are servers, object storage, databases, upgrades and the engineering time to run them, and the one-time costs are migration and testing. The cost of ownership comparison page walks through each component. Whatever you decide, keep the verified export as a retained archive until the new registries have passed your restore and pull tests.

How DeployOpen scopes and delivers an Artifactory exit

DeployOpen plans, implements, backs up and documents self-hosted open-source platforms inside your own infrastructure, so an export becomes a scoped, written deliverable rather than an open-ended project. We start by confirming which deployment you run, which repositories hold the content you must keep, and where the exported data will land.

How we scope

Confirm whether you run JFrog Cloud or self-managed Artifactory, since that decides which export paths exist
Inventory repositories, package types, retention needs and the users and CI jobs that pull from them
Agree the written scope, deliverables and timeline with you before any export work begins

How we build

Script repository downloads with the JFrog CLI and verify checksums against the source before accepting copies
Stand up the target storage and registry in your environment, including backups before any import
Test pulls and pushes from representative CI jobs and Kubernetes clusters in a non-production copy first

How we hand over

Document the export procedure, checksum results, repository mapping and any content that could not move
Deliver runbooks for restores, upgrades and credential changes, written for your own platform team
Walk your engineers through the handover so they can rerun the export process without our involvement

How we support

Engagements are fixed-scope, and any follow-on work is agreed in a separate written scope
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Compliance evidence we prepare supports your independent auditors, who issue any attestation or certification

How to export your data from JFrog Artifactory