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

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

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.