Do users and permissions migrate automatically from Gitea?

Not established for repository migration. Accounts, credentials, personal SSH keys, organization membership, teams, and repository permissions should be recreated and reviewed on the Forgejo side.

Does Fjord have a Gitea self-service importer today?

Not today. Fjord has a managed repository migration entry point, but the current Paragon route is scoped to GitHub sources. For Gitea, use Forgejo migration inside the instance or request assisted planning.

From Gitea to Forgejo.

Q: Can a current Gitea server move to Fjord with a database upgrade?

Not for modern Gitea. Forgejo documents transparent upgrades from Gitea up to version 1.22 through Forgejo 10. For Gitea 1.23 and later, plan a repository migration instead.

Gitea and Forgejo share a history, familiar workflows, and familiar project concepts. On current Gitea, the move is still a migration, not a database swap, so the useful work is knowing what comes across and what you rebuild.

The drop-in path is closed for modern Gitea

Forgejo documents transparent upgrades from Gitea up to version 1.22, through Forgejo 10. Gitea 1.23 and later are outside that transparent upgrade path, and Gitea's current documented API line is 1.27.3. For a modern Gitea server, treat Fjord as a clean Forgejo destination and migrate repositories into it.

Sources: Forgejo upgrade guide, Gitea API documentation.

What the repository migration can carry

Forgejo's repository archive commands and Gitea's current repository migration schema cover the core collaboration record: code, wiki, issues, pull requests, labels, milestones, and releases. Comments, release assets, and LFS need a pilot import before you promise exact parity.

Surface	Status	Source-backed note
Git repository	Migrates	Repository import clones the source repository into Forgejo. Gitea 1.27 API schema
Wiki	Migrates when selected	The Gitea 1.27 migration schema includes a wiki option. Gitea 1.27 API schema
Issues and pull requests	Migrates when selected	The migration schema exposes issue and pull-request options. Gitea 1.27 API schema
Labels and milestones	Migrates when selected	Both appear as first-class migration options. Gitea 1.27 API schema
Releases	Migrates when selected	Releases are a Gitea migration option. Gitea 1.27 API schema
Comments and release assets	Validate in a pilot	Forgejo archive commands name comments and release assets as transferable units, while the Gitea 1.27 migration options do not expose separate toggles for them. Forgejo command-line reference
Git LFS	Validate in a pilot	Gitea exposes LFS import fields, but end-to-end object fidelity from a modern Gitea source is not established by the verified Forgejo migration docs. Gitea 1.27 API schema

What you rebuild

The Gitea migration endpoint is a repository import endpoint. It does not establish instance identity, policy, runners, package registry contents, or integrations on the destination.

Actions history and runners

Workflow files move as repository files, but run history, runner registration, and runner configuration are not repository migration fields.

Gitea 1.27 API schema

Webhooks and deploy keys

Gitea documents these as repository API surfaces, not as fields on the repository migration options.

Gitea API documentation

User accounts and credentials

Accounts, passwords, tokens, personal SSH keys, and OAuth applications are outside the repository migration schema.

Gitea 1.27 API schema

Organizations, teams, and permissions

Organization and team administration are separate API areas, so membership and access policy should be rebuilt deliberately.

Gitea API documentation

Packages

Packages have their own API group and are not included in the repository migration fields verified for Gitea 1.27.

Gitea API documentation

The Fjord path today

Fjord gives you the Forgejo destination: managed upgrades, TLS, backups, and CI infrastructure around a dedicated forge. The current Paragon managed repository migration entry point is GitHub-scoped, so a Gitea move should use Forgejo's migration flow inside the instance or start with an assisted migration plan.

Gitea hosting context

Compare managed Forgejo with operating Gitea yourself.

Gitea Cloud comparison

See how Fjord positions dedicated Forgejo beside Gitea Cloud.

CI migration

Plan Actions runners, secrets, and workflow cutover separately from repository import.

When staying on Gitea is the honest answer

Stay on Gitea, at least for now, if you need a database-level takeover of a current Gitea 1.27 server, package registry preservation without republishing, Actions run history as an audit artifact, or automatic account and permission carryover. Those outcomes are not established by the repository migration sources above.

A practical sequence

Inventory repositories, LFS usage, packages, webhooks, deploy keys, users, teams, and CI.
Create the Forgejo destination and rebuild account, organization, team, and policy structure.
Pilot one representative repository before the production move, including comments, release assets, and LFS checks.
Run repository imports, republish packages as needed, recreate integrations, and register runners.
Freeze source writes, verify destination permissions and URLs, then cut over DNS and documentation.