Migrating from GitLab EE to GitLab CE – Is it possible?

Over the past year, we received several requests for help with migrating from GitLab EE to the free GitLab CE (each client for their own reasons), and we helped clients execute this transition.

Now, while summarizing what we learned in the past year, I decided to write an article about this and highlight important points based on our accumulated experience, as well as provide some tips.

Is migrating from GitLab Enterprise Edition to Community Edition possible?

First — such a migration is possible, and the GitLab website explains how to do it (link provided below).

However — it’s important to remember the implications: certain features will stop working, and you won’t receive support from the manufacturer.

Some factors to support switching to GitLab CE:

• The manufacturer declares in the product’s terms of use their commitment to provide updates and bug fixes, including security fixes (and the history of all product releases to date proves they’ve stood by this)
• The CE edition is rich, well-maintained, and offers hundreds of features (contact us for an up-to-date list)
• You can receive quality support from us (we have extensive knowledge accumulated since 2015)
• Some features available in the paid edition can be developed independently (we’ve developed several such features in response to demand from our customers — contact us for more details)

So such a migration is possible and can be done independently, but it’s not necessarily simple!

It must be done carefully and the implications must be checked beforehand.

GitLab Migration Implications:

Here’s a list of things to check and some tips:

1. Map features currently in use–check if they’re available in the Enterprise edition
   (Tip: you can contact us for an up-to-date and detailed list of differences between editions)
2. Check if you’re using API calls that might stop working
   (Tip: certain API calls are only available in the Enterprise edition)
3. Check if you’re using webhooks that might stop working
4. Check if CI/CD pipelines will continue to work without changes
5. Check connections to other tools (if any) — that might stop working? (Tools such as Jenkins, Jira, etc.)
6. It’s recommended to backup the system before making changes (backups are always important, particularly in such a migration)
7. It’s recommended to set up a separate environment and test it (dry run)
8. Such a migration can also be an opportunity to check if you’re using an updated version of GitLab (and if not, it’s recommended to update), and it’s also an opportunity to check if you’re using the right Deployment method for you (remember there are various types of deployment for GitLab, even in the free edition)

(The above list is not necessarily complete as it cannot include all checks – which depend on the development environments, GitLab installation / deployment method, end-users’ behaviour etc.).

If this migration testing process sounds complex, or if you’re too busy to do it alone,

you can contact us and our skilled team can do it for you as a paid service.

To sum up:

Such a transition is possible. It’s not necessarily complicated, but requires attention and some time investment.

We can do that migration for you, and also provide support, managed services, ongoing maintenance and upgrades, for your GitLab environment – including all flavors of GitLab editions and deployments.
Contact us: 866-503-1471 (USA / Canada), +972-722-405-222 (International) or by email: gitlab@almtoolbox.com

Related links:

• Tech doc: Downgrading from EE to CE (GitLab’s website)
• What are the Differences Between GitLab Free and GitLab Premium?
• Our GitLab website
• Moving from GitLab CE to EE