Maintain project and group file-based import/export as a workaround for migrations over air-gapped networks and to serve other use cases

Problem to Solve

GitLab migration replaces the old import / export migration, however some users with offline networks can't use the Group Migration because they don't have network connectivity between GitLab instances. They can only work with the export / import way. Also, the Infrastructure team relies on export/import for data recovery.

Proposed Solution

  1. Remove the UI deprecation message (discussion). Consider leaving a warning for users that DT is the preferred method.
  2. Hide the Import / export functionality behind an Operational Flag, so Self-managed customers who needs to use it will enable it, and will have both the UI and API functionality.

Use cases

  • Exporting projects for compliance reasons. In example customer uses schedule an export API endpoint.
Edited Jan 23, 2026 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading