[{"data":1,"prerenderedAt":817},["ShallowReactive",2],{"/en-us/blog/jenkins-to-gitlab-migration-made-easy":3,"navigation-en-us":39,"banner-en-us":449,"footer-en-us":459,"blog-post-authors-en-us-Fernando Diaz":698,"blog-related-posts-en-us-jenkins-to-gitlab-migration-made-easy":712,"blog-promotions-en-us":755,"next-steps-en-us":807},{"id":4,"title":5,"authorSlugs":6,"authors":8,"body":10,"category":11,"categorySlug":11,"config":12,"content":16,"date":20,"description":17,"extension":24,"externalUrl":25,"featured":14,"heroImage":19,"isFeatured":14,"meta":26,"navigation":14,"path":27,"publishedDate":20,"rawbody":28,"seo":29,"slug":13,"stem":34,"tagSlugs":35,"tags":37,"template":15,"updatedDate":25,"__hash__":38},"blogPosts/en-us/blog/jenkins-to-gitlab-migration-made-easy.yml","Jenkins-to-GitLab migration made easy",[7],"fernando-diaz",[9],"Fernando Diaz","GitLab is the most comprehensive AI-powered DevSecOps platform. This means that GitLab provides everything needed to plan, develop, and deliver secure software faster, all within one tool.\n\nPlatforms take away the pains and struggles of integrating various tools (DIY DevOps) to enable the software development lifecycle (SDLC). Since Jenkins is not a platform, additional tools are required to complete the SDLC. This DIY DevOps approach introduces toolchain complexity, which creates the following drawbacks:\n\n- Custom support is required for the integration and orchestration of tools\n- Difficulty maintaining/upgrading/securing separate tools\n- Inefficiency in measuring organizational transformation\n- Poor developer experience\n- Additional management/time/budget costs\n- Loss of productivity\n- Context switching and collaboration inefficiencies\n\n\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png \"DIY DevOps vs. DevSecOps Platform\")\n\n\u003Cp>\u003C/p>\n\nFor these reasons, many Jenkins teams are considering migrating to a DevSecOps platform. If you are looking for a more powerful, reliable, and secure solution, GitLab is your best option! GitLab is free to get started with and offers different subscription tiers based on the needs of your organization. To learn more about our offerings and features, check out our [pricing page](https://about.gitlab.com/pricing/).\n\nIn this blog, you will learn:\n- How to plan for a migration\n- How to migrate repositories from other source code management (SCM) tools to GitLab\n- How to migrate CI/CD pipelines from Jenkins to GitLab\n- Additional migration considerations\n\n### Planning for a migration\n\nBefore starting a migration from another tool to GitLab CI/CD, you should begin by developing a migration plan. A migration plan is an important technical step for setting expectations. CI/CD tools differ in approach, structure, and technical specifics, meaning that migrations are not just 1:1 mappings of data. A migration plan will provide the following benefits:\n- Sets and communicates a clear vision of what your migration goals are, which helps your users understand why the effort is worth it. The value is clear when the work is done, but people need to be aware while it’s in progress too.\n- Provides sponsorship and alignment from the relevant leadership teams helps with the point above.\n- Spends time educating users on what’s different.\n- Finds ways to sequence or delay parts of the migration and prevent non-migrated (or partially migrated) states for too long.\n- Documents advantages of the improvements that GitLab CI/CD offers, and updates your implementation as part of the transition.\n\nA migration plan will allow you to put a process in place where you can slowly migrate to GitLab with minimal disruption. This may include running both Jenkins and GitLab, while certain projects are moved to GitLab and offloaded from Jenkins.\n\n### Defining a change management process\n\nThe migration plan should define an effective change management process. Developers, IT Operations, Cloud Administrators, Security, and Quality Engineers may not have experience with GitLab and they may not know why you or your leadership have decided to move in this direction.\n\nThe people this is impacting need to know:\n- __Why__ the change is being made\n- __What__ the future state looks like\n- __How__ the company intends to get there from here\n- __Where__ to go for more information or help\n\nTo this end, you should consider the following steps to manage change across these functional roles:\n- __Analyze the current state__: Document the current state of processes. Gather metrics as a baseline. Identify what's working and not working with CI/CD by interviewing key team members. Document the challenges you uncover both quantitatively and qualitatively. You’re going to have to sell the vision and reason for the change, so the more clearly you can define the problem set, the easier it will be to gain buy-in from across the business.\n- __Establish a vision__: Now that you have current pain points outlined quantitatively with baseline metrics and qualitatively (in the words of your team members), communicate a vision of the future state. Explain why it's important (tie this to business success metrics). Provide live and recorded demonstrations of what good looks like and compare it to the current state. Reinforce this message through multiple channels and media — chat groups, all-hands meetings, email notifications, banner notifications on GitLab, etc.\n- __Educate the workforce__: Invest in [GitLab CI/CD Training](https://university.gitlab.com/pages/ci-cd-training/) delivered by a GitLab expert. Measure knowledge acquisition and retention using [GitLab Certifications](https://levelup.gitlab.com/pages/certifications).\n- __Communicate roadmap and resources__: Communicate to your team members the intended timeline, available resources to help them transition, and community resources like chat groups, Q&A boards, or GitLab Influencer office hours so they can ask questions and get help. Bonus points for building a reward system to incentivize teams to transition early and share their experience with their peer application groups!\n\nIf you have these elements in place as you begin this transition, you will have a framework for success.\n\n### Establishing migration goals\nBefore performing a migration, you should have a good understanding of your goals and how to meet them. For example, some questions you should have answers to are as follows:\n- What is your timeline to migrate?\n- How is your Jenkins server currently configured?\n- How many projects must be migrated?\n- What is the complexity of your pipeline?\n- Does it require external dependencies, multiple pipeline triggers, parallel builds, etc.?\n- How/Where do you deploy your code?\n- What is the release/review process for deploying code?\n- Is it integrated into Jenkins, or a separate workflow triggered by Jenkins?\n- Which build artifacts or binaries are required for pipeline success?\n- Which plugins are used by jobs in Jenkins today?\n- Which software is installed on the Jenkins agents?\n- What SCM solution are you currently using?\n- Are there any shared libraries in use within your Jenkins jobs?\n- Which authentication method is used for Jenkins (Basic auth, LDAP/AD, SSO)?\n- Are there other projects that you need to access from your pipeline?\n- Are there credentials in Jenkins used to access outside services?\n\nBy answering these questions you’ll know how to proceed with the migration, how long it will take, and where to start. Once you have built a plan and are confident of the expectations and possible pitfalls, you can begin the migration process.\n\n### Prerequisites for migration\nOnce you have created a migration plan and addressed all the expectations of the migration, you can begin to set up GitLab. Some of the prerequisites suggested for migration are as follows:\n- Get familiar with GitLab. Read about the [key GitLab CI/CD features](https://docs.gitlab.com/ci/).\n- Follow tutorials to create your first [GitLab pipeline](https://docs.gitlab.com/ci/quick_start/) and [more complex pipelines](https://docs.gitlab.com/ci/quick_start/tutorial/) that build, test, and deploy a static site.\n- Review the [.gitlab-ci.yml keyword reference](https://docs.gitlab.com/ci/yaml/).\n- Set up and configure GitLab.\n- Test your GitLab instance.\n\nOnce you understand GitLab and an instance has been configured, you can work through your migration plan and begin to move projects from Jenkins over to GitLab. Make sure your GitLab instance has been properly set up using GitLab best practices and [reference architectures](https://docs.gitlab.com/administration/reference_architectures/).\n\n### Migrating repositories to GitLab\nOne of the main drawbacks of Jenkins is that it does not provide an SCM solution. If you are using Jenkins, your code must be stored in a separate SCM solution which Jenkins must have access to. Because GitLab has built-in SCM, migrating away from Jenkins also allows you to migrate from the SCM solution you were leveraging, bringing forth an additional reduction in costs.\n\nGitLab provides tools to allow you to easily move your repository and its metadata into GitLab. The following importers are included to assist in migrating your projects to GitLab:\n\n- [GitHub](https://docs.gitlab.com/user/project/import/github/)\n- [Another GitLab instance](https://docs.gitlab.com/user/project/settings/import_export/)\n- [Bitbucket Cloud](https://docs.gitlab.com/user/project/import/bitbucket/)\n- [Bitbucket Server](https://docs.gitlab.com/user/project/import/bitbucket_server/)\n- [FogBugz](https://docs.gitlab.com/user/project/import/fogbugz/)\n- [Gitea](https://docs.gitlab.com/user/project/import/gitea/)\n- [Jira (Issues only)](https://docs.gitlab.com/user/project/import/jira/)\n- [Repo by manifest file](https://docs.gitlab.com/user/project/import/manifest/)\n- [Repo by URL](https://docs.gitlab.com/user/project/import/repo_by_url/)\n![GitHub to GitLab Repo Exporter](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png \"GitHub to GitLab Repo Exporter\")\nEach importer imports different data from a project. Read the [import and migrate projects documentation](https://docs.gitlab.com/user/project/import/) to learn more about the provided importers to see what data is migrated to GitLab. Additionally, you can [automate group and project import](https://docs.gitlab.com/user/project/import/#automate-group-and-project-import) and build a custom solution to further suit the needs of your organization:\n\n- [Professional Services](https://about.gitlab.com/services/)\n- [Migration Utilities](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n- [Frequently Asked Migration Questions](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n### How to migrate a repository\nMigrating a repository to GitLab is easy using our built-in importers. In this example, I’ll show how to copy a repo from GitHub to GitLab along with [its resources](https://docs.gitlab.com/user/project/import/github/#imported-data) (Issues, Pull Requests, Milestones, etc.). In order to migrate a repository from another GitHub to GitLab, you can follow the steps below:\n\n1. On the left sidebar, at the top, select **Create new (+)**.\n2. Select **New project/repository** under the In GitLab section.\n3. Select **Import project**.\n\n\n![Import project selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png \"Import project selection\")\n\n\u003Cp>\u003C/p>\n\n4. Click the **GitHub** button.\n    - If using GitLab self-managed, then you must [enable the GitHub importer](https://docs.gitlab.com/administration/settings/import_and_export_settings/#configure-allowed-import-sources).\n    - Note that other importers can be initiated in the same way.\n5. Now you can either:\n    - Authorize with GitHub OAuth: Select **Authorize with GitHub**.\n    - Or, use a GitHub personal access token:\n       - Go to [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n       - In the **Note** field, enter a token description.\n       - Select the repo scope.\n       - Optionally to import collaborators, select the              **read:org** scope.\n       - Click the **Generate token** button.\n       - On the GitLab import page, in the Personal Access Token field, paste the GitHub personal access token.\n6. Click the **Authenticate** button.\n7. Select the items you wish to migrate.\n8. Select the projects you wish to migrate and to where.\n9. Press the **Import** button.\n\nNow you should have the imported project in your workspace. For additional guidance on migrating from GitHub to GitLab you can watch this video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\nOnce you have completed the repository migration, you can set your Jenkins pipeline to leverage the Jenkinsfile within GitLab. This can be done by setting the repository URL via to your newly imported project via the Jenkin pipeline configuration menu:\n\n\n![Jenkins Pipeline SCM settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png \"Jenkins Pipeline SCM settings\")\n\n\u003Cp>\u003C/p>\n\nThis is useful for the initial repo migration phase and allows you to use both Jenkins and GitLab in parallel, preventing service disruptions while you work on migrating the CI/CD functionality.\n\nAdditionally, you can leverage the [GitLab Jenkins plugin](https://plugins.jenkins.io/gitlab-plugin/) to assist with migration. This plugin allows GitLab to trigger and obtain the status of Jenkins builds.\n\n### Migrating CI/CD pipelines\nOnce you have migrated your repositories to GitLab, you can proceed to migrate your Jenkins pipelines to GitLab. This process can be fairly straightforward, but requires an understanding of both Jenkins and GitLab concepts and syntax.\n\nJenkins provides two different types of syntax for defining pipelines, Declarative and Scripted. In this guide we will be covering migrating from Declarative pipelines since they are the most commonly used.\n\n### Step-by-step pipeline migration\nIn this tutorial we will analyze a Jenkinsfile (Groovy) alongside a GitLab CI/CD configuration file (YAML) that builds, tests, and deploys a microservice written in Golang. We will then proceed to enable the pipeline within GitLab and see its results. The pipeline will:\n\n- Use the golang container image with the **alpine** tag\n- Run a job for building the Golang code into an executable binary\n   - Stores the built executable as an artifact\n- Run a job to run unit tests\n- Run a job to deploy to staging\n   - Only executes if the commit targets the **staging** branch\n   - Starts after the **test** stage succeeds\n   - Uses the built executable artifact from the earlier job\n\nBelow you can see Jenkins and GitLab pipeline definitions along with descriptive comments. You can see the pipeline in action in the [Meow Migration project](https://gitlab.com/gitlab-da/projects/blogs/meow-migration).\n\nLet's take a look at a Jenkinsfile written in Groovy:\n\n```shell\n// The top-level of the declarative\n// pipeline.\npipeline {\n\n  // Defines the default agent to use\n  // when it is not explicitly defined\n  // in a job.\n    agent any\n\n  // Defines the stages that will run\n  // in numerical order. Each stage\n  // only runs one job.\n    stages {\n\n    // Defines the name of the stage\n        stage('build') {\n      // Defines the container image to\n      // use for this job, overwriting\n      // the default 'agent any'.\n      // The Jenkins Docker plugin\n      // must be configured for this\n      // to run.\n            agent { docker 'golang:alpine' }\n\n      // Defines the sequence of steps\n      // to execute when the stage is\n      // run.\n            steps {\n                sh 'go build -o bin/meow-micro'\n                sh 'chmod +x bin/meow-micro'\n            }\n\n      // The steps to run after the\n      // stage completes.\n            post {\n              always {\n\n        // Stores the stage artifacts\n        // generated for use in another\n        // job.\n                archiveArtifacts artifacts: 'bin/meow-micro'\n                onlyIfSuccessful: true\n              }\n            }\n        }\n\n    stage('test') {\n            agent { docker 'golang:alpine' }\n            steps {\n                sh 'go test .'\n            }\n        }\n\n        stage('deploy') {\n      // Defines conditions which must\n      // be met in order for the job to\n      // execute. In this case the\n      // deploy job will only run on the\n      // staging branch.\n            when {\n              branch 'staging'\n            }\n            steps {\n                echo 'Deploying meow-micro to staging'\n        // Uses the artifact stored in\n        // the build stage.\n                sh './bin/meow-micro'\n            }\n        }\n    }\n}\n```\n\nNow, let's see how to create the same functionality in GitLab:\n\n```text\n# Defines the default image to use\n# when it is not explicitly defined in\n# a job.\ndefault:\n  image: alpine:latest\n\n# Defines the order to run the stages.\n# Each stage can have multiple jobs.\nstages:\n  - build\n  - test\n  - deploy\n\n# Defines the name of the job\ncreate-binary:\n # Defines the stage the job will run in\n  stage: build\n # Defines the container image to use\n # for this job, overwriting default.\n  image: golang:alpine\n # Defines the sequence of steps to\n # execute when the job is run.\n  script:\n    - go build -o bin/meow-micro\n    - chmod +x bin/meow-micro\n # Stores the job artifacts generated\n # for use in another job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n    expire_in: 1 week\n\nunit-tests:\n  stage: test\n  image: golang:alpine\n  script:\n    - go test .\n # Defines commands to run after the\n # job.\n after_script:\n  - echo \"Tests Complete\"\n\nstaging-deploy:\n  stage: deploy\n # Defines commands to run before the\n # actual job.\n  before_script:\n    - apk update\n  script:\n    - echo \"Deploying meow-micro to staging environment\"\n    - ./bin/meow-micro\n # Defines conditions which must be met\n # in order for this job to execute. In\n # this case the staging-deploy job will\n # only run on the staging branch.\n  rules:\n    - if: $CI_COMMIT_BRANCH == 'staging'\n # Allows the artifact stored in the\n # build job to be used in this job.\n  artifacts:\n    paths:\n      - bin/meow-micro\n\n```\n\nAs you may have observed, there are many similarities between both Jenkins and GitLab in terms of syntax, making pipeline migration straightforward. While the above provides a basic example, be sure to read the comprehensive list of [feature and concept comparisons](https://docs.gitlab.com/ci/migration/jenkins/#comparison-of-features-and-concepts) between both tools.\n\nNow that we have an understanding of how to map Jenkins to GitLab we can start creating a pipeline with the same functionality in GitLab. In order to perform the migration of CI/CD, you can go through the following steps:\n\n##### 1. Open the repository you migrated to GitLab in the section above.\n- On the left sidebar, at the top, select **Search or go to…**.\n- Locate your project.\n\n##### 2. Open the [Pipeline Editor](https://docs.gitlab.com/ci/pipeline_editor/).\n- On the left sidebar, Select **Build > Pipeline editor**.\n\n![Pipeline editor menu](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png \"Pipeline editor menu\")\n\n\u003Cp>\u003C/p>\n\n- Click the **Configure pipeline** button.\n\n\n![Configure pipeline selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png \"Configure pipeline selection\")\n\n\u003Cp>\u003C/p>\n\n##### 3. Populate the [.gitlab-ci.yml](https://docs.gitlab.com/ci/yaml/).\n- Add the GitLab CI pipeline code.\n\n![Pipeline editor input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png \"Pipeline editor input\")\n\n\u003Cp>\u003C/p>\n\n- Verify that the syntax is correct.\n\n\n![Pipeline syntax validation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png \"Pipeline syntax validation\")\n\n\u003Cp>\u003C/p>\n\n- Visualize the pipeline.\n\n\n![Pipeline visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png \"Pipeline visualization\")\n\n\u003Cp>\u003C/p>\n\n##### 4. Commit the file to the main branch.\n- Add a commit message.\n- Make sure the branch is set to main.\n- Click the Commit changes button.\n\n\n![Commit changes dialog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png \"Commit changes dialog\")\n\n\u003Cp>\u003C/p>\n\nOnce the file has been merged, the defined pipeline will kick off. You can go back to your project and [view the pipeline](https://docs.gitlab.com/ci/pipelines/#view-pipelines) in action by selecting it under your project’s **Build > Pipelines** page. Since it was run on the **main** branch, you will see only the **create-binary** and unit-tests jobs; the **staging-deploy** job only runs on the staging branch.\n\n\n![Pipeline running on main branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png \"Pipeline running on main branch\")\n\n\u003Cp>\u003C/p>\n\nIf we create a staging branch, we can see that the following pipeline is initiated.\n\n\n![Pipeline running on staging branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png \"Pipeline running on staging branch\")\n\n\u003Cp>\u003C/p>\n\nWhen clicking on a job we can see its output:\n\n\n![create-binary job output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png \"create-binary job output\")\n\n\u003Cp>\u003C/p>\n\n\n![unit-tests job output input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png \"unit-tests job output input\")\n\n\u003Cp>\u003C/p>\n\n\n![staging-deploy job output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png \"staging-deploy job output\")\n\n\u003Cp>\u003C/p>\n\nYou can see how the artifact is stored in the create-binary job and used in the staging-deploy job. And that's how easy it is to migrate a pipeline from Jenkins to GitLab!\n\n### Additional considerations when migrating\nSome helpful considerations we’ve found to make the deployment process more straightforward are as follows:\n\n- Don't try to replicate tasks into GitLab jobs 1:1. Take some inventory and time to understand what the current pipeline is doing, and which problem it is solving.\n\n- Some Jenkins jobs may be too complex to move over to GitLab right away. For this reason, it may be beneficial to use the [GitLab Jenkins plugin](https://plugins.jenkins.io/gitlab-plugin/) to initiate Jenkins pipelines and view their results directly from GitLab. This allows you to slowly migrate certain actions to GitLab until the whole pipeline can be moved.\n\n- Implement [security scanners and code quality](https://docs.gitlab.com/user/application_security/) using built-in templates provided by GitLab from the start. This will allow you to shift security left, reducing the potential for a breach.\nDon't overcomplicate the CI/CD config and try to use every feature advantage at once. Modularize code and implement it in small iterations.\n\n- Implement monitoring and governance from the start.\n\n- Understand that the GitLab Runner (Go) might behave differently than the Jenkins agent (Java). CPU usage and memory consumption might differ — make sure to compare over time.\n\n- Consider investing in auto-scaling mechanisms, and shut down unneeded resources on the weekend, or outside of working hours.\n\n- Modernize application development by containerizing your jobs. Jenkins jobs are not executed on a container today but on a Jenkins agent running as a VM.\n\nWhile this list is not exhaustive, it does provide a good start on some considerations to take note of. If you need additional help, GitLab provides [professional services](https://about.gitlab.com/get-help/) to support your migration journey.\n\n### Learn more\nThanks for reading! I hope this guide has helped you get a clear understanding of why and how to migrate from Jenkins to GitLab. Not convinced? [Give GitLab a try with our free trial](https://about.gitlab.com/free-trial/), and see the value of a DevSecOps platform!\n\nHere are a few resources where you can learn more about GitLab, the benefits of using a DevSecOps platform, and migrating from Jenkins:\n\n- [Migrating from Jenkins](https://docs.gitlab.com/ci/migration/jenkins/)\n- [Planning a migration](https://docs.gitlab.com/ci/migration/plan_a_migration/)\n- [GitLab Project Importers](https://docs.gitlab.com/user/project/import/)\n- [Tutorial: GitHub to GitLab migration the easy way](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n- [Video: GitHub to GitLab migration the easy way](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n- [Jenkins to GitLab: The ultimate guide to modernizing your CI/CD environment](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n","devsecops",{"slug":13,"featured":14,"template":15},"jenkins-to-gitlab-migration-made-easy",true,"BlogPost",{"title":5,"description":17,"authors":18,"heroImage":19,"date":20,"body":10,"category":11,"tags":21},"Learn why and how to migrate from Jenkins to GitLab with ease by following this step-by-step guide.",[9],"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg","2024-02-01",[22,23],"CI/CD","DevSecOps","yml",null,{},"/en-us/blog/jenkins-to-gitlab-migration-made-easy","seo:\n  title: Jenkins-to-GitLab migration made easy\n  description: >-\n    Learn why and how to migrate from Jenkins to GitLab with ease by following\n    this step-by-step guide.\n  ogTitle: Jenkins-to-GitLab migration made easy\n  ogDescription: >-\n    Learn why and how to migrate from Jenkins to GitLab with ease by following\n    this step-by-step guide.\n  noIndex: false\n  ogImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n  ogUrl: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\n  ogSiteName: https://about.gitlab.com\n  ogType: article\n  canonicalUrls: https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy\ncontent:\n  title: Jenkins-to-GitLab migration made easy\n  description: >-\n    Learn why and how to migrate from Jenkins to GitLab with ease by following\n    this step-by-step guide.\n  authors:\n    - Fernando Diaz\n  heroImage: >-\n    https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663019/Blog/Hero%20Images/AdobeStock_519147119.jpg\n  date: '2024-02-01'\n  body: >\n    GitLab is the most comprehensive AI-powered DevSecOps platform. This means\n    that GitLab provides everything needed to plan, develop, and deliver secure\n    software faster, all within one tool.\n\n\n    Platforms take away the pains and struggles of integrating various tools\n    (DIY DevOps) to enable the software development lifecycle (SDLC). Since\n    Jenkins is not a platform, additional tools are required to complete the\n    SDLC. This DIY DevOps approach introduces toolchain complexity, which\n    creates the following drawbacks:\n\n\n    - Custom support is required for the integration and orchestration of tools\n\n    - Difficulty maintaining/upgrading/securing separate tools\n\n    - Inefficiency in measuring organizational transformation\n\n    - Poor developer experience\n\n    - Additional management/time/budget costs\n\n    - Loss of productivity\n\n    - Context switching and collaboration inefficiencies\n\n\n\n    ![Import project\n    selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752175993/Blog/ikr97sr9jclddeqdg7ew.png\n    \"DIY DevOps vs. DevSecOps Platform\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    For these reasons, many Jenkins teams are considering migrating to a\n    DevSecOps platform. If you are looking for a more powerful, reliable, and\n    secure solution, GitLab is your best option! GitLab is free to get started\n    with and offers different subscription tiers based on the needs of your\n    organization. To learn more about our offerings and features, check out our\n    [pricing page](https://about.gitlab.com/pricing/).\n\n\n    In this blog, you will learn:\n\n    - How to plan for a migration\n\n    - How to migrate repositories from other source code management (SCM) tools\n    to GitLab\n\n    - How to migrate CI/CD pipelines from Jenkins to GitLab\n\n    - Additional migration considerations\n\n\n    ### Planning for a migration\n\n\n    Before starting a migration from another tool to GitLab CI/CD, you should\n    begin by developing a migration plan. A migration plan is an important\n    technical step for setting expectations. CI/CD tools differ in approach,\n    structure, and technical specifics, meaning that migrations are not just 1:1\n    mappings of data. A migration plan will provide the following benefits:\n\n    - Sets and communicates a clear vision of what your migration goals are,\n    which helps your users understand why the effort is worth it. The value is\n    clear when the work is done, but people need to be aware while it’s in\n    progress too.\n\n    - Provides sponsorship and alignment from the relevant leadership teams\n    helps with the point above.\n\n    - Spends time educating users on what’s different.\n\n    - Finds ways to sequence or delay parts of the migration and prevent\n    non-migrated (or partially migrated) states for too long.\n\n    - Documents advantages of the improvements that GitLab CI/CD offers, and\n    updates your implementation as part of the transition.\n\n\n    A migration plan will allow you to put a process in place where you can\n    slowly migrate to GitLab with minimal disruption. This may include running\n    both Jenkins and GitLab, while certain projects are moved to GitLab and\n    offloaded from Jenkins.\n\n\n    ### Defining a change management process\n\n\n    The migration plan should define an effective change management process.\n    Developers, IT Operations, Cloud Administrators, Security, and Quality\n    Engineers may not have experience with GitLab and they may not know why you\n    or your leadership have decided to move in this direction.\n\n\n    The people this is impacting need to know:\n\n    - __Why__ the change is being made\n\n    - __What__ the future state looks like\n\n    - __How__ the company intends to get there from here\n\n    - __Where__ to go for more information or help\n\n\n    To this end, you should consider the following steps to manage change across\n    these functional roles:\n\n    - __Analyze the current state__: Document the current state of processes.\n    Gather metrics as a baseline. Identify what's working and not working with\n    CI/CD by interviewing key team members. Document the challenges you uncover\n    both quantitatively and qualitatively. You’re going to have to sell the\n    vision and reason for the change, so the more clearly you can define the\n    problem set, the easier it will be to gain buy-in from across the business.\n\n    - __Establish a vision__: Now that you have current pain points outlined\n    quantitatively with baseline metrics and qualitatively (in the words of your\n    team members), communicate a vision of the future state. Explain why it's\n    important (tie this to business success metrics). Provide live and recorded\n    demonstrations of what good looks like and compare it to the current state.\n    Reinforce this message through multiple channels and media — chat groups,\n    all-hands meetings, email notifications, banner notifications on GitLab,\n    etc.\n\n    - __Educate the workforce__: Invest in [GitLab CI/CD\n    Training](https://university.gitlab.com/pages/ci-cd-training/) delivered by\n    a GitLab expert. Measure knowledge acquisition and retention using [GitLab\n    Certifications](https://levelup.gitlab.com/pages/certifications).\n\n    - __Communicate roadmap and resources__: Communicate to your team members\n    the intended timeline, available resources to help them transition, and\n    community resources like chat groups, Q&A boards, or GitLab Influencer\n    office hours so they can ask questions and get help. Bonus points for\n    building a reward system to incentivize teams to transition early and share\n    their experience with their peer application groups!\n\n\n    If you have these elements in place as you begin this transition, you will\n    have a framework for success.\n\n\n    ### Establishing migration goals\n\n    Before performing a migration, you should have a good understanding of your\n    goals and how to meet them. For example, some questions you should have\n    answers to are as follows:\n\n    - What is your timeline to migrate?\n\n    - How is your Jenkins server currently configured?\n\n    - How many projects must be migrated?\n\n    - What is the complexity of your pipeline?\n\n    - Does it require external dependencies, multiple pipeline triggers,\n    parallel builds, etc.?\n\n    - How/Where do you deploy your code?\n\n    - What is the release/review process for deploying code?\n\n    - Is it integrated into Jenkins, or a separate workflow triggered by\n    Jenkins?\n\n    - Which build artifacts or binaries are required for pipeline success?\n\n    - Which plugins are used by jobs in Jenkins today?\n\n    - Which software is installed on the Jenkins agents?\n\n    - What SCM solution are you currently using?\n\n    - Are there any shared libraries in use within your Jenkins jobs?\n\n    - Which authentication method is used for Jenkins (Basic auth, LDAP/AD,\n    SSO)?\n\n    - Are there other projects that you need to access from your pipeline?\n\n    - Are there credentials in Jenkins used to access outside services?\n\n\n    By answering these questions you’ll know how to proceed with the migration,\n    how long it will take, and where to start. Once you have built a plan and\n    are confident of the expectations and possible pitfalls, you can begin the\n    migration process.\n\n\n    ### Prerequisites for migration\n\n    Once you have created a migration plan and addressed all the expectations of\n    the migration, you can begin to set up GitLab. Some of the prerequisites\n    suggested for migration are as follows:\n\n    - Get familiar with GitLab. Read about the [key GitLab CI/CD\n    features](https://docs.gitlab.com/ci/).\n\n    - Follow tutorials to create your first [GitLab\n    pipeline](https://docs.gitlab.com/ci/quick_start/) and [more\n    complex pipelines](https://docs.gitlab.com/ci/quick_start/tutorial/)\n    that build, test, and deploy a static site.\n\n    - Review the [.gitlab-ci.yml keyword\n    reference](https://docs.gitlab.com/ci/yaml/).\n\n    - Set up and configure GitLab.\n\n    - Test your GitLab instance.\n\n\n    Once you understand GitLab and an instance has been configured, you can work\n    through your migration plan and begin to move projects from Jenkins over to\n    GitLab. Make sure your GitLab instance has been properly set up using GitLab\n    best practices and [reference\n    architectures](https://docs.gitlab.com/administration/reference_architectures/).\n\n\n    ### Migrating repositories to GitLab\n\n    One of the main drawbacks of Jenkins is that it does not provide an SCM\n    solution. If you are using Jenkins, your code must be stored in a separate\n    SCM solution which Jenkins must have access to. Because GitLab has built-in\n    SCM, migrating away from Jenkins also allows you to migrate from the SCM\n    solution you were leveraging, bringing forth an additional reduction in\n    costs.\n\n\n    GitLab provides tools to allow you to easily move your repository and its\n    metadata into GitLab. The following importers are included to assist in\n    migrating your projects to GitLab:\n\n\n    - [GitHub](https://docs.gitlab.com/user/project/import/github/)\n\n    - [Another GitLab\n    instance](https://docs.gitlab.com/user/project/settings/import_export/)\n\n    - [Bitbucket\n    Cloud](https://docs.gitlab.com/user/project/import/bitbucket/)\n\n    - [Bitbucket\n    Server](https://docs.gitlab.com/user/project/import/bitbucket_server/)\n\n    - [FogBugz](https://docs.gitlab.com/user/project/import/fogbugz/)\n\n    - [Gitea](https://docs.gitlab.com/user/project/import/gitea/)\n\n    - [Jira (Issues\n    only)](https://docs.gitlab.com/user/project/import/jira/)\n\n    - [Repo by manifest\n    file](https://docs.gitlab.com/user/project/import/manifest/)\n\n    - [Repo by\n    URL](https://docs.gitlab.com/user/project/import/repo_by_url/)\n\n    ![GitHub to GitLab Repo\n    Exporter](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176002/Blog/ie2xrexhbcoq6m8rnhit.png\n    \"GitHub to GitLab Repo Exporter\")\n\n    Each importer imports different data from a project. Read the [import and\n    migrate projects\n    documentation](https://docs.gitlab.com/user/project/import/) to learn\n    more about the provided importers to see what data is migrated to GitLab.\n    Additionally, you can [automate group and project\n    import](https://docs.gitlab.com/user/project/import/#automate-group-and-project-import)\n    and build a custom solution to further suit the needs of your organization:\n\n\n    - [Professional Services](https://about.gitlab.com/services/)\n\n    - [Migration\n    Utilities](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/docs/using-congregate.md#quick-start)\n\n    - [Frequently Asked Migration\n    Questions](https://gitlab.com/gitlab-org/professional-services-automation/tools/migration/congregate/-/blob/master/customer/famq.md)\n\n\n    ### How to migrate a repository\n\n    Migrating a repository to GitLab is easy using our built-in importers. In\n    this example, I’ll show how to copy a repo from GitHub to GitLab along with\n    [its\n    resources](https://docs.gitlab.com/user/project/import/github/#imported-data)\n    (Issues, Pull Requests, Milestones, etc.). In order to migrate a repository\n    from another GitHub to GitLab, you can follow the steps below:\n\n\n    1. On the left sidebar, at the top, select **Create new (+)**.\n\n    2. Select **New project/repository** under the In GitLab section.\n\n    3. Select **Import project**.\n\n\n\n    ![Import project\n    selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176017/Blog/boowmmaqhbredxa3g92s.png\n    \"Import project selection\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    4. Click the **GitHub** button.\n        - If using GitLab self-managed, then you must [enable the GitHub importer](https://docs.gitlab.com/administration/settings/import_and_export_settings/#configure-allowed-import-sources).\n        - Note that other importers can be initiated in the same way.\n    5. Now you can either:\n        - Authorize with GitHub OAuth: Select **Authorize with GitHub**.\n        - Or, use a GitHub personal access token:\n           - Go to [https://github.com/settings/tokens/new](https://github.com/settings/tokens/new).\n           - In the **Note** field, enter a token description.\n           - Select the repo scope.\n           - Optionally to import collaborators, select the              **read:org** scope.\n           - Click the **Generate token** button.\n           - On the GitLab import page, in the Personal Access Token field, paste the GitHub personal access token.\n    6. Click the **Authenticate** button.\n\n    7. Select the items you wish to migrate.\n\n    8. Select the projects you wish to migrate and to where.\n\n    9. Press the **Import** button.\n\n\n    Now you should have the imported project in your workspace. For additional\n    guidance on migrating from GitHub to GitLab you can watch this video:\n\n\n    \u003C!-- blank line -->\n\n    \u003Cfigure class=\"video_container\">\n      \u003Ciframe src=\"https://www.youtube.com/embed/0Id5oMl1Kqs?si=TQ5HI9aMwtzJMiMi\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n    \u003C/figure>\n\n    \u003C!-- blank line -->\n\n\n    Once you have completed the repository migration, you can set your Jenkins\n    pipeline to leverage the Jenkinsfile within GitLab. This can be done by\n    setting the repository URL via to your newly imported project via the Jenkin\n    pipeline configuration menu:\n\n\n\n    ![Jenkins Pipeline SCM\n    settings](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176020/Blog/mu475liw66abcxbu2g6g.png\n    \"Jenkins Pipeline SCM settings\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    This is useful for the initial repo migration phase and allows you to use\n    both Jenkins and GitLab in parallel, preventing service disruptions while\n    you work on migrating the CI/CD functionality.\n\n\n    Additionally, you can leverage the [GitLab Jenkins\n    plugin](https://plugins.jenkins.io/gitlab-plugin/) to assist with migration.\n    This plugin allows GitLab to trigger and obtain the status of Jenkins\n    builds.\n\n\n    ### Migrating CI/CD pipelines\n\n    Once you have migrated your repositories to GitLab, you can proceed to\n    migrate your Jenkins pipelines to GitLab. This process can be fairly\n    straightforward, but requires an understanding of both Jenkins and GitLab\n    concepts and syntax.\n\n\n    Jenkins provides two different types of syntax for defining pipelines,\n    Declarative and Scripted. In this guide we will be covering migrating from\n    Declarative pipelines since they are the most commonly used.\n\n\n    ### Step-by-step pipeline migration\n\n    In this tutorial we will analyze a Jenkinsfile (Groovy) alongside a GitLab\n    CI/CD configuration file (YAML) that builds, tests, and deploys a\n    microservice written in Golang. We will then proceed to enable the pipeline\n    within GitLab and see its results. The pipeline will:\n\n\n    - Use the golang container image with the **alpine** tag\n\n    - Run a job for building the Golang code into an executable binary\n       - Stores the built executable as an artifact\n    - Run a job to run unit tests\n\n    - Run a job to deploy to staging\n       - Only executes if the commit targets the **staging** branch\n       - Starts after the **test** stage succeeds\n       - Uses the built executable artifact from the earlier job\n\n    Below you can see Jenkins and GitLab pipeline definitions along with\n    descriptive comments. You can see the pipeline in action in the [Meow\n    Migration\n    project](https://gitlab.com/gitlab-da/projects/blogs/meow-migration).\n\n\n    Let's take a look at a Jenkinsfile written in Groovy:\n\n\n    ```shell\n\n    // The top-level of the declarative\n\n    // pipeline.\n\n    pipeline {\n\n      // Defines the default agent to use\n      // when it is not explicitly defined\n      // in a job.\n        agent any\n\n      // Defines the stages that will run\n      // in numerical order. Each stage\n      // only runs one job.\n        stages {\n\n        // Defines the name of the stage\n            stage('build') {\n          // Defines the container image to\n          // use for this job, overwriting\n          // the default 'agent any'.\n          // The Jenkins Docker plugin\n          // must be configured for this\n          // to run.\n                agent { docker 'golang:alpine' }\n\n          // Defines the sequence of steps\n          // to execute when the stage is\n          // run.\n                steps {\n                    sh 'go build -o bin/meow-micro'\n                    sh 'chmod +x bin/meow-micro'\n                }\n\n          // The steps to run after the\n          // stage completes.\n                post {\n                  always {\n\n            // Stores the stage artifacts\n            // generated for use in another\n            // job.\n                    archiveArtifacts artifacts: 'bin/meow-micro'\n                    onlyIfSuccessful: true\n                  }\n                }\n            }\n\n        stage('test') {\n                agent { docker 'golang:alpine' }\n                steps {\n                    sh 'go test .'\n                }\n            }\n\n            stage('deploy') {\n          // Defines conditions which must\n          // be met in order for the job to\n          // execute. In this case the\n          // deploy job will only run on the\n          // staging branch.\n                when {\n                  branch 'staging'\n                }\n                steps {\n                    echo 'Deploying meow-micro to staging'\n            // Uses the artifact stored in\n            // the build stage.\n                    sh './bin/meow-micro'\n                }\n            }\n        }\n    }\n\n    ```\n\n\n    Now, let's see how to create the same functionality in GitLab:\n\n\n    ```text\n\n    # Defines the default image to use\n\n    # when it is not explicitly defined in\n\n    # a job.\n\n    default:\n      image: alpine:latest\n\n    # Defines the order to run the stages.\n\n    # Each stage can have multiple jobs.\n\n    stages:\n      - build\n      - test\n      - deploy\n\n    # Defines the name of the job\n\n    create-binary:\n     # Defines the stage the job will run in\n      stage: build\n     # Defines the container image to use\n     # for this job, overwriting default.\n      image: golang:alpine\n     # Defines the sequence of steps to\n     # execute when the job is run.\n      script:\n        - go build -o bin/meow-micro\n        - chmod +x bin/meow-micro\n     # Stores the job artifacts generated\n     # for use in another job.\n      artifacts:\n        paths:\n          - bin/meow-micro\n        expire_in: 1 week\n\n    unit-tests:\n      stage: test\n      image: golang:alpine\n      script:\n        - go test .\n     # Defines commands to run after the\n     # job.\n     after_script:\n      - echo \"Tests Complete\"\n\n    staging-deploy:\n      stage: deploy\n     # Defines commands to run before the\n     # actual job.\n      before_script:\n        - apk update\n      script:\n        - echo \"Deploying meow-micro to staging environment\"\n        - ./bin/meow-micro\n     # Defines conditions which must be met\n     # in order for this job to execute. In\n     # this case the staging-deploy job will\n     # only run on the staging branch.\n      rules:\n        - if: $CI_COMMIT_BRANCH == 'staging'\n     # Allows the artifact stored in the\n     # build job to be used in this job.\n      artifacts:\n        paths:\n          - bin/meow-micro\n\n    ```\n\n\n    As you may have observed, there are many similarities between both Jenkins\n    and GitLab in terms of syntax, making pipeline migration straightforward.\n    While the above provides a basic example, be sure to read the comprehensive\n    list of [feature and concept\n    comparisons](https://docs.gitlab.com/ci/migration/jenkins/#comparison-of-features-and-concepts)\n    between both tools.\n\n\n    Now that we have an understanding of how to map Jenkins to GitLab we can\n    start creating a pipeline with the same functionality in GitLab. In order to\n    perform the migration of CI/CD, you can go through the following steps:\n\n\n    ##### 1. Open the repository you migrated to GitLab in the section above.\n\n    - On the left sidebar, at the top, select **Search or go to…**.\n\n    - Locate your project.\n\n\n    ##### 2. Open the [Pipeline\n    Editor](https://docs.gitlab.com/ci/pipeline_editor/).\n\n    - On the left sidebar, Select **Build > Pipeline editor**.\n\n\n    ![Pipeline editor\n    menu](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176026/Blog/ecp4jh7epho2oxuegaor.png\n    \"Pipeline editor menu\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    - Click the **Configure pipeline** button.\n\n\n\n    ![Configure pipeline\n    selection](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176029/Blog/nypfh01zhwgvzqc0xz3v.png\n    \"Configure pipeline selection\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    ##### 3. Populate the [.gitlab-ci.yml](https://docs.gitlab.com/ci/yaml/).\n\n    - Add the GitLab CI pipeline code.\n\n\n    ![Pipeline editor\n    input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176031/Blog/nxi6uxxispyyoiiyvxyg.png\n    \"Pipeline editor input\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    - Verify that the syntax is correct.\n\n\n\n    ![Pipeline syntax\n    validation](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176037/Blog/x3d4utfsnymye0lvphtf.png\n    \"Pipeline syntax validation\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    - Visualize the pipeline.\n\n\n\n    ![Pipeline\n    visualization](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176043/Blog/hipzofpyywjxf62edzfv.png\n    \"Pipeline visualization\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    ##### 4. Commit the file to the main branch.\n\n    - Add a commit message.\n\n    - Make sure the branch is set to main.\n\n    - Click the Commit changes button.\n\n\n\n    ![Commit changes\n    dialog](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176048/Blog/nn8bl7rdysabccoycfrk.png\n    \"Commit changes dialog\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    Once the file has been merged, the defined pipeline will kick off. You can\n    go back to your project and [view the\n    pipeline](https://docs.gitlab.com/ci/pipelines/#view-pipelines) in action\n    by selecting it under your project’s **Build > Pipelines** page. Since it\n    was run on the **main** branch, you will see only the **create-binary** and\n    unit-tests jobs; the **staging-deploy** job only runs on the staging branch.\n\n\n\n    ![Pipeline running on main\n    branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176051/Blog/wfb4k8nkzpg28kpf2pzz.png\n    \"Pipeline running on main branch\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    If we create a staging branch, we can see that the following pipeline is\n    initiated.\n\n\n\n    ![Pipeline running on staging\n    branch](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176053/Blog/e2jxedpolaniotgixpby.png\n    \"Pipeline running on staging branch\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    When clicking on a job we can see its output:\n\n\n\n    ![create-binary job\n    output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176056/Blog/fywzwbzkwcvc9zzakilh.png\n    \"create-binary job output\")\n\n\n    \u003Cp>\u003C/p>\n\n\n\n    ![unit-tests job output\n    input](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176061/Blog/ekmpd8ecanwwiena9xi9.png\n    \"unit-tests job output input\")\n\n\n    \u003Cp>\u003C/p>\n\n\n\n    ![staging-deploy job\n    output](https://res.cloudinary.com/about-gitlab-com/image/upload/v1752176065/Blog/h7nqxszy50xdmnvhalfq.png\n    \"staging-deploy job output\")\n\n\n    \u003Cp>\u003C/p>\n\n\n    You can see how the artifact is stored in the create-binary job and used in\n    the staging-deploy job. And that's how easy it is to migrate a pipeline from\n    Jenkins to GitLab!\n\n\n    ### Additional considerations when migrating\n\n    Some helpful considerations we’ve found to make the deployment process more\n    straightforward are as follows:\n\n\n    - Don't try to replicate tasks into GitLab jobs 1:1. Take some inventory and\n    time to understand what the current pipeline is doing, and which problem it\n    is solving.\n\n\n    - Some Jenkins jobs may be too complex to move over to GitLab right away.\n    For this reason, it may be beneficial to use the [GitLab Jenkins\n    plugin](https://plugins.jenkins.io/gitlab-plugin/) to initiate Jenkins\n    pipelines and view their results directly from GitLab. This allows you to\n    slowly migrate certain actions to GitLab until the whole pipeline can be\n    moved.\n\n\n    - Implement [security scanners and code\n    quality](https://docs.gitlab.com/user/application_security/) using\n    built-in templates provided by GitLab from the start. This will allow you to\n    shift security left, reducing the potential for a breach.\n\n    Don't overcomplicate the CI/CD config and try to use every feature advantage\n    at once. Modularize code and implement it in small iterations.\n\n\n    - Implement monitoring and governance from the start.\n\n\n    - Understand that the GitLab Runner (Go) might behave differently than the\n    Jenkins agent (Java). CPU usage and memory consumption might differ — make\n    sure to compare over time.\n\n\n    - Consider investing in auto-scaling mechanisms, and shut down unneeded\n    resources on the weekend, or outside of working hours.\n\n\n    - Modernize application development by containerizing your jobs. Jenkins\n    jobs are not executed on a container today but on a Jenkins agent running as\n    a VM.\n\n\n    While this list is not exhaustive, it does provide a good start on some\n    considerations to take note of. If you need additional help, GitLab provides\n    [professional services](https://about.gitlab.com/get-help/) to support your\n    migration journey.\n\n\n    ### Learn more\n\n    Thanks for reading! I hope this guide has helped you get a clear\n    understanding of why and how to migrate from Jenkins to GitLab. Not\n    convinced? [Give GitLab a try with our free\n    trial](https://about.gitlab.com/free-trial/), and see the value of a\n    DevSecOps platform!\n\n\n    Here are a few resources where you can learn more about GitLab, the benefits\n    of using a DevSecOps platform, and migrating from Jenkins:\n\n\n    - [Migrating from\n    Jenkins](https://docs.gitlab.com/ci/migration/jenkins/)\n\n    - [Planning a\n    migration](https://docs.gitlab.com/ci/migration/plan_a_migration/)\n\n    - [GitLab Project\n    Importers](https://docs.gitlab.com/user/project/import/)\n\n    - [Tutorial: GitHub to GitLab migration the easy\n    way](https://about.gitlab.com/blog/github-to-gitlab-migration-made-easy/)\n\n    - [Video: GitHub to GitLab migration the easy\n    way](https://youtu.be/0Id5oMl1Kqs?feature=shared)\n\n    - [Jenkins to GitLab: The ultimate guide to modernizing your CI/CD\n    environment](https://about.gitlab.com/blog/jenkins-gitlab-ultimate-guide-to-modernizing-cicd-environment/)\n  category: devsecops\n  tags:\n    - CI/CD\n    - DevSecOps\nconfig:\n  slug: jenkins-to-gitlab-migration-made-easy\n  featured: true\n  template: BlogPost\n",{"title":5,"description":17,"ogTitle":5,"ogDescription":17,"noIndex":30,"ogImage":19,"ogUrl":31,"ogSiteName":32,"ogType":33,"canonicalUrls":31},false,"https://about.gitlab.com/blog/jenkins-to-gitlab-migration-made-easy","https://about.gitlab.com","article","en-us/blog/jenkins-to-gitlab-migration-made-easy",[36,11],"cicd",[22,23],"-JsKh_qVJIzEq-S8VoQUF6wQ1AgpUgYvJWUhcVnQgDI",{"data":40},{"logo":41,"freeTrial":46,"sales":51,"login":56,"items":61,"search":369,"minimal":400,"duo":419,"switchNav":428,"pricingDeployment":439},{"config":42},{"href":43,"dataGaName":44,"dataGaLocation":45},"/","gitlab logo","header",{"text":47,"config":48},"Get free trial",{"href":49,"dataGaName":50,"dataGaLocation":45},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":52,"config":53},"Talk to sales",{"href":54,"dataGaName":55,"dataGaLocation":45},"/sales/","sales",{"text":57,"config":58},"Sign in",{"href":59,"dataGaName":60,"dataGaLocation":45},"https://gitlab.com/users/sign_in/","sign in",[62,89,183,188,290,350],{"text":63,"config":64,"cards":66},"Platform",{"dataNavLevelOne":65},"platform",[67,73,81],{"title":63,"description":68,"link":69},"The intelligent orchestration platform for DevSecOps",{"text":70,"config":71},"Explore our Platform",{"href":72,"dataGaName":65,"dataGaLocation":45},"/platform/",{"title":74,"description":75,"link":76},"GitLab Duo Agent Platform","Agentic AI for the entire software lifecycle",{"text":77,"config":78},"Meet GitLab Duo",{"href":79,"dataGaName":80,"dataGaLocation":45},"/gitlab-duo-agent-platform/","gitlab duo agent platform",{"title":82,"description":83,"link":84},"Why GitLab","See the top reasons enterprises choose GitLab",{"text":85,"config":86},"Learn more",{"href":87,"dataGaName":88,"dataGaLocation":45},"/why-gitlab/","why gitlab",{"text":90,"left":14,"config":91,"link":93,"lists":97,"footer":165},"Product",{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":45},"/solutions/",[98,121,144],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":45},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,110,113,117],{"text":22,"config":108},{"href":109,"dataGaLocation":45,"dataGaName":22},"/solutions/continuous-integration/",{"text":74,"config":111},{"href":79,"dataGaLocation":45,"dataGaName":112},"gitlab duo agent platform - product menu",{"text":114,"config":115},"Source Code Management",{"href":116,"dataGaLocation":45,"dataGaName":114},"/solutions/source-code-management/",{"text":118,"config":119},"Automated Software Delivery",{"href":104,"dataGaLocation":45,"dataGaName":120},"Automated software delivery",{"title":122,"description":123,"link":124,"items":129},"Security","Deliver code faster without compromising security",{"config":125},{"href":126,"dataGaName":127,"dataGaLocation":45,"icon":128},"/solutions/application-security-testing/","security and compliance","ShieldCheckLight",[130,134,139],{"text":131,"config":132},"Application Security Testing",{"href":126,"dataGaName":133,"dataGaLocation":45},"Application security testing",{"text":135,"config":136},"Software Supply Chain Security",{"href":137,"dataGaLocation":45,"dataGaName":138},"/solutions/supply-chain/","Software supply chain security",{"text":140,"config":141},"Software Compliance",{"href":142,"dataGaName":143,"dataGaLocation":45},"/solutions/software-compliance/","software compliance",{"title":145,"link":146,"items":151},"Measurement",{"config":147},{"icon":148,"href":149,"dataGaName":150,"dataGaLocation":45},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[152,156,160],{"text":153,"config":154},"Visibility & Measurement",{"href":149,"dataGaLocation":45,"dataGaName":155},"Visibility and Measurement",{"text":157,"config":158},"Value Stream Management",{"href":159,"dataGaLocation":45,"dataGaName":157},"/solutions/value-stream-management/",{"text":161,"config":162},"Analytics & Insights",{"href":163,"dataGaLocation":45,"dataGaName":164},"/solutions/analytics-and-insights/","Analytics and insights",{"title":166,"items":167},"GitLab for",[168,173,178],{"text":169,"config":170},"Enterprise",{"href":171,"dataGaLocation":45,"dataGaName":172},"/enterprise/","enterprise",{"text":174,"config":175},"Small Business",{"href":176,"dataGaLocation":45,"dataGaName":177},"/small-business/","small business",{"text":179,"config":180},"Public Sector",{"href":181,"dataGaLocation":45,"dataGaName":182},"/solutions/public-sector/","public sector",{"text":184,"config":185},"Pricing",{"href":186,"dataGaName":187,"dataGaLocation":45,"dataNavLevelOne":187},"/pricing/","pricing",{"text":189,"config":190,"link":192,"lists":196,"feature":281},"Resources",{"dataNavLevelOne":191},"resources",{"text":193,"config":194},"View all resources",{"href":195,"dataGaName":191,"dataGaLocation":45},"/resources/",[197,230,253],{"title":198,"items":199},"Getting started",[200,205,210,215,220,225],{"text":201,"config":202},"Install",{"href":203,"dataGaName":204,"dataGaLocation":45},"/install/","install",{"text":206,"config":207},"Quick start guides",{"href":208,"dataGaName":209,"dataGaLocation":45},"/get-started/","quick setup checklists",{"text":211,"config":212},"Learn",{"href":213,"dataGaLocation":45,"dataGaName":214},"https://university.gitlab.com/","learn",{"text":216,"config":217},"Product documentation",{"href":218,"dataGaName":219,"dataGaLocation":45},"https://docs.gitlab.com/","product documentation",{"text":221,"config":222},"Best practice videos",{"href":223,"dataGaName":224,"dataGaLocation":45},"/getting-started-videos/","best practice videos",{"text":226,"config":227},"Integrations",{"href":228,"dataGaName":229,"dataGaLocation":45},"/integrations/","integrations",{"title":231,"items":232},"Discover",[233,238,243,248],{"text":234,"config":235},"Customer success stories",{"href":236,"dataGaName":237,"dataGaLocation":45},"/customers/","customer success stories",{"text":239,"config":240},"Blog",{"href":241,"dataGaName":242,"dataGaLocation":45},"/blog/","blog",{"text":244,"config":245},"The Source",{"href":246,"dataGaName":247,"dataGaLocation":45},"/the-source/","the source",{"text":249,"config":250},"Remote",{"href":251,"dataGaName":252,"dataGaLocation":45},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"title":254,"items":255},"Connect",[256,261,266,271,276],{"text":257,"config":258},"GitLab Services",{"href":259,"dataGaName":260,"dataGaLocation":45},"/services/","services",{"text":262,"config":263},"Community",{"href":264,"dataGaName":265,"dataGaLocation":45},"/community/","community",{"text":267,"config":268},"Forum",{"href":269,"dataGaName":270,"dataGaLocation":45},"https://forum.gitlab.com/","forum",{"text":272,"config":273},"Events",{"href":274,"dataGaName":275,"dataGaLocation":45},"/events/","events",{"text":277,"config":278},"Partners",{"href":279,"dataGaName":280,"dataGaLocation":45},"/partners/","partners",{"textColor":282,"title":283,"text":284,"link":285},"#000","What’s new in GitLab","Stay updated with our latest features and improvements.",{"text":286,"config":287},"Read the latest",{"href":288,"dataGaName":289,"dataGaLocation":45},"/releases/whats-new/","whats new",{"text":291,"config":292,"lists":294},"Company",{"dataNavLevelOne":293},"company",[295],{"items":296},[297,302,308,310,315,320,325,330,335,340,345],{"text":298,"config":299},"About",{"href":300,"dataGaName":301,"dataGaLocation":45},"/company/","about",{"text":303,"config":304,"footerGa":307},"Jobs",{"href":305,"dataGaName":306,"dataGaLocation":45},"/jobs/","jobs",{"dataGaName":306},{"text":272,"config":309},{"href":274,"dataGaName":275,"dataGaLocation":45},{"text":311,"config":312},"Leadership",{"href":313,"dataGaName":314,"dataGaLocation":45},"/company/team/e-group/","leadership",{"text":316,"config":317},"Team",{"href":318,"dataGaName":319,"dataGaLocation":45},"/company/team/","team",{"text":321,"config":322},"Handbook",{"href":323,"dataGaName":324,"dataGaLocation":45},"https://handbook.gitlab.com/","handbook",{"text":326,"config":327},"Investor relations",{"href":328,"dataGaName":329,"dataGaLocation":45},"https://ir.gitlab.com/","investor relations",{"text":331,"config":332},"Trust Center",{"href":333,"dataGaName":334,"dataGaLocation":45},"/security/","trust center",{"text":336,"config":337},"AI Transparency Center",{"href":338,"dataGaName":339,"dataGaLocation":45},"/ai-transparency-center/","ai transparency center",{"text":341,"config":342},"Newsletter",{"href":343,"dataGaName":344,"dataGaLocation":45},"/company/contact/#contact-forms","newsletter",{"text":346,"config":347},"Press",{"href":348,"dataGaName":349,"dataGaLocation":45},"/press/","press",{"text":351,"config":352,"lists":353},"Contact us",{"dataNavLevelOne":293},[354],{"items":355},[356,359,364],{"text":52,"config":357},{"href":54,"dataGaName":358,"dataGaLocation":45},"talk to sales",{"text":360,"config":361},"Support portal",{"href":362,"dataGaName":363,"dataGaLocation":45},"https://support.gitlab.com","support portal",{"text":365,"config":366},"Customer portal",{"href":367,"dataGaName":368,"dataGaLocation":45},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":370,"login":371,"suggestions":378},"Close",{"text":372,"link":373},"To search repositories and projects, login to",{"text":374,"config":375},"gitlab.com",{"href":59,"dataGaName":376,"dataGaLocation":377},"search login","search",{"text":379,"default":380},"Suggestions",[381,383,387,389,393,397],{"text":74,"config":382},{"href":79,"dataGaName":74,"dataGaLocation":377},{"text":384,"config":385},"Code Suggestions (AI)",{"href":386,"dataGaName":384,"dataGaLocation":377},"/solutions/code-suggestions/",{"text":22,"config":388},{"href":109,"dataGaName":22,"dataGaLocation":377},{"text":390,"config":391},"GitLab on AWS",{"href":392,"dataGaName":390,"dataGaLocation":377},"/partners/technology-partners/aws/",{"text":394,"config":395},"GitLab on Google Cloud",{"href":396,"dataGaName":394,"dataGaLocation":377},"/partners/technology-partners/google-cloud-platform/",{"text":398,"config":399},"Why GitLab?",{"href":87,"dataGaName":398,"dataGaLocation":377},{"freeTrial":401,"mobileIcon":406,"desktopIcon":411,"secondaryButton":414},{"text":402,"config":403},"Start free trial",{"href":404,"dataGaName":50,"dataGaLocation":405},"https://gitlab.com/-/trials/new/","nav",{"altText":407,"config":408},"Gitlab Icon",{"src":409,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":407,"config":412},{"src":413,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":415,"config":416},"Get Started",{"href":417,"dataGaName":418,"dataGaLocation":405},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/get-started/","get started",{"freeTrial":420,"mobileIcon":424,"desktopIcon":426},{"text":421,"config":422},"Learn more about GitLab Duo",{"href":79,"dataGaName":423,"dataGaLocation":405},"gitlab duo",{"altText":407,"config":425},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":427},{"src":413,"dataGaName":410,"dataGaLocation":405},{"button":429,"mobileIcon":434,"desktopIcon":436},{"text":430,"config":431},"/switch",{"href":432,"dataGaName":433,"dataGaLocation":405},"#contact","switch",{"altText":407,"config":435},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":437},{"src":438,"dataGaName":410,"dataGaLocation":405},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1773335277/ohhpiuoxoldryzrnhfrh.png",{"freeTrial":440,"mobileIcon":445,"desktopIcon":447},{"text":441,"config":442},"Back to pricing",{"href":186,"dataGaName":443,"dataGaLocation":405,"icon":444},"back to pricing","GoBack",{"altText":407,"config":446},{"src":409,"dataGaName":410,"dataGaLocation":405},{"altText":407,"config":448},{"src":413,"dataGaName":410,"dataGaLocation":405},{"title":450,"button":451,"config":456},"See how agentic AI transforms software delivery",{"text":452,"config":453},"Watch GitLab Transcend now",{"href":454,"dataGaName":455,"dataGaLocation":45},"/events/transcend/virtual/","transcend event",{"layout":457,"icon":458,"disabled":14},"release","AiStar",{"data":460},{"text":461,"source":462,"edit":468,"contribute":473,"config":478,"items":483,"minimal":687},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":463,"config":464},"View page source",{"href":465,"dataGaName":466,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":469,"config":470},"Edit this page",{"href":471,"dataGaName":472,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":474,"config":475},"Please contribute",{"href":476,"dataGaName":477,"dataGaLocation":467},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":479,"facebook":480,"youtube":481,"linkedin":482},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[484,531,582,626,653],{"title":184,"links":485,"subMenu":500},[486,490,495],{"text":487,"config":488},"View plans",{"href":186,"dataGaName":489,"dataGaLocation":467},"view plans",{"text":491,"config":492},"Why Premium?",{"href":493,"dataGaName":494,"dataGaLocation":467},"/pricing/premium/","why premium",{"text":496,"config":497},"Why Ultimate?",{"href":498,"dataGaName":499,"dataGaLocation":467},"/pricing/ultimate/","why ultimate",[501],{"title":502,"links":503},"Contact Us",[504,507,509,511,516,521,526],{"text":505,"config":506},"Contact sales",{"href":54,"dataGaName":55,"dataGaLocation":467},{"text":360,"config":508},{"href":362,"dataGaName":363,"dataGaLocation":467},{"text":365,"config":510},{"href":367,"dataGaName":368,"dataGaLocation":467},{"text":512,"config":513},"Status",{"href":514,"dataGaName":515,"dataGaLocation":467},"https://status.gitlab.com/","status",{"text":517,"config":518},"Terms of use",{"href":519,"dataGaName":520,"dataGaLocation":467},"/terms/","terms of use",{"text":522,"config":523},"Privacy statement",{"href":524,"dataGaName":525,"dataGaLocation":467},"/privacy/","privacy statement",{"text":527,"config":528},"Cookie preferences",{"dataGaName":529,"dataGaLocation":467,"id":530,"isOneTrustButton":14},"cookie preferences","ot-sdk-btn",{"title":90,"links":532,"subMenu":541},[533,537],{"text":534,"config":535},"DevSecOps platform",{"href":72,"dataGaName":536,"dataGaLocation":467},"devsecops platform",{"text":538,"config":539},"AI-Assisted Development",{"href":79,"dataGaName":540,"dataGaLocation":467},"ai-assisted development",[542],{"title":543,"links":544},"Topics",[545,549,554,559,564,567,572,577],{"text":546,"config":547},"CICD",{"href":548,"dataGaName":36,"dataGaLocation":467},"/topics/ci-cd/",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":467},"/topics/gitops/","gitops",{"text":555,"config":556},"DevOps",{"href":557,"dataGaName":558,"dataGaLocation":467},"/topics/devops/","devops",{"text":560,"config":561},"Version Control",{"href":562,"dataGaName":563,"dataGaLocation":467},"/topics/version-control/","version control",{"text":23,"config":565},{"href":566,"dataGaName":11,"dataGaLocation":467},"/topics/devsecops/",{"text":568,"config":569},"Cloud Native",{"href":570,"dataGaName":571,"dataGaLocation":467},"/topics/cloud-native/","cloud native",{"text":573,"config":574},"AI for Coding",{"href":575,"dataGaName":576,"dataGaLocation":467},"/topics/devops/ai-for-coding/","ai for coding",{"text":578,"config":579},"Agentic AI",{"href":580,"dataGaName":581,"dataGaLocation":467},"/topics/agentic-ai/","agentic ai",{"title":583,"links":584},"Solutions",[585,587,589,594,598,601,605,608,610,613,616,621],{"text":131,"config":586},{"href":126,"dataGaName":131,"dataGaLocation":467},{"text":120,"config":588},{"href":104,"dataGaName":105,"dataGaLocation":467},{"text":590,"config":591},"Agile development",{"href":592,"dataGaName":593,"dataGaLocation":467},"/solutions/agile-delivery/","agile delivery",{"text":595,"config":596},"SCM",{"href":116,"dataGaName":597,"dataGaLocation":467},"source code management",{"text":546,"config":599},{"href":109,"dataGaName":600,"dataGaLocation":467},"continuous integration & delivery",{"text":602,"config":603},"Value stream management",{"href":159,"dataGaName":604,"dataGaLocation":467},"value stream management",{"text":550,"config":606},{"href":607,"dataGaName":553,"dataGaLocation":467},"/solutions/gitops/",{"text":169,"config":609},{"href":171,"dataGaName":172,"dataGaLocation":467},{"text":611,"config":612},"Small business",{"href":176,"dataGaName":177,"dataGaLocation":467},{"text":614,"config":615},"Public sector",{"href":181,"dataGaName":182,"dataGaLocation":467},{"text":617,"config":618},"Education",{"href":619,"dataGaName":620,"dataGaLocation":467},"/solutions/education/","education",{"text":622,"config":623},"Financial services",{"href":624,"dataGaName":625,"dataGaLocation":467},"/solutions/finance/","financial services",{"title":189,"links":627},[628,630,632,634,637,639,641,643,645,647,649,651],{"text":201,"config":629},{"href":203,"dataGaName":204,"dataGaLocation":467},{"text":206,"config":631},{"href":208,"dataGaName":209,"dataGaLocation":467},{"text":211,"config":633},{"href":213,"dataGaName":214,"dataGaLocation":467},{"text":216,"config":635},{"href":218,"dataGaName":636,"dataGaLocation":467},"docs",{"text":239,"config":638},{"href":241,"dataGaName":242,"dataGaLocation":467},{"text":234,"config":640},{"href":236,"dataGaName":237,"dataGaLocation":467},{"text":249,"config":642},{"href":251,"dataGaName":252,"dataGaLocation":467},{"text":257,"config":644},{"href":259,"dataGaName":260,"dataGaLocation":467},{"text":262,"config":646},{"href":264,"dataGaName":265,"dataGaLocation":467},{"text":267,"config":648},{"href":269,"dataGaName":270,"dataGaLocation":467},{"text":272,"config":650},{"href":274,"dataGaName":275,"dataGaLocation":467},{"text":277,"config":652},{"href":279,"dataGaName":280,"dataGaLocation":467},{"title":291,"links":654},[655,657,659,661,663,665,667,671,676,678,680,682],{"text":298,"config":656},{"href":300,"dataGaName":293,"dataGaLocation":467},{"text":303,"config":658},{"href":305,"dataGaName":306,"dataGaLocation":467},{"text":311,"config":660},{"href":313,"dataGaName":314,"dataGaLocation":467},{"text":316,"config":662},{"href":318,"dataGaName":319,"dataGaLocation":467},{"text":321,"config":664},{"href":323,"dataGaName":324,"dataGaLocation":467},{"text":326,"config":666},{"href":328,"dataGaName":329,"dataGaLocation":467},{"text":668,"config":669},"Sustainability",{"href":670,"dataGaName":668,"dataGaLocation":467},"/sustainability/",{"text":672,"config":673},"Diversity, inclusion and belonging (DIB)",{"href":674,"dataGaName":675,"dataGaLocation":467},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":331,"config":677},{"href":333,"dataGaName":334,"dataGaLocation":467},{"text":341,"config":679},{"href":343,"dataGaName":344,"dataGaLocation":467},{"text":346,"config":681},{"href":348,"dataGaName":349,"dataGaLocation":467},{"text":683,"config":684},"Modern Slavery Transparency Statement",{"href":685,"dataGaName":686,"dataGaLocation":467},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"items":688},[689,692,695],{"text":690,"config":691},"Terms",{"href":519,"dataGaName":520,"dataGaLocation":467},{"text":693,"config":694},"Cookies",{"dataGaName":529,"dataGaLocation":467,"id":530,"isOneTrustButton":14},{"text":696,"config":697},"Privacy",{"href":524,"dataGaName":525,"dataGaLocation":467},[699],{"id":700,"title":9,"body":25,"config":701,"content":703,"description":25,"extension":24,"meta":707,"navigation":14,"path":708,"seo":709,"stem":710,"__hash__":711},"blogAuthors/en-us/blog/authors/fernando-diaz.yml",{"template":702},"BlogAuthor",{"name":9,"config":704},{"headshot":705,"ctfId":706},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659556/Blog/Author%20Headshots/fern_diaz.png","fjdiaz",{},"/en-us/blog/authors/fernando-diaz",{},"en-us/blog/authors/fernando-diaz","lxRJIOydP4_yzYZvsPcuQevP9AYAKREF7i8QmmdnOWc",[713,726,741],{"content":714,"config":724},{"title":715,"description":716,"authors":717,"heroImage":719,"date":720,"body":721,"category":11,"tags":722},"Teaching software development the easy way using GitLab","Learn how University of Washington lecturer Stephen G. Dame uses GitLab for Education to manage student assignments, distribute course materials, and provide inline code feedback at scale.\n",[718],"Rod Burns","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749659537/Blog/Hero%20Images/display-article-image-0679-1800x945-fy26.png","2026-04-29","For instructors teaching software development, one of the biggest logistical challenges is assignment distribution and feedback at scale. How do you give large groups of students access to course materials, keep solution code private, and still deliver meaningful, contextual feedback without lots of administrative overhead?\n\nThe **[GitLab for Education program](https://about.gitlab.com/solutions/education/)** provides qualifying institutions with free access to **GitLab Ultimate**, enabling instructors to build professional-grade workflows that mirror real-world software development environments. In this article, you'll learn how Stephen G. Dame, a lecturer in the Computing and Software Systems department at the University of Washington, Bothell, uses simple workflows in GitLab to manage everything from course materials to student feedback across multiple classes.\n\n## From aerospace to academia: Bringing GitLab to the classroom\n\nDame came to academia with years of experience as a chief software engineer at Boeing Commercial Airplanes, where GitLab was used for aerospace projects. As an adjunct professor, he became an early advocate for GitLab within the university, joining the GitLab for Education program to access the full feature set needed to run structured, scalable course workflows.\n\n> **\"GitLab provides the greatest way to organize multiple classes, student assignments, lectures, and code samples through the use of Groups and Subgroups, which I found to be unique to GitLab compared to other repository platforms.\"**\n>\n> - Stephen G. Dame, University of Washington, Bothell\n\n## Set up groups: Build the right structure before writing a line of code\n\nThe foundation of an effective GitLab-based course is a well-planned group hierarchy. GitLab's **[Groups and Subgroups](https://docs.gitlab.com/tutorials/manage_user/#create-the-organization-parent-group-and-subgroups)** allow instructors to model the natural structure of a university department institution, course, and role with precise, inheritable permissions at every level.\n\nDame's structure places the university at the root (`UWTeaching`), with each course occupying its own subgroup (e.g. `css430`). Within each course sit repositories for `lecture-materials` and `code`, alongside dedicated Subgroups for `students` and `graders`. Instructor materials remain private, while student and grader subgroups are configured with controlled permissions so that assignment briefs and solutions are visible only to the right people.\n\n![Screenshot of GitLab group hierarchy — institution, course subgroup, and per-student subgroups](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777463673/dpxfnitv76pdmvcqtgag.png)\n\nPermissions cascade downward through the hierarchy via **Manage > Members**, allowing Dame to add students to a course's `students` subgroup with `Reporter` access and an expiration date tied to the end of the academic quarter. Students can clone and pull from assignment repositories but cannot push — keeping solution code firmly under instructor control.\n\nStudents are guided to set up SSH keys across all their working environments (local machines, cloud shells, virtual machines) so they can clone repositories and receive weekly updates via `git pull`. They copy relevant code into their own private repositories to manage their own version history.\n\n**Tip for large classes:** For larger cohorts, adding students by hand is impractical. GitLab's REST API lets you automate subgroup creation and membership from a list of usernames. Below is a sample Python script that handles this:\n\n```python\n    import gitlab\n    from datetime import datetime\n\n    # Connect to your GitLab instance\n    gl = gitlab.Gitlab('https://gitlab.com', private_token='YOUR_PRIVATE_TOKEN')\n\n    # Target parent group ID (e.g., the ID for \"css430 > students\")\n    parent_group_id = 12345678\n\n    # Set expiration: typically the beginning of the next month after quarter end\n    expiry_date = '2025-01-01'\n\n    # List of collected student usernames\n    student_list = ['alice_css430', 'bob_css430', 'carol_css430', 'dave_css430', 'eve_css430']\n\n    for username in student_list:\n        try:\n            # 1. Create a personal subgroup for the student\n            subgroup = gl.groups.create({\n                'name': username,\n                'path': username,\n                'parent_id': parent_group_id,\n                'visibility': 'private'\n            })\n\n            # 2. Add student to the new subgroup with Expiration\n            user = gl.users.list(username=username)[0]\n            subgroup.members.create({\n                'user_id': user.id,\n                'access_level': gitlab.const.REPORTER_ACCESS,\n                'expires_at': expiry_date\n            })\n            print(f\"Success: Subgroup created and student added for {username}\")\n        except Exception as e:\n            print(f\"Error processing {username}: {e}\")\n```\nThere is also an [open source project that automates class management](https://gitlab.com/edu-docs/class-management-automation) published by GitLab that provides additional tooling for this workflow.\n## Give feedback where the work actually lives\n\nOnce the structure is in place, the feedback workflow is where GitLab's value becomes most apparent to students. Dame asks students to submit assignments by opening a **[merge request](https://docs.gitlab.com/user/project/merge_requests/)** in their repository. This gives instructors an immediate, clean diff of everything the student has written.\n![A GitLab merge request showing inline code comment function for an instructor](https://res.cloudinary.com/about-gitlab-com/image/upload/v1777467468/icclzyglbkwlvfysggbi.png)\nInstructors can click any line of code and leave an **inline comment** — not just flagging what is wrong, but explaining why, and pointing to what to look at next. Students receive this feedback in direct context with their code, which is far more actionable than a comment at the bottom of a submitted document.\n\n## Join GitLab for Education\n\nSetting up your first GitLab assignment takes some initial effort, but once the structure is in place it largely runs itself. The real payoff goes beyond organization: Students graduate having worked daily in an environment that mirrors professional software development, building habits around [version control](https://about.gitlab.com/topics/version-control/) and [code review](https://docs.gitlab.com/development/code_review/) rather than learning them as abstract concepts.\n\nIf you are just getting started, keep it simple. Begin with a single course group, one assignment template, and a basic pipeline. The structure will grow naturally alongside your confidence with the platform.\n\nMake sure to **[sign up for GitLab for Education](https://about.gitlab.com/solutions/education/join/)** so that you and your students can access all top-tier features, including unlimited reviewers on merge requests, additional compute minutes, and expanded storage.\n\n> [Apply to the GitLab for Education program today](https://about.gitlab.com/solutions/education/join/).",[620,723],"open source",{"featured":30,"template":15,"slug":725},"teaching-software-development-the-easy-way-using-gitlab",{"content":727,"config":739},{"description":728,"authors":729,"heroImage":731,"date":732,"title":733,"body":734,"category":11,"tags":735},"AI-generated code is 34% of development work. Discover how to balance productivity gains with quality, reliability, and security.",[730],"Manav Khurana","https://res.cloudinary.com/about-gitlab-com/image/upload/v1767982271/e9ogyosmuummq7j65zqg.png","2026-01-08","AI is reshaping DevSecOps: Attend GitLab Transcend to see what’s next","AI promises a step change in innovation velocity, but most software teams are hitting a wall. According to our latest [Global DevSecOps Report](https://about.gitlab.com/developer-survey/), AI-generated code now accounts for 34% of all development work. Yet 70% of DevSecOps professionals report that AI is making compliance management more difficult, and 76% say agentic AI will create unprecedented security challenges.\n\nThis is the AI paradox: AI accelerates coding, but software delivery slows down as teams struggle to test, secure, and deploy all that code.\n\n## Productivity gains meet workflow bottlenecks\nThe problem isn't AI itself. It's how software gets built today. The traditional DevSecOps lifecycle contains hundreds of small tasks that developers must navigate manually: updating tickets, running tests, requesting reviews, waiting for approvals, fixing merge conflicts, addressing security findings. These tasks drain an average of seven hours per week from every team member, according to our research.\n\nDevelopment teams are producing code faster than ever, but that code still crawls through fragmented toolchains, manual handoffs, and disconnected processes. In fact, 60% of DevSecOps teams use more than five tools for software development overall, and 49% use more than five AI tools. This fragmentation creates collaboration barriers, with 94% of DevSecOps professionals experiencing factors that limit collaboration in the software development lifecycle.\n\nThe answer isn't more tools. It's intelligent orchestration that brings software teams and their AI agents together across projects and release cycles, with enterprise-grade security, governance, and compliance built in.\n\n## Seeking deeper human-AI partnerships\nDevSecOps professionals don't want AI to take over — they want reliable partnerships. The vast majority (82%) say using agentic AI would increase their job satisfaction, and 43% envision an ideal future with a 50/50 split between human and AI contributions. They're ready to trust AI with 37% of their daily tasks without human review, particularly for documentation, test writing, and code reviews.\n\nWhat we heard resoundingly from DevSecOps professionals is that AI won't replace them; rather, it will fundamentally reshape their roles. 83% of DevSecOps professionals believe AI will significantly change their work within five years, and notably, 76% think this will create more engineering jobs, not fewer. As coding becomes easier with AI, engineers who can architect systems, ensure quality, and apply business context will be in high demand.\n\nCritically, 88% agree there are essential human qualities that AI will never fully replace, including creativity, innovation, collaboration, and strategic vision.\n\nSo how can organizations bridge the gap between AI’s promise and the reality of fragmented workflows?\n\n## Join us at GitLab Transcend: Explore how to drive real value with agentic AI\nOn February 10, 2026, GitLab will be hosting Transcend, where we'll reveal how intelligent orchestration transforms AI-powered software development. You'll get a first look at GitLab's upcoming product roadmap and learn how teams are solving real-world challenges by modernizing development workflows with AI.\n\nOrganizations winning in this new era balance AI adoption with security, compliance, and platform consolidation. AI offers genuine productivity gains when implemented thoughtfully — not by replacing human developers, but by freeing DevSecOps professionals to focus on strategic thinking and creative innovation.\n\n[Register for Transcend today](https://about.gitlab.com/events/transcend/virtual/) to secure your spot and discover how intelligent orchestration can help your software teams stay in flow.",[736,737,738],"AI/ML","DevOps platform","security",{"featured":14,"template":15,"slug":740},"ai-is-reshaping-devsecops-attend-gitlab-transcend-to-see-whats-next",{"content":742,"config":753},{"title":743,"description":744,"authors":745,"heroImage":747,"date":748,"body":749,"category":11,"tags":750},"Atlassian ending Data Center as GitLab maintains deployment choice","As Atlassian transitions Data Center customers to cloud-only, GitLab presents a menu of deployment choices that map to business needs.",[746],"Emilio Salvador","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098354/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%281%29_5XrohmuWBNuqL89BxVUzWm_1750098354056.png","2025-10-07","Change is never easy, especially when it's not your choice. Atlassian's announcement that [all Data Center products will reach end-of-life by March 28, 2029](https://www.atlassian.com/blog/announcements/atlassian-ascend), means thousands of organizations must now reconsider their DevSecOps deployment and infrastructure. But you don't have to settle for deployment options that don't fit your needs. GitLab maintains your freedom to choose — whether you need self-managed for compliance, cloud for convenience, or hybrid for flexibility — all within a single AI-powered DevSecOps platform that respects your requirements.\n\nWhile other vendors force migrations to cloud-only architectures, GitLab remains committed to supporting the deployment choices that match your business needs. Whether you're managing sensitive government data, operating in air-gapped environments, or simply prefer the control of self-managed deployments, we understand that one size doesn't fit all.\n\n## The cloud isn't the answer for everyone\n\nFor the many companies that invested millions of dollars in Data Center deployments, including those that migrated to Data Center [after its Server products were discontinued](https://about.gitlab.com/blog/atlassian-server-ending-move-to-a-single-devsecops-platform/), this announcement represents more than a product sunset. It signals a fundamental shift away from customer-centric architecture choices, forcing enterprises into difficult positions: accept a deployment model that doesn't fit their needs, or find a vendor that respects their requirements.\n\nMany of the organizations requiring self-managed deployments represent some of the world's most important organizations: healthcare systems protecting patient data, financial institutions managing trillions in assets, government agencies safeguarding national security, and defense contractors operating in air-gapped environments.\n\nThese organizations don't choose self-managed deployments for convenience; they choose them for compliance, security, and sovereignty requirements that cloud-only architectures simply cannot meet. Organizations operating in closed environments with restricted or no internet access aren't exceptions — they represent a significant portion of enterprise customers across various industries.\n\n![GitLab vs. Atlassian comparison table](https://res.cloudinary.com/about-gitlab-com/image/upload/v1759928476/ynl7wwmkh5xyqhszv46m.jpg)\n\n## The real cost of forced cloud migration goes beyond dollars\n\nWhile cloud-only vendors frame mandatory migrations as \"upgrades,\" organizations face substantial challenges beyond simple financial costs:\n\n* **Lost integration capabilities:** Years of custom integrations with legacy systems, carefully crafted workflows, and enterprise-specific automations become obsolete. Organizations with deep integrations to legacy systems often find cloud migration technically infeasible.\n\n* **Regulatory constraints:** For organizations in regulated industries, cloud migration isn't just complex — it's often not permitted. Data residency requirements, air-gapped environments, and strict regulatory frameworks don't bend to vendor preferences. The absence of single-tenant solutions in many cloud-only approaches creates insurmountable compliance barriers.\n\n* **Productivity impacts:** Cloud-only architectures often require juggling multiple products: separate tools for planning, code management, CI/CD, and documentation. Each tool means another context switch, another integration to maintain, another potential point of failure. GitLab research shows [30% of developers spend at least 50% of their job maintaining and/or integrating their DevSecOps toolchain](https://about.gitlab.com/developer-survey/). Fragmented architectures exacerbate this challenge rather than solving it.\n\n## GitLab offers choice, commitment, and consolidation\n\nEnterprise customers deserve a trustworthy technology partner. That's why we've committed to supporting a range of deployment options — whether you need on-premises for compliance, hybrid for flexibility, or cloud for convenience, the choice remains yours. That commitment continues with [GitLab Duo](https://about.gitlab.com/gitlab-duo-agent-platform/), our AI solution that supports developers at every stage of their workflow.\n\nBut we offer more than just deployment flexibility. While other vendors might force you to cobble together their products into a fragmented toolchain, GitLab provides everything in a **comprehensive AI-native DevSecOps platform**. Source code management, CI/CD, security scanning, Agile planning, and documentation are all managed within a single application and a single vendor relationship.\n\nThis isn't theoretical. When Airbus and [Iron Mountain](https://about.gitlab.com/customers/iron-mountain/) evaluated their existing fragmented toolchains, they consistently identified challenges: poor user experience, missing functionalities like built-in security scanning and review apps, and management complexity from plugin troubleshooting. **These aren't minor challenges; they're major blockers for modern software delivery.**\n\n## Your migration path: Simpler than you think\n\nWe've helped thousands of organizations migrate from other vendors, and we've built the tools and expertise to make your transition smooth:\n\n* **Automated migration tools:** Our [Bitbucket Server importer](https://docs.gitlab.com/user/import/bitbucket_server/) brings over repositories, pull requests, comments, and even Large File Storage (LFS) objects. For Jira, our [built-in importer](https://docs.gitlab.com/user/project/import/jira/) handles issues, descriptions, and labels, with professional services available for complex migrations.\n\n* **Proven at scale:** A 500 GiB repository with 13,000 pull requests, 10,000 branches, and 7,000 tags is likely to [take just 8 hours to migrate](https://docs.gitlab.com/user/import/bitbucket_server/) from Bitbucket to GitLab using parallel processing.\n\n* **Immediate ROI:** A [Forrester Consulting Total Economic Impact™ study commissioned by GitLab](https://about.gitlab.com/resources/study-forrester-tei-gitlab-ultimate/) found that investing in GitLab Ultimate confirms these benefits translate to real bottom-line impact, with a three-year 483% ROI, 5x time saved in security related activities, and 25% savings in software toolchain costs.\n\n## Start your journey to a unified DevSecOps platform\n\nForward-thinking organizations aren't waiting for vendor-mandated deadlines. They're evaluating alternatives now, while they have time to migrate thoughtfully to platforms that protect their investments and deliver on promises.\n\nOrganizations invest in self-managed deployments because they need control, compliance, and customization. When vendors deprecate these capabilities, they remove not just features but the fundamental ability to choose environments matching business requirements.\n\nModern DevSecOps platforms should offer complete functionality that respects deployment needs, consolidates toolchains, and accelerates software delivery, without forcing compromises on security or data sovereignty.\n\n[Talk to our sales team](https://about.gitlab.com/sales/) today about your migration options, or explore our [comprehensive migration resources](https://about.gitlab.com/move-to-gitlab-from-atlassian/) to see how thousands of organizations have already made the switch.\n\nYou also can [try GitLab Ultimate with GitLab Duo Enterprise](https://about.gitlab.com/free-trial/devsecops/) for free for 30 days to see what a unified DevSecOps platform can do for your organization.",[571,23,751,752],"product","features",{"featured":14,"template":15,"slug":754},"atlassian-ending-data-center-as-gitlab-maintains-deployment-choice",{"promotions":756},[757,771,782,793],{"id":758,"categories":759,"header":761,"text":762,"button":763,"image":768},"ai-modernization",[760],"ai-ml","Is AI achieving its promise at scale?","Quiz will take 5 minutes or less",{"text":764,"config":765},"Get your AI maturity score",{"href":766,"dataGaName":767,"dataGaLocation":242},"/assessments/ai-modernization-assessment/","modernization assessment",{"config":769},{"src":770},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/qix0m7kwnd8x2fh1zq49.png",{"id":772,"categories":773,"header":774,"text":762,"button":775,"image":779},"devops-modernization",[751,11],"Are you just managing tools or shipping innovation?",{"text":776,"config":777},"Get your DevOps maturity score",{"href":778,"dataGaName":767,"dataGaLocation":242},"/assessments/devops-modernization-assessment/",{"config":780},{"src":781},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138785/eg818fmakweyuznttgid.png",{"id":783,"categories":784,"header":785,"text":762,"button":786,"image":790},"security-modernization",[738],"Are you trading speed for security?",{"text":787,"config":788},"Get your security maturity score",{"href":789,"dataGaName":767,"dataGaLocation":242},"/assessments/security-modernization-assessment/",{"config":791},{"src":792},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1772138786/p4pbqd9nnjejg5ds6mdk.png",{"id":794,"paths":795,"header":798,"text":799,"button":800,"image":805},"github-azure-migration",[796,797],"migration-from-azure-devops-to-gitlab","integrating-azure-devops-scm-and-gitlab","Is your team ready for GitHub's Azure move?","GitHub is already rebuilding around Azure. Find out what it means for you.",{"text":801,"config":802},"See how GitLab compares to GitHub",{"href":803,"dataGaName":804,"dataGaLocation":242},"/compare/gitlab-vs-github/github-azure-migration/","github azure migration",{"config":806},{"src":781},{"header":808,"blurb":809,"button":810,"secondaryButton":815},"Start building faster today","See what your team can do with the intelligent orchestration platform for DevSecOps.\n",{"text":811,"config":812},"Get your free trial",{"href":813,"dataGaName":50,"dataGaLocation":814},"https://gitlab.com/-/trial_registrations/new?glm_content=default-saas-trial&glm_source=about.gitlab.com/","feature",{"text":505,"config":816},{"href":54,"dataGaName":55,"dataGaLocation":814},1777493605191]