JFrog Artifactory
Repositories, artifacts, properties, build-info envelopes — all migrate via the orbital migrate plan inventory pass and bulk-importer.
Formats: All major formats
Watches and Xray policies map to OrbitalReg pull-gate policies.
Migration
OrbitalReg ships first-class importers for every major artifact-registry incumbent. Your developers keep using the same push and pull commands — only the URL changes. Three migration strategies cover every risk profile, from "downtime is fine" to "zero-tolerance for outages."
Where you're coming from
Each importer ships in the OrbitalReg core. No add-on, no separate licence, no third-party migration tool to evaluate.
Repositories, artifacts, properties, build-info envelopes — all migrate via the orbital migrate plan inventory pass and bulk-importer.
Formats: All major formats
Watches and Xray policies map to OrbitalReg pull-gate policies.
Format-by-format migration. Maven, npm, Docker, NuGet, RubyGems, PyPI, Helm, Conan, Raw — pulled in parallel where bandwidth allows.
Formats: Maven, npm, Docker, NuGet, RubyGems, PyPI, Helm, Conan, Raw
Both OSS and Pro source instances supported. Repository-level permissions migrate to OrbitalReg roles.
Per-org migration with a GitHub PAT. Permissions follow GitHub team mappings; repository scopes translate to OrbitalReg projects.
Formats: Maven, npm, Docker, RubyGems, NuGet
GitHub Enterprise Server and GitHub.com both supported.
Self-hosted GitLab and GitLab.com supported. Group + project scopes map to OrbitalReg projects + repos.
Formats: Maven, npm, Docker, NuGet, PyPI, Conan, Composer, Helm
GitLab CI OIDC tokens translate to OrbitalReg OIDC trust policies natively.
Cross-account migration via STS-assumed role. Domain → project, repository → repo. Upstream mappings preserved.
Formats: Maven, npm, NuGet, PyPI, Generic
Outbound calls only during migration window — air-gapped after cutover.
Azure DevOps PAT auth. Feeds map 1:1 to OrbitalReg projects. Upstream sources translate to OrbitalReg virtual repos.
Formats: Maven, npm, NuGet, Python, Universal
Personal feeds and organisation feeds both supported.
GCP service account with read access. Project-and-region scoping preserved during inventory; consolidated into OrbitalReg projects after.
Formats: Docker, Maven, npm, Python, Apt, Yum, Kubeflow
gcr.io legacy registries also supported via the Docker-format adapter.
What gets migrated
Most teams move a small number of formats with high volume. We profile the migration around your top-five and pull the long-tail formats during the same window.
pom.xml + sha + signature stay intact. Snapshot vs release semantics preserved.
package.json metadata + .tgz tarball + integrity hash. Scoped packages map naturally.
Image manifests + layers + tags + signatures. Multi-arch index.json supported.
index.yaml + tarballs + signed Chart.yaml provenance.
Wheels + sdists + metadata. Per-project namespace mapping.
Plus 30+ additional adapters — Cargo, RubyGems, NuGet, Conan, Nix, Argo Workflows, Deno, Homebrew, Ollama, Kustomize, OPA Bundles, and more. The full format matrix lives in the customer documentation.
How migration works
We've helped teams migrate registries from a few GB to multiple TB. The right approach depends on your downtime tolerance, your registry size, and how distributed your developer base is.
01
Schedule a maintenance window. Run inventory + bulk import + verify. Flip DNS. Total downtime: 30 min – 4 h depending on registry size.
Best for: smaller registries (< 1 TB), teams that can afford a planned outage, predictability over zero-downtime.
02
OrbitalReg runs alongside the source registry. Push traffic doubles up; pull traffic stays on source. After full inventory + verification, you flip DNS in a single change.
Best for: production-critical registries, zero-downtime requirement, ability to handle 2× write traffic during the cutover window.
03
OrbitalReg starts as a remote-proxy in front of the source registry. Each pull fills the cache. Once cache hits exceed your threshold, switch to local-only mode and decommission the source.
Best for: huge registries (> 10 TB), low risk tolerance, distributed teams that can't agree on a single cutover window.
Verify before you cut over
orbital migrate CLI.
A single command-line tool plans the inventory, runs the import, and verifies the result against the source registry — sample-set sha256 comparison, format-aware metadata diffing, permission audit.
Cutover is your decision; the verifier tells you when the data says the cutover is safe.
# Inventory the source registry
$ orbital migrate plan \
--source nexus \
--endpoint https://nexus.example.com \
--token $NEXUS_TOKEN
✓ 12 projects, 100 repositories, ~30M artifacts (14.2 TB)
✓ Strategy recommendation: lazy proxy (size class: large)
✓ Estimated cutover window: 7-14 days (gradual)
# Run the bulk import (resumable, parallel)
$ orbital migrate apply --plan migration-plan.json
✓ 100/100 repositories registered
✓ 30,184,572 artifacts indexed
✓ 47 permission groups translated
✓ Lazy-proxy mode: pulls fill cache on demand
# Verify before cutover
$ orbital migrate verify --sample 5000
✓ 5000/5000 sha256 matches
✓ All metadata round-trips correctly
✓ Pull-test from random sample succeeded
→ Safe to flip DNSDetailed playbooks
Per-source step-by-step guides, format-by-format gotchas, real cutover timelines from past migrations, rollback procedures, and the verification CLI's full reference. Available to invited customers in the documentation portal.