Big acquisitions sometimes make loyal users of a platform or service a little jumpy. Worries over new ownership “messing with success,” forcing the use of certain proprietary products, or changing features that teams have come to rely on—and in some cases build entire workflows around—can send users running.

With Microsoft’s recent $7.5 billion GitHub acquisition, many developers are more than just wondering if this will have an effect on the open-source coding platform; some are already migrating away. As a result, competitors such as GitLab and Bitbucket are gaining hundreds of thousands of new users. It’s far from a mass exodus, but it’s piqued interest in trying out alternative options.

Microsoft maintains GitHub will stay language- and platform-independent and isn’t looking to make too many changes—except perhaps focusing more on enterprise developers and giving its cloud computing platform Azure a boost. Microsoft is one of the largest users of GitHub itself, with 2 million of the platform’s 85 million commits belonging to the tech giant.

Nonetheless, if you’ve ever wondered how GitLab and GitHub are different or considered #movingtogitlab, here are some important things to know:

  1. GitLab is well suited to private repositories. If you have open-source projects on GitHub currently, it might be worth leaving those and migrating the private ones to start.
  2. Use the GitHub Importer to import your GitHub repositories to GitLab.com or to your self-hosted GitLab instance. You can import project in parallel or sequentially.
  3. Self-hosted? If you’re not hosting on GitLab.com, you’ll need to enable the GitHub integration to import, or get a personal access token from GitHub.
  4. You might run into GitHub API call limits during your import. GitHub’s API has a rate limit of 5,000 calls in an hour, and those calls are largely dictated by the number of unique users involved in a project. The more authors, the more requests that have to be made, which might result in your import being rescheduled for a time when the rate limit has been reset.
  5. The larger your project, the longer it may take to import. This is rather obvious, but there are things you can do to make it go a bit faster, such as adding in parallel import processes with Sidekiq, which requires you to update to GitLab version 10.2.
  6. Have a project using TypeScript or Visual Studio Code? Because those are Microsoft-maintained technologies, you might consider keeping those projects on GitHub to see about improved compatibility.
  7. Pull requests in GitHub are called merge requests in GitLab. This is an important distinction to know when you’re migrating your project over.
  8. Developers and contributors will need to do some administrative setup. For your migration to work properly, you need to assign the right authors to merge requests and issues. That means each GitHub author and assignee in the repository needs to either log in to a GitLab account using the GitHub icon or create a GitHub account with an email address that matches the email address he or she uses on GitLab.
  9. Choose your new plan based on your needs. There are a number of different plans to consider, both self-hosted and hosted on GitLab.com. Be sure the plan you choose meets your needs, whether those are monitoring of Kubernetes clusters, support for high availability, or 24/7 disaster support.

If migration is your intended path, find a skilled GitLab developer on Upwork to help make a move. Looking to boost your use? We’ve got developers for that too!