Migrating projects using file exports (FREE)
Existing projects on any self-managed GitLab instance or GitLab.com can be exported to a file and then imported into a new GitLab instance. You can also:
Set up project import/export
Before you can import or export a project and its data, you must set it up.
- On the left sidebar, select Settings > General.
- Expand Visibility and access controls.
- Scroll to Import sources.
- Enable the desired Import sources.
Between CE and EE
If you're exporting a project from the Enterprise Edition to the Community Edition, you may lose data that is retained only in the Enterprise Edition. For more information, see downgrading from EE to CE.
Export a project and its data
Before you can import a project, you must export it.
- Review the list of items that are exported. Not all items are exported.
- You must have at least the Maintainer role for the project.
To export a project and its data, follow these steps:
- On the top bar, select Main menu > Projects and find your project.
- On the left sidebar, select Settings > General.
- Expand Advanced.
- Select Export project.
- After the export is generated, you should receive an email with a link to download the file.
- Alternatively, you can come back to the project settings and download the file from there or generate a new export. After the file is available, the page should show the Download export button.
The export is generated in your configured
shared_path, a temporary shared directory, and then
moved to your configured
uploads_directory. Every 24 hours, a worker deletes these export files.
Items that are exported
file for projects lists many of the items exported and imported when migrating projects using file exports. View this file in the branch
for your version of GitLab to see the list of items relevant to you. For example,
import_export.yml on the
Migrating projects with file exports uses the same export and import mechanisms as creating projects from templates at the group and instance levels. Therefore, the list of exported items is the same.
Items that are exported include:
- Project and wiki repositories
- Project uploads
- Project configuration, excluding integrations
- Merge requests
- Time tracking and other project entities
- Design Management files and data
- LFS objects
- Issue boards
- Pipelines history
- Push Rules
- Group members are exported as project members, as long as the user has the Maintainer role in the exported project's group, or is an administrator
Items that are not exported include:
- Child pipeline history
- Build traces and artifacts
- Package and container registry images
- CI/CD variables
- Pipeline triggers
- Any encrypted tokens
- Number of required approvals
- Repository size limits
- Deploy keys allowed to push to protected branches
- Secure Files
Import a project and its data
Default maximum import file size changed from 50 MB to unlimited in GitLab 13.8.
WARNING: Only import projects from sources you trust. If you import a project from an untrusted source, it may be possible for an attacker to steal your sensitive data.
- You must have exported the project and its data.
- Compare GitLab versions and ensure you are importing to a GitLab version that is the same or later than the GitLab version you exported to.
- Review the Version history for compatibility issues.
To import a project:
- When creating a new project, select Import project.
- In Import project from, select GitLab export.
- Enter your project name and URL. Then select the file you exported previously.
- Select Import project to begin importing. Your newly imported project page appears shortly.
To get the status of an import, you can query it through the Project import/export API. As described in the API documentation, the query may return an import error or exceptions.
Changes to imported items
Exported items are imported with the following changes:
- Project members with the Owner role are imported with the Maintainer role.
- If an imported project contains merge requests originating from forks, new branches associated with these merge requests are created in the project. Therefore, the number of branches in the new project can be more than in the source project.
- If the
Internalvisibility level is restricted, all imported projects are given
Deploy keys aren't imported. To use deploy keys, you must enable them in your imported project and update protected branches.
Import large projects (FREE SELF)
If you have a larger project, consider using a Rake task as described in the developer documentation.
Automate group and project import (PREMIUM)
For information on automating user, group, and project import API calls, see Automate group and project import.
Maximum import file size
Administrators can set the maximum import file size one of two ways:
The default is
For the GitLab.com setting, see the Account and limit settings section of the GitLab.com settings page.
Map users for import
Imported users can be mapped by their public email addresses on self-managed instances, if an administrator (not an owner) does the import.
- The project must be exported by a project or group member with the Owner role.
- Public email addresses are not set by default. Users must set it in their profiles for mapping to work correctly.
- For contributions to be mapped correctly, users must be an existing member of the namespace, or they can be added as a member of the project. Otherwise, a supplementary comment is left to mention that the original author and the merge requests, notes, or issues that are owned by the importer.
- Imported users are set as direct members in the imported project.
For project migration imports performed over GitLab.com groups, preserving author information is possible through a professional services engagement.
To help avoid abuse, by default, users are rate limited to:
|Export||6 projects per minute|
|Download export||1 download per group per minute|
|Import||6 projects per minute|
GitLab.com may have different settings from the defaults.
In GitLab 14.0, the JSON format is no longer supported for project and group exports. To allow for a transitional period, you can still import any JSON exports. The new format for imports and exports is NDJSON.
Starting with GitLab 13.0, GitLab can import bundles that were exported from a different GitLab deployment. This ability is limited to two previous GitLab minor releases, which is similar to our process for Security Releases.
|Current version||Can import bundles exported from|
|13.0||13.0, 12.10, 12.9|
|13.1||13.1, 13.0, 12.10|
Prior to 13.0 this was a defined compatibility table:
|Exporting GitLab version||Importing GitLab version|
|11.7 to 12.10||11.7 to 12.10|
|11.1 to 11.6||11.1 to 11.6|
|10.8 to 11.0||10.8 to 11.0|
|10.4 to 10.7||10.4 to 10.7|
|10.0 to 10.2||10.0 to 10.2|
|9.4 to 9.6||9.4 to 9.6|
|9.2 to 9.3||9.2 to 9.3|
|8.17 to 9.1||8.17 to 9.1|
|8.13 to 8.16||8.13 to 8.16|
|8.10.3 to 8.11||8.10.3 to 8.11|
|8.10.0 to 8.10.2||8.10.0 to 8.10.2|
|8.9.5 to 8.9.11||8.9.5 to 8.9.11|
|8.9.0 to 8.9.4||8.9.0 to 8.9.4|
Projects can be exported and imported only between versions of GitLab with matching Import/Export versions.
For example, 8.10.3 and 8.11 have the same Import/Export version (0.1.3) and the exports between them are compatible.