This page describes scoping migrations from GitLab, Bitbucket Server or GitHub (Enterprise or .com) to a destination GitLab instance (Self-Managed or SaaS). The migrations typically utilize our Congregate automation tool. Migrations from other SCM systems and non-GitLab CI/CD migrations are out of scope for this migration tooling and must be scoped separately.
Using the services calculator, an SA or CSM/CSM can create scoping issue, and work with an Engagement Manager to iterate and refine the services estimate for a customer. In this issue, we have included additional context to the SCM Migration Scoping Questions, which can be previewed below
SCM Migration Scoping Question | Customer Response | Example response | Rationale for asking |
---|---|---|---|
Source SCM System(s) | to-do | Bitbucket Server, GitLab Self-Managed | GitLab PS has automation to facilitate migration for the most popular source systems. Need to know what systems the data is coming from to accurately scope the time to migrate. |
Destination GitLab deployment (SaaS, Self-Managed(HA), Self-Managed(single node)) | to-do | SaaS | We ask this to ensure the destination system deployment is strong enough to handle the throughput of data that will be required during migration. |
Source gitlab version (must be 2 behind latest) | to-do | 13.4 | Migration services leverage many GitLab APIs including our project import/export API. There are specific compatability guidelines documented here |
Destination gitlab version (must be within 2 minor versions of source) | to-do | 14.1 | Migration services leverage many GitLab APIs including our project import/export API. There are specific compatability guidelines documented here |
Total number of Users** | to-do | BB = 225, GLSM = 775 | Migrating users is a pre-requisite step to migrating the data to ensure data elements are associated properly. This is a discrete task in migration engagements and must be scoped with number of users as an input. |
Total portfolios (w/ stakeholder rep) | to-do | 6 | We use total portfolios as a proxy metric to identify how much coordination will be required during migration. Each portfolio leader needs to understand and buy into the migration process for things to go smoothly. This coordination time is built into the migration engagement. |
Total number of git repositories | to-do | BB = 1,234; GL = 4321 | We need to know the total number of repositories to be migrated in order to estimate the number of days of effort. Note: A bitbucket project can contain multiple git repositories. We need the total number of repos. |
Total >5GB GitLab repositories | to-do | BB N/A, GL = 3 | Only applicable for GitLab self-managed migrations to GitLab.com; repos >5GB must be manually migrated due to a 5 GB Cloudflare limitation. Note that we only care about repo size, not the total project size. |
CI/CD System(s) | to-do | Jenkins | We need to know what CI/CD systems are being used to estimate how much it will take to repoint those pipeline jobs to the new SCM system to help the customer resume IT operations. |
Total ci/cd jobs? (CI/CD jobs will need cut-over even if not migrated) | to-do | 4567 | The engagement could include repointing CI/CD jobs back to a source repository. If this is the case, we will need to know how many jobs need to be reconfigured. |
Typical registry size | to-do | 159MB | If registry sizes are unusually big, it could affect the speed of migration. Note: this question only applies to migrations where gitlab is a source system. |
SSO Identity Provider | to-do | Auth0 | We want to make sure this is already in place prior to migration as it is a foundational to the success of a migration engagement. See here for a full list of supported Identity Providers |
Source system OS and Version | to-do | Ubuntu v21.10 | If an upgrade of the source system is needed/included prior to the migration, we want to be sure the OS does not need to be upgraded by the customer to support the new version of GitLab. See installation requirements for more details. |
Source system DB version | to-do | PostgreSQL 13.0 | If an upgrade of the source system is needed/included prior to the migration, we want to be sure the DB does not need to be upgraded by the customer to support the new version of GitLab. See installation requirements for more details. |
Notes:
Note: A project on bitbucket is equivalent to a GitLab group. A Repository on Bitbucket is equivalent to a GitLab project.
Azure DevOps (formerly named Team Foundation Server) contains more than a source code repository, so additional questions need to be asked while scoping out an ADO migration. Five common components in ADO are the following:
Question | Answer | Sample Answer | Rationale for asking |
---|---|---|---|
General | |||
Is it SaaS or self-hosted? | Azure DevOps (SaaS) | If ADO Server (self-hosted), then we need to know software version and other details (i.e. SQL version etc), this will help to pick the right migration approach. | |
How many organizations do you have that need to be migrated? | 1 | Answer to this question will help to understand the current state, amount of required effort and contribute to future architecture of GitLab. | |
How many projects per organization? | 500 | Answer to this questions will help to estimate amount of time and approach for migration. | |
What is the ratio project/repo? | 1:1 | Based on answer to this question additional advisory services to refactor/restructure might be required | |
Azure Boards | |||
Are you using workitems in ADO? | Yes | If workitems need to be retained, then additional migration and/or advisory activities need to be added to the engagement. Note: there are features in ADO workitems (e.g. custom fields and workflows) that are not supported by GitLab issues. During scoping, make sure the customer is aware of these differences. | |
What template do you use? | Scrum, Agile, SCCM | To understand the current state and ensure GitLab's Issues support all the capabilities. | |
What customizations do you use in your boards? | Extra swimming lanes, custom fields etc | Based on this answer we may require additional advisory services to discuss what is possible / not possible and propose alternatives. | |
Azure Repos | |||
Are you using Git or TFVC for your SCM? | Git | This will influence how we interact with the ADO server and determine if a conversion to Git is necessary | |
How many code repositories? | 500 | This will affect the decision on general approaches listed above | |
Are you using branches in your code repositories? | Yes | If the answer is no for some of the repositories, the customer will have to choose between converting specific folders in the repository to branches to retain history or accept a flat file migration of the repository with no history | |
Do you need to retain history in your code repositories? | Yes | If the answer is no and the customer is using ADO, then we do not need to convert the repos to Git. | |
Azure Pipelines | |||
Are you using ADO to build your software? | Yes | This will add CI/CD consulting/transformation activities to the engagement if the answer is yes | |
How many builds/build templates are used per code repository? | 1 | This is a gauge of complexity. Sometimes a code repository can contain several different build definitions | |
Are multiple solution (.sln) or project (.csproj) files building the same packages? | Yes | If yes, this can require advisory services to refactor to those solution/project files to work with gitlab pipelines | |
How many build servers do you use? | 1 | We usually convert a build server to something more ephemeral so the more build servers in use, the more development is required to transition them to something more ephemeral | |
Are there any specific flags used in your build process? If so, what? | Yes | This shows the customer is measuring this data to be used during the transition process. | |
Do you use classic releases? | No | If the answer is yes then additional effort might be required to educate on YAML (pipeline as code) concept | |
Do you use UI build definitions? | No | If yes then this will add CI/CD consulting/transformation activities | |
Do you use YAML for all your definitions (build / release)? | Yes | If "Yes" is the answer to this question then SOW might include additional effort and advisory services (i.e. CI/CD consulting/transformation activities) | |
Do you use extensions from the marketplace that are part of your build/test/release process? Provide the list of extensions (if the answer is "Yes") | Yes. ARM-ttk extension for linting templates. | If yes then we need to ensure that we have equivalent in GitLab for this (or propose alternative solution) | |
What type of agents do you use? | Self-Hosted, Microsoft-hosted (i.e. windows-latest , ubuntu-latest etc) |
Based on this answers we will make a decision what runner architecture to propose and make sure GitLab supports it and how much effort it requires to achieve similar state | |
Do they have special requirements (i.e. network connectivity, required components for build/test/release process)? | Yes, need Visual Studio 2017 capabilities (i.e. legacy software) | Based on the answer we will make a decision if custom runner images are needed (i.e. to install capabilities) | |
Are there any plans in the future to use/add anything special in the CI/CD? | GPU optimized agent | Based on the answer we will make a decision on GitLab Runners to avoid potential limits in the future | |
Azure Test Plans | |||
Do you use test plans and do you need similar functionality in GitLab? | Yes | Based on the answer we need to propose equivalent feature in GitLab | |
Azure Artifacts | |||
Do you use artifact feeds? | Yes | To understand the current state | |
What type of feeds? | Maven, npm, NuGet | To understand the current state and make ensure GitLab has the same capabilities (see GitLab Package Registry) | |
Do you use build/pipeline artifacts? | Yes | ||
What is the retention policy of the packages and do you need to migrate them? | 365 days, no migration needed | To estimate additional effort for migration or/and advisory service to retain existing ADO feed refactoring application to use GitLab Package Registry | |
Integrations | |||
Are there any external tools/applications tied to your ADO server? | Yes. We use an in-house tool that pulls from TFS daily for gathering metrics | If the answer is yes, additional activities will need to be added to the SOW to accommodate transitioning those tools to pull from Git instead. |
.csv
file with source project url
and destination parent path
to let us know where the projects will land on the destination system. Also the customer or we must create the group structure prior to a migration with this reorganization involved. There should be additional time added for new group hierarcy creation to the scope.