Channel Partner Migration Services

Partner Migration Services

To learn about GitLab migrations, start with GitLab’s technical documentation titled Import and migrate groups and projects. Depending on the source Git provider, size/scope of the migration and the importance of the preservation of the migrated artifacts, carefully consider each option given each option’s limitations/benefits.

The GitLab Channel Partner Program provides the following GitLab Channel Service Packages to our partners in order to construct your own Services Packages in our GitLab Partner Portal, including our Migration Quickstart Services Offering.

From other DevOps platforms to GitLab

To migrate projects from systems other than GitLab, please review the list of Supported import sources.

Migrating pipelines from other systems, such as Jenkins, is a value-add manual development process. We encourage our partners to scope by understanding the number of pipelines, current pipeline performance, envirnonmental variables and secrets used. Some partners find a time and materials style contract to be helpful when consulting on developing pipelines between other sources sytems and GitLab’s pipeline syntax.

From GitLab self-managed to GitLab self-managed

In case of migrating from one self-managed GitLab server to another, the best way usually is to do a full backup at the source instance and then a restore at the target instance. More details about this method can be found here.

From GitLab self-managed to GitLab SaaS or the other way around

There are three different options for these migrations.

1. Congregate

Congregate - used by GitLab Professional Services - is GitLab’s most mature migration solution and supports many options. Note that migrations to SaaS requires the involvement of GitLab PS due to restricted access to GitLab SaaS (multi-tenant) data. More information about the latter can be found here.

Important to note about Congregate:

• Congregate Migration Features Matrix

• Migration Readiness Checklist

• Customer’s obligations and responsibilities - Congregate FAMQ

• Limitations of Self-Managed to SaaS migrations via Congregate - Congregate FAMQ

2. Direct transfer (Beta)

This feature was just recently released, and is the direction our product team is moving towards for migrating GitLab projects from instance to instance or to SaaS. Please review the following resources:

• Migrated group items (direct transfer)

• Migrated project items (direct transfer)

3. File exports

For cases what direct transfer can’t or won’t cover. A good example would be air-gapped environments - see below.

• Migrating projects using file exports

• Items that are exported via file exports

• Items that are not exported via file exports

• Project import and export API

• Group import and export API

Air-gapped environments

GitLab can be installed and operated in offline environments. This setup makes migration projects more complex.

• Direct transfer doesn’t support this. Project/export import is a workaround and it will likely stay as such. More info here and here.

• Congregate does support this. More info here and here.

GitLab Professional Migration Services

GitLab Professional Services team has a full service catalog of offerings avaialable for direct to customers to utilize. Partners may want to review the offerings for inspiration towards delivering same or similar Professional (consultative) Service offerings.

The GitLab Professional Services Migration Package is one popular offering.

Our GitLab Partner Portal has Channel Service Packages that many partners choose to deliver as paid offerings. The link above includes Service Names, Data Sheets, Statement of Works (SOWs), Project Plans, Delivery Kits. The table also outlines GitLabs expectations for the certicications held by our partners under the Aligned Partner Certification column.