Migrate from GitLab Package Registry to RepoFlow

Overview

RepoFlow can automatically migrate supported packages from GitLab Package Registry. This guide covers the built-in migration flow, validation, GitLab CI and client updates, cutover, and decommissioning.

Automatic migration in RepoFlow

RepoFlow now includes automatic repository migration in the product. For new migrations, use the guided RepoFlow migration flow to connect GitLab Package Registry, select the repositories you want to move, and track the transfer from RepoFlow.

Supported package types

Automatic migration from GitLab Package Registry currently supports:

• Universal (generic)
• npm
• Maven (maven2)

Open RepoFlow to start a migration

Legacy RepoFlow CLI migration tool

The standalone RepoFlow CLI migration tool remains available for older CLI-based workflows. For GitLab Package Registry, use the automatic migration flow in RepoFlow for the package types listed above.

Open legacy RepoFlow CLI migration docs

Need help with another package type or a complex repository layout? Contact us or email hello@repoflow.io.

Why migrate to RepoFlow

RepoFlow gives you a dedicated package management platform with proxy caching and flexible cloud or self-hosted deployment, with more details on the features page

Migration steps

1. Inventory packages and consumers: List the GitLab projects and groups that host packages, their package types, and every CI job or developer configuration that uses their endpoints.
2. Design the target layout in RepoFlow: Create the local, remote, and virtual repositories your teams need and map GitLab projects or groups to their RepoFlow destinations.
3. Run an automatic migration: Start with a representative project, then verify package versions, metadata, and permissions in RepoFlow.
4. Validate in GitLab CI: Update one pipeline to restore packages from RepoFlow and run a clean build before the full cutover.
5. Cut over publishing and downloads: Pause package publishing to GitLab for a short final migration window, then update CI variables, tokens, and client endpoints.
6. Monitor and decommission: Keep the old registry paths available until you are confident no packages or clients were missed, then retire them safely.