Import Issues from GitLab

I’m working on migrating from a private Gitlab instance to a Github developer account with private repos. I’ve imported my repos but now I need to move the Issues in Gitlab over to Github. After looking around for a couple hours about how to do this, I can’t seem to find a simple way. 

I need to bring over Issues including…

  • Title
  • Description
  • Comment history
  • File attachments

There are enough issues that it would be impracticable to re-enter them manually. I’m fine with existing comments being collapsed into the description or something like that if fields don’t quite match up, I just need all the content. 

Is there anyone out there with insight or advice on this? 


Hi @drewhood,

If you are able to get that information from GitLab in an organized format, you can use GitHub’s Issue API endpoint to create issues on To script this so that you don’t have to do it manually, you might be interested in Octokit which are a set of frameworks for working with the GitHub API programmatically.


That sounds very complicated and time consuming. There should be an easy way to import issues from gitlab. After gitlab doesn’t have any problem importing issues from github, so why can’t the opposite be made to work simply?


There are tools that other people have built for this purpose but since we don’t maintain them or use them regularly, we can’t vouch for these third-party tools.

Since I have the same task now to migrate a whole gitlab server with 50 projects on it, googling for some tooling to do the job revealed, among others, this guy:

This will be my first try. I’ll post my experience with it here.


How did it go?

@basejumpa : Did you find a way to migrate the Gitlab issues to Github?

Interested in how you got on with this @basejumpa 

I just gave it a go (actually, a fork with a follow-up commit, and it has a ton of problems, at least migrating GL issues.

  1. It quickly bumps into 502 and 403 errors, presumably from getting throttled, and doesn’t complete the run. If I rerun the script, it creates dupes.
  2. It only imports my own comments, so a lot of discussions are missing.
  3. Images are broken because they’re hotlinked from GL and reuploaded to GH.

I’m glad I ran this on a test repo so I can blow it up because it made quite a mess.

I just used instead, and it’s so much better. 

It migrates issues without bumping into API throttling, doesn’t create dupes after multiple runs, includes comments made by other users (including a handy mapping config between GL and GH users), and has a decent UI.

The only thing it doesn’t do is migrate images, sadly. But it’s a huge step up from that other script.


Hi @that-pat

I’ve been doing some research about migrating issues from GitLab to Github, and ideally, I would like to mirror issues (keeping creation date and author fields on every issue and comment).

So far I’ve seen 2 different approaches regarding Github API:

  • Regular Github v3 API :



Those methods do not provide “created_at” fields, nor “author” field, so I suspect that all issues/comments would have the same date the migration was done, and the author would be the account used to do the migration.

¿Is this still a valid way to migrate issues? This methods provide a “created_at” field, but on the other hand there is no “author” field, so in this case I guess all issues/comments would get the same owner (i.e: the account used to do the migration).

¿Is there any way to overcome this “created_at”/“author” field editing limitations?

¿What is the way you recommend to do this kind of migration as of 2020?

Thank you very much in advance for your help,

Asier Marruedo

Hi there @amarruedo! Thanks so much for posing those questions with your thoughtful post.

With brevity in mind, the simplest way to respond is: yes, the gist you linked to:

…is still what we recommend in 2020, and the authorship disparity still exists.

Though since that gist, we’ve implemented a transferIssue mutation in our GraphQL API. We still don’t recommend this as the way to solve the explicit use cases that this thread raises. That endpoint will still result in notifications, and would likely trigger anti-abuse rate limits, depending on the volume.

For what transparency I can provide, I’m going to followup both with our REST and GraphQL teams, to reiterate the need for this type of functionality.

Will also make sure to follow up here in this thread, once I have anything digestible for our public-facing community folks.

Thanks again!