### Executive Summary Air-gapped customers currently face significant migration challenges, relying on manual file-based processes or costly Professional Services. The proposed solution extends Direct Transfer to support offline migrations without network connectivity between instances. This enables organizations with strict security policies, firewall restrictions, or regulatory requirements to perform convenient, semi-automated migrations. The feature will initially be available via API, followed by UI implementation allowing batch migration of groups and projects. While not fully automated, the process will be straightforward, with optional encryption and support for customers with the strictest data sovereignty requirements. ### Problem Customers that are using air-gapped networks, with no network connectivity between their GitLab instances or with no network connectivity between their GitLab instance and Gitlab.com are currently not able to use Direct transfer to migrate their GitLab resources, as DT requires network connection between instances or GitLab.com. They need to either use file-based import/export and manually export and import each group and project or hire Professional Services to support their migrations. This feature should enable customers who: - Won't allow ANY outside access to their network for various reasons (internal policy, gov't policy) - Don't want to allow an IP range required for online DT - Cannot quickly and easily get an IP added to their firewall system - Have strict restrictions on what lives on the external machines that can connect to their networks (must have this specific VPN, antivirus, etc) to do convenient, semi-automated migrations. ### Proposed solution Refactor and extend Direct transfer, so that it supports migration of Gitlab resources between instances with no network connectivity between them and from offline self-managed instances to .com. In this cases we want to offer to the customers **convenience rather than full automation**. The customers will be responsible for the transfer of the data between the source and destination GitLab instances, because each customer might have different security requirements for the transfer and storage of data, for example some customers cannot allow their data to ever leave their servers. #### Requirements **First iteration** - Users should be able to use API to migrate chosen groups and projects between offline instances. This should be available first, before UI. - The process cannot be fully automated, but it should be straightforward and convenient. - Customers with most strict security requirements ("data cannot leave our servers") need to be supported. **Future iterations** - Users should be able to use UI to choose groups and projects they want to migrate. That means DT should support migration of many groups and projects at the time. - - Currently in UI users can choose only top-level group. In the future it should be possible to choose also subgroups and project from UI. This feature should not prevent more selective choice of resources in the future. - Users should be able to easily understand from UI which path they need to follow and what they need to do in case they want to migrate between connected instances and what they need in case they want to migrate between not connected instances. - Support optional encryption. #### Out of scope - Continuous syncs. -> with completing this epic DT should support one-off migrations between online instances, but not syncing the diffs as the source changes. This is another opportunity, feature requested by customers, but not the focus for this epic. This work should not prevent it, but this capability is out of scope. #### Workarounds for older instances Air-gapped migration can be straightforward for source instances on GL version that contain the changes mentioned in https://gitlab.com/groups/gitlab-org/-/epics/9246+. Older GitLab versions may be able to use the `air-gapped` feature, but they will have to do more manual tasks. These users can always create the expected exported files manually. For example, if their instance isn't exporting the `members` list to files, they can create a script that uses the GraphQL API to fetch the information and then generate the file. - from [comment](https://gitlab.com/gitlab-org/gitlab/-/issues/480245#note_2232548073). <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->