Migrating to OrbitalReg

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".

Sources we import

Source	Importer status	Detailed playbook
Sonatype Nexus	Stable	✓ Available
JFrog Artifactory	Stable	✓ Available
GitLab Package Registry	Stable	✓ Available
AWS CodeArtifact	Stable	✓ Available (combined cloud guide)
Azure Artifacts	Stable	✓ Available (combined cloud guide)
Google Artifact Registry	Stable	✓ Available (combined cloud guide)
GitHub Packages	Stable	✓ Available

Each importer ships in the OrbitalReg core. No add-on, no separate licence, no third-party migration tool to evaluate.

Three strategies

Pick the strategy that matches your risk profile.

Big bang

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 (under 1 TB), teams that can afford a planned outage, predictability over zero-downtime.

Blue-green parallel run

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.

Lazy proxy

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 (over 10 TB), low risk tolerance, distributed teams that cannot agree on a single cutover window.

The orbital migrate CLI

The CLI handles the entire lifecycle: inventory, bulk import, verification.

# Inventory the source registry — see ./cli-plan for the full reference.
orbital migrate plan \
  --source nexus \
  --endpoint https://nexus.example.com \
  --token "$NEXUS_TOKEN" \
  --output-file migration-plan.json

# Run the bulk import (resumable, parallel) — Phase B, ships separately.
orbital migrate apply --plan migration-plan.json

# Verify before cutover — Phase C, ships separately.
orbital migrate verify --sample 5000

The plan step recommends a strategy based on registry size, network bandwidth, and downtime tolerance. The verify step is what tells you when the data agrees the cutover is safe — it sha256-compares a random sample, format-aware metadata-diffs every repository, and runs synthetic pull tests.

All four commands are shipped today:

• Plan — orbital migrate plan inventories the source registry and recommends a strategy. Per-source flag set + strategy thresholds documented.
• Apply — orbital migrate apply provisions the OrbitalReg side. Strategy-specific provisioning semantics, dry-run / resume flags, and the skipped-row taxonomy.
• Verify — orbital migrate verify sha256- compares a sample, format-aware metadata-diffs every repo, and runs synthetic pull tests. The per-row divergence list + decision taxonomy turns "did the migration land what it claimed?" into a single command.
• Finalize — orbital migrate finalize is the lazy-proxy capstone. Once cache-hit rate is steady, it flips warmed remote-mode repos to local-mode so the source registry can finally be decommissioned.

For the consolidated reference (flag tables, exit codes, end-to-end recipes, tab-completion install) see reference/cli/migrate. The migration pages linked above stay the how-to with strategy rationale and worked examples; the reference page is the what that CI authors and operators copy from.

What you keep

• Developer commands and CI scripts (only the registry URL changes)
• Build-info envelopes (CI run, commit SHA, builder identity)
• Cryptographic signatures (Sigstore, X.509, OpenPGP, CMS)
• Permission groups (translated to OrbitalReg roles)
• Webhooks and automation hooks (translated 1:1 where semantically equivalent)

What changes

• Admin UI (OrbitalReg's is leaner — single binary, single Postgres)
• Pricing model (per-deployment, not per-user — see pricing)
• Air-gapped operation becomes the default (rather than an upcharge)
• All security features always-on (no separate scanning, signing, or audit licences)

Need help?

Customers in active migration get a dedicated channel for questions. Email info@orbitalreg.com with subject "Migration support" and we'll schedule a working session.