gitlab-org--gitlab-foss/doc/user/project/import/index.md

type	stage	group	info
reference, howto	Manage	Import	To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments

Migrate projects to a GitLab instance (FREE)

See these documents to migrate to GitLab:

• From Bitbucket Cloud
• From Bitbucket Server (also known as Stash)
• From ClearCase
• From CVS
• From FogBugz
• From GitHub.com or GitHub Enterprise
• From GitLab.com
• From Gitea
• From Perforce
• From SVN
• From TFVC
• From repository by URL
• By uploading a manifest file (AOSP)
• From Phabricator
• From Jira (issues only)

You can also import any Git repository through HTTP from the New Project page. Note that if the repository is too large, the import can timeout.

You can also connect your external repository to get CI/CD benefits.

Project import history

You can view all project imports created by you. This list includes the following:

• Source (without credentials for security reasons)
• Destination
• Status
• Error details if the import failed

To view project import history:

1. Sign in to GitLab.
2. On the top bar, select New ({plus}).
3. Select New project/repository.
4. Select Import project.
5. Select History.

The history also includes projects created from built-in or custom templates. GitLab uses import repository by URL to create a new project from a template.

LFS authentication

When importing a project that contains LFS objects, if the project has an .lfsconfig file with a URL host (lfs.url) different from the repository URL host, LFS files are not downloaded.

Migrate from self-managed GitLab to GitLab.com

If you only need to migrate Git repositories, you can import each project by URL. However, you can't import issues and merge requests this way. To retain all metadata like issues and merge requests, use the import/export feature to export projects from self-managed GitLab and import those projects into GitLab.com. All GitLab user associations (such as comment author) are changed to the user importing the project. For more information, see the prerequisites and important notes in these sections:

• Export a project and its data.
• Import the project.

NOTE: When migrating to GitLab.com, you must create users manually unless SCIM will be used. Creating users with the API is limited to self-managed instances as it requires administrator access.

To migrate all data from self-managed to GitLab.com, you can leverage the API. Migrate the assets in this order:

1. Groups
2. Projects
3. Project variables

Keep in mind the limitations of the import/export feature.

You must still migrate your Container Registry over a series of Docker pulls and pushes. Re-run any CI pipelines to retrieve any build artifacts.

Migrate from GitLab.com to self-managed GitLab

The process is essentially the same as migrating from self-managed GitLab to GitLab.com. The main difference is that an administrator can create users on the self-managed GitLab instance through the UI or the users API.

Migrate between two self-managed GitLab instances

To migrate from an existing self-managed GitLab instance to a new self-managed GitLab instance, it's best to back up the existing instance and restore it on the new instance. For example, this is useful when migrating a self-managed instance from an old server to a new server.

The backups produced don't depend on the operating system running GitLab. You can therefore use the restore method to switch between different operating system distributions or versions, as long as the same GitLab version is available for installation.

To instead merge two self-managed GitLab instances together, use the instructions in Migrate from self-managed GitLab to GitLab.com. This method is useful when both self-managed instances have existing data that must be preserved.

Also note that administrators can use the Users API to migrate users.

Project aliases (PREMIUM SELF)

Introduced in GitLab 12.1.

GitLab repositories are usually accessed with a namespace and a project name. When migrating frequently accessed repositories to GitLab, however, you can use project aliases to access those repositories with the original name. Accessing repositories through a project alias reduces the risk associated with migrating such repositories.

This feature is only available on Git over SSH. Also, only GitLab administrators can create project aliases, and they can only do so through the API. For more information, see the Project Aliases API documentation.

After an administrator creates an alias for a project, you can use the alias to clone the repository. For example, if an administrator creates the alias gitlab for the project https://gitlab.com/gitlab-org/gitlab, you can clone the project with git clone git@gitlab.com:gitlab.git instead of git clone git@gitlab.com:gitlab-org/gitlab.git.

Automate group and project import (PREMIUM)

The GitLab Professional Services team uses Congregate to orchestrate user, group, and project import API calls. With Congregate, you can migrate data to GitLab from:

• Other GitLab instances
• GitHub Enterprise
• GitHub.com
• Bitbucket Server
• Bitbucket Data Center

See the Quick Start Guide to learn how to use this approach for migrating users, groups, and projects at scale.