Maintain project and group file-based import/export as a workaround for migrations over air-gapped networks and to serve other use cases (#363406) · Issues · GitLab.org / GitLab · GitLab

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

<details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=363406) </details>  ## Problem to Solve GitLab migration replaces the old import / export migration, however some users with [offline networks](https://gitlab.com/groups/gitlab-org/-/epics/4619#note_738548858) 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](https://gitlab.com/gitlab-com/gl-infra/production/-/issues/7122#note_967379458). ## Proposed Solution 1. Remove the UI deprecation message ([discussion](https://gitlab.com/gitlab-org/gitlab/-/issues/341282#note_2838863673)). Consider leaving a warning for users that [DT](https://docs.gitlab.com/user/group/import/) is the preferred method. 1. 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](https://gitlab.com/gitlab-com/dev-sub-department/section-dev-request-for-help/-/issues/165#customer-impact) customer uses [schedule an export](https://docs.gitlab.com/ee/api/project_import_export.html#schedule-an-export) API endpoint.

issue