Migrating from GitHub to Fjord

Published Jul 29, 2026 3 min read

Moving off GitHub sounds like a project. Because Fjord runs Forgejo, and Forgejo speaks GitHub’s shapes, most of it is import-and-verify rather than rewrite. How long it takes depends mostly on how much CI you have and how much of it reaches for GitHub-only APIs. This guide walks the path: bring the repositories over, get CI running, and point your tools at the new forge.

Before you start

You will want two things: a Fjord forge (sign up if you do not have one yet) and a GitHub personal access token with read access to the repositories, issues, and pull requests you want to bring across. The token is what lets the importer pull more than just the git history.

Bring the repositories over

Start an import for each repository

Use your forge's migration flow and point it at the GitHub repository URL, with your GitHub token. Forgejo's importer pulls the git history and, when you opt in, the issues, pull requests, labels, milestones, releases, and wiki, not just a bare `git clone`. Bring your open issues and PRs with you rather than leaving history behind.

Verify what came across

Spot-check a repository or two: default branch, tags and releases, issue and PR history, labels and milestones. Large or long-lived repositories take longer to import; let them finish before you judge the result.

Repoint your local clones

For each working copy, update the remote to the new forge:

git remote set-url origin https://<your-forge>/<owner>/<repo>.git
git remote -v

New clones can come straight from the forge, or from fj with fj repo clone <owner>/<repo>.

Get CI running

Forgejo Actions is compatible with GitHub Actions: the same on:/jobs:/steps: workflow model, and the same marketplace-style actions in most cases. For a lot of projects, CI is a move-into-place rather than a rewrite.

Move the workflows

Forgejo reads workflows from `.forgejo/workflows/`. Moving your `.github/workflows/` files there (or configuring your forge to read the GitHub path) is usually the bulk of the work.

Check your action references

Steps that use `actions/*` resolve as expected. Third-party actions referenced by bare `owner/repo` may need a full URL so the runner knows where to fetch them, and anything that assumes GitHub-only APIs or secrets will need a look. Pin versions the same way you did before.

Attach a runner

CI needs a runner. Every Fjord forge runs CI on a shared runner pool we operate, so there is nothing to stand up or patch to get a pipeline going. If you want capacity that is not shared, **team** and **pro** can attach a dedicated Linux runner as a paid add-on (one on team, up to three on pro). Point your workflows at the runner labels your forge exposes and push a commit to see the first pipeline go green.

What transfers cleanly, and what to check

Git history, branches, tags, releases, issues, pull requests, labels, and milestones import well. The things worth a manual pass are CI secrets and variables (re-enter them; they do not travel with an import), branch protection and other repository settings, and any workflow step that reaches for a GitHub-only API. Webhooks and anything hanging off them do not come across either: expect to re-create those against the new forge, and to re-point whatever was listening.

Point your tools at the new forge

Once the code and CI are across, move the daily workflow over. fj gives you the terminal path, repositories, pull requests, issues, and CI runs from the command line, and Fjord Mobile covers review and triage on the move. Both sign in with your Fjord Account.

Start your migration

Create your forge and import

The specifics of the import screen and the exact runner labels live in the documentation; this guide is the map, the docs are the territory.

Migrating from GitHub to Fjord

#Before you start

#Bring the repositories over