---
title: "Thinking about moving to GitLab? Here are 5 reasons why you should."
author: Aricka Flowers
author_gitlab: atflowers
author_twitter: ArickaFlowers
categories: company
image_title: '/images/blogimages/moving-to-gitlab-cover.png'
description: "Inspired by #movingtogitlab? We've put together our top reasons to give it a try."
twitter_text: "Here are the top 5 reasons why developers should move to @gitlab"
---
We've been getting a lot of questions about what makes GitLab great and worthy of developers’ business and, most importantly, trust. So we decided to take some time to list out the top five reasons to [move to GitLab](/community/moving-to-gitlab/):
## 1. It's the only single application for the entire Devops cycle
GitLab is the first application built to cover all stages of the DevOps cycle. This means product, development, QA, and Ops teams can all work together concurrently, making the software development lifecycle three times faster. Built-in [continuous integration and continuous delivery features](/product/continuous-integration/) make it seamless to go from a code change to a running pipeline. On top of that, GitLab has project management, issue tracking, and free private repository hosting to make it easier to plan and manage your projects. Because GitLab is open, it has great integrations with many other tools, including container orchestration tools like [Kubernetes](/solutions/kubernetes/).
{::options parse_block_html="false" /}
Okay I get it. @GitLab's product leapfrogged GitHub. I'm shocked how incredibly nice, thoughtful and well designed it is. Fantastic built-in tools -- incredible Kubernetes support, built-in CI/CD, security testing, project management and support features, etc. #MovingToGitLab
## 2. Security is built in
We're keenly aware that security is critical in software development, and too often security is at the end of the SDLC. In GitLab, security is first class. Security checks are built into merge requests (MRs), with problems being reported directly in pipelines and MRs. Some of our integrated security features include:
* Dependency scanning
* Static Application Security Testing (SAST)
* Dynamic Application Security Testing
* Container scanning
In GitLab, every code change can be scanned automatically.
{::options parse_block_html="false" /}
Today I moved all my work related repositories to @gitlab, I have to admit, I wish I did it way before. Gitlab has everything in one package, groups, boards, auto dev ops. Quite impressed.
## 3. It's open core
GitLab is [open core](/blog/2016/07/20/gitlab-is-open-core-github-is-closed-source/).
GitLab Core is open source, while higher tiers of self-hosted GitLab include both open source and proprietary features. Our [Community Edition](https://gitlab.com/gitlab-org/gitlab-ce/) (CE) repository includes only open source code, while the [Enterprise Edition repository](https://gitlab.com/gitlab-org/gitlab-ee/) (EE) holds both open source and proprietary code,
but operates like CE, thanks to a publicly visible issue tracker. This means that whether you use GitLab Core, GitLab.com, GitLab Ultimate, or anything in between, you can influence and contribute to GitLab, and keep an eye on [where things are going](/direction/).
You can read about our [stewardship of the open source project](/company/stewardship/) and check out [our recent post](/blog/2018/04/20/gitlab-tiers/) which goes into more detail about the different GitLab tiers.
{::options parse_block_html="false" /}
As a product-focused company, we support the #movingtogitlab movement 🦁🚀
We moved to @Gitlab in the recent months, and it has everything our engineers need in one application. #Gitlab enables us to move fast with all the resources we need in one place. https://t.co/tQMew8JosX
## 4. Transparency is by default
Building and maintaining open and honest relationships with users is at the core of our value system. Everything we do is public by default. Our [entire handbook](/handbook/) is open to the public along with [our website’s repository](https://gitlab.com/gitlab-com/www-gitlab-com/).
{::options parse_block_html="false" /}
Phew... Panic resolved. One nice thing about open-source frameworks: transitioning to a clone can be relatively seamless. Thanks @GitLab! Good-bye @GitHub (it's not your fault). #MovingToGitLab is seamless and nearly instant for my teams' usage.
## 5. Everyone can contribute
[This GitLab principle](/company/strategy/#mission) is applicable to your project’s workflow *and* our own application. Our platform allows all project stakeholders – from VPs and directors to ScrumMasters, developers and writers – to collaborate and communicate in one place, allowing for organized and open discourse.
Anyone can create an issue or MR to improve GitLab. We welcome [community contributions](/community/contribute/) and celebrate them by designating a [Most Valuable Person](/community/mvp/) (MVP) every month. With [our public issue tracker](https://gitlab.com/gitlab-org/gitlab-ce/issues), anyone can propose, contribute to, and discuss GitLab’s features. Since we ship a new release on the 22nd of each month, the implementation of public contributions and input are visible in short order.
{::options parse_block_html="false" /}
No problem, I mean what's not to love? You improve consistently, you listen to the community and you make using your platform feel like you're a part of something special. I support you all the way, I have no need to be #movingtogitlab as I've used @gitlab for nearly 2 years now
Ready to make your move? We’ve made it pretty easy to migrate projects to GitLab. Check out [our documentation](https://docs.gitlab.com/ee/user/project/import/) or this video tutorial to get moving today.