Hoe migreer je van Gitea naar Forgejo zonder je repositories te breken

Je stopt Gitea, installeert Forgejo, kopieert app.ini en je datadirectory, en start de service op de manier die elke migratiegids beschrijft. De web-UI komt op. Dan mislukt de databasemigratie, of erger nog, Forgejo weigert te starten omdat je schemaversie te nieuw is om te begrijpen. Je draait Gitea 1.23 of nieuwer, en de simpele in-place upgrade die iedereen documenteert, is niet meer op jou van toepassing.

Forgejo werd begin 2024 een harde fork van Gitea, en de twee projecten zijn sindsdien uiteengelopen op het niveau van het databaseschema. Hoe je Gitea naar Forgejo migreert, hangt nu volledig af van je Gitea-versie. Deze gids geeft je het exacte pad voor jouw versie, de volledige commando's voor zowel native als Docker-installaties, de workarounds voor Gitea 1.23+, en een verificatiechecklist, zodat je migreert zonder repositories, issues of gebruikers te verliezen.

TL;DR

• De versiekloof is reëel. Forgejo v10.0 was de laatste release die een transparante directe upgrade vanaf Gitea ondersteunde. Gitea v1.22 is de hoogste versie die het ondersteunde directe pad kan nemen.
• Op Gitea v1.22 of ouder: migreer eerst naar Forgejo v10.0.x, upgrade daarna Forgejo v10 naar de huidige release (v15). Twee stappen, beide ondersteund.
• Op Gitea v1.23 of nieuwer: is er geen officieel ondersteund direct pad. Je kiest tussen een SQL/schema-downgrade, community-migratiescripts, repo/API-migratie, of een nieuwe-server-staging-migratie met een van die methoden. Elk brengt een andere afweging in gegevensverlies met zich mee.
• Maak een back-up van je datamap en je database voordat je iets aanraakt. Elk pad hieronder gaat ervan uit dat je een herstelbare back-up hebt. De niet-ondersteunde paden gaan er dubbel van uit.
• Sommige zaken vragen altijd aandacht na de migratie: plan om Personal Access Tokens opnieuw aan te maken of te controleren, Actions-runners opnieuw te registreren, en de Bleve-zoekindex te verwijderen en opnieuw op te bouwen. Houd hier rekening mee ongeacht het gekozen pad.
• Migreren is niet verplicht. Gitea wordt actief onderhouden. De beslissing om "op Gitea te blijven" houdt stand als het migratierisico groter is dan het voordeel voor jouw situatie.

Buiten het bestek hiervan: migreren van Gogs, GitHub of GitLab naar Forgejo, en Forgejo Actions vanaf nul opzetten.

Vereisten / Wat je nodig hebt

Voordat je ook maar één commando uitvoert, controleer of je een volledige, herstelbare back-up hebt van twee dingen: je Gitea-datamap (/var/lib/gitea bij een standaard native installatie) en je database. Als je database SQLite is, bevindt dat bestand zich in de datamap; als het PostgreSQL of MySQL is, dump je het apart met pg_dump of mysqldump. Een migratie zonder geverifieerde back-up is geen migratie, het is gokken.

Je hebt ook nodig:

• Je huidige Gitea-versie. Voer gitea --version (of docker exec <container> gitea --version). Dit nummer bepaalt je volledige pad.
• Je databasetype: SQLite, PostgreSQL of MySQL. Sommige workarounds zijn database-specifiek.
• Root- of sudo-toegang op de server.
• Het besef dat het ondersteunde pad Forgejo v10.0 als tussenstap installeert. Forgejo v10.0 is EOL sinds 16 april 2025. Je installeert het alleen voor de duur van de migratie en upgradet er direct weer vanaf.

Waarom het directe upgradepad brak

In december 2024 publiceerde het Forgejo-project een compatibiliteitsverklaring die een harde grens trok: "Toekomstige versies van Forgejo zullen geen upgrades meer ondersteunen vanaf Gitea-instanties die versie v1.23 of hoger draaien." Die zin is het hele probleem in één regel.

Toen Forgejo begin 2024 van Gitea afsplitste, bleven de twee codebases uit elkaar groeien en raakten de databaseschema's steeds verder van elkaar verwijderd. Forgejo hield een compatibiliteitsvenster aan zodat bestaande Gitea-beheerders konden overstappen, maar dat venster had een einde. Forgejo v10.0, uitgebracht op 16 januari 2025, was "the last version to allow a transparent upgrade from Gitea v1.22 or lower." Alles nieuwer dan v10.0 kan een Gitea-database niet direct lezen.

De timing is waar mensen over struikelen. Gitea v1.23 verscheen eind 2024, en de de huidige Gitea-release is per juni 2026 v1.26.4. Als je je Gitea-instantie redelijk actueel hebt gehouden, ben je de grens al gepasseerd en beschrijven de standaardtutorials jouw situatie niet meer.

Kern van deze sectie: het ondersteunde directe pad houdt op bij Gitea v1.22. Alles nieuwer vereist een extra stap.

Vind jouw migratiepad op basis van je Gitea-versie

Voer uit gitea --version, zoek je rij op en volg het pad in de derde kolom. Al het andere in deze gids is het detail achter deze rijen.

De verklaringen over versiecompatibiliteit komen rechtstreeks van de officiële compatibiliteitsaankondiging van Forgejo: Gitea tot en met v1.21 kan overstappen naar Forgejo v7.0 tot en met v10.0, en Gitea v1.22 kan overstappen naar Forgejo v8.0 tot en met v10.0. Beide eindigen bij v10.0 als laatste ondersteunde directe doelversie.

Onder de versievraag liggen drie migratiestrategieën, en het helpt om die te zien voordat je aan de stap-voor-stap-instructies begint:

• Ter plaatse, op dezelfde server. Vervang de binary of container image op de bestaande server. Minste moeite als jouw versie dit ondersteunt; vereist de tussenstap via v10.0.
• Voorbereiding op een nieuwe server. Zet een nieuwe server op en gebruik deze als veilig doel voor de migratiemethode die past bij jouw Gitea-versie. Dit beschermt de oorspronkelijke Gitea-server en maakt terugdraaien eenvoudiger, maar het omzeilt het databaseschemaprobleem van Gitea 1.23+ niet.
• Repo/API-migratie. Gebruik de migratietools van Forgejo om repositories op te halen uit de oude Gitea-instantie. Git-geschiedenis is het betrouwbare onderdeel; metadata zoals issues, PR's, labels, releases, wikigegevens en reacties moet je als best-effort beschouwen en per repo controleren.

Het ondersteunde pad: Gitea v1.22 of eerder

Als je op Gitea v1.22 of ouder zit, de officiële migratiedocumentatie beschrijven een tweestapspad: migreer naar Forgejo v10.0.x, upgrade daarna Forgejo v10 naar de huidige release. De eerste stap is een drop-in vervanging omdat Forgejo v10.x een Gitea v1.22-database leest; de tweede stap is een normale Forgejo-upgrade.

Er zijn twee manieren om dit te doen, afhankelijk van hoe Gitea op jouw server draait. Kies degene die past bij jouw bestaande opzet. Als Gitea als systeemservice draait, gebruik je het natieve pad. Als Gitea in een container draait, gebruik je het Docker-pad. Forgejo v10.x fungeert als drop-in vervanging voor Gitea v1.22.x.

Native pad (systemd)

Maak eerst een back-up. Installeer vervolgens Forgejo v10.0.x met het pakket van je distributie of de release-binary vastgezet op v10.0. Stop Gitea voordat je iets kopieert. Een draaiende service die tijdens het kopiëren naar zijn datamap schrijft, corrumpeert de kopie.

# Stop the running Gitea service before touching its data
systemctl stop gitea

Kopieer de configuratie en de datamap naar de locaties van Forgejo en corrigeer vervolgens het eigenaarschap. Het configuratiebestand moet leesbaar zijn voor de groep forgejo; de data moet eigendom zijn van de gebruiker forgejo.

# Copy the existing Gitea config to Forgejo's config path
cp /etc/gitea/app.ini /etc/forgejo/app.ini

# Back up the copied config before rewriting paths
cp /etc/forgejo/app.ini /etc/forgejo/app.ini.bak

# Update old Gitea data paths to Forgejo data paths
sed -i 's#/var/lib/gitea#/var/lib/forgejo#g' /etc/forgejo/app.ini

# Forgejo reads its config as the forgejo group; grant group write
chown root:forgejo /etc/forgejo/app.ini && chmod g+w /etc/forgejo/app.ini

# Copy the data directory and hand ownership to the forgejo user
rsync -aHAX --numeric-ids /var/lib/gitea/ /var/lib/forgejo/
chown -R forgejo:forgejo /var/lib/forgejo

Start Forgejo en schakel het in bij het opstarten.

# Start Forgejo and enable it at boot
systemctl start forgejo && systemctl enable forgejo

Voordat je weg upgradet van v10.0, leeg je de wachtrijen zodat er geen lopend werk verloren gaat tijdens de versiesprong.

# Flush pending queue items before the version upgrade
forgejo manager flush-queues

Upgrade nu Forgejo v10.0.x naar de huidige release door de binary te vervangen door v15 en de service opnieuw te starten, volgens de standaard Forgejo-upgradegids. Voer na beide tussenstappen de doctor uit om de database te controleren en te herstellen wat mogelijk is.

# Check everything; write a log you can read if something is wrong
forgejo doctor check --all --log-file /tmp/doctor.log

Lees /tmp/doctor.log voordat je een automatische oplossing toepast. Gebruik --fix alleen wanneer de output van de doctor een specifieke reparatie identificeert die je begrijpt, of wanneer je een officieel probleemoplossingspad volgt.

Als doctor geen kritieke fouten meldt en de web-UI je repositories toont, is de eerste migratie voltooid.

Docker- / containerpad

Als Gitea als container draaide, draai Forgejo dan op dezelfde manier. Gebruik de Forgejo v10.x-image als drop-in vervanging voor je Gitea v1.22.x-image, en wijs hem naar hetzelfde datavolume en dezelfde database. Controleer eerst of je Docker-versie minstens 20.10.6 is. Oudere versies veroorzaken onvoorspelbaar gedrag bij Forgejo-containers.

Het ene container-specifieke detail waar mensen over struikelen: omgevingsvariabelen. Forgejo behoudt het GITEA_-voorvoegsel voor compatibiliteit, maar de documentatie raadt aan beide voorvoegsels mee te geven zodat je configuratie een toekomstige Forgejo-versie overleeft die de oude namen laat vallen.

# docker-compose.yml (excerpt): pass both prefixes for forward compatibility
environment:
  - GITEA__database__DB_TYPE=postgres
  - FORGEJO__database__DB_TYPE=postgres
  # ...repeat the dual-prefix pattern for every config override you pass

Voor rootless containers moet de data eigendom zijn van gebruiker 1000 en groep 1000, overeenkomend met de runtime-gebruiker van de rootless image. Nadat de container is gestart op v10.x, voer je hetzelfde forgejo doctor check --all vanuit de container, upgrade daarna de image tag naar de huidige v15-release en herstart.

Als je op Gitea v1.23 of nieuwer zit

Dit is waar de standaardgidsen stoppen en waar de meeste huidige installaties zich daadwerkelijk bevinden. Er is geen officieel ondersteund direct pad vanaf Gitea v1.23+, dus elke onderstaande optie is ofwel afkomstig uit de community, ofwel verliesgevend. Maak voordat je een van deze uitvoert een volledige back-up van je datadirectory en je database, en controleer of je deze kunt herstellen. Deze aanpakken wijzigen productiegegevens; de back-up is je enige manier om terug te draaien.

De drie opties verschillen in risico en in hoeveel ze behouden. Kies de optie waarvan je de afweging kunt accepteren.

Optie A: SQL-schema-downgrade / versiepatch

De meest beperkte workaround downgradet de databaseschemaversie zodat Forgejo v10 deze als een v1.22-database behandelt.

Let op: behandel de versie-update niet als op zichzelf staande volledige downgrade. De geregistreerde migratieversie en het daadwerkelijke schema moeten overeenkomen. Test op Gitea 1.23.x de volledige downgrade eerst op een kopie en vergelijk het schema voordat je Forgejo erop richt.

Een Forgejo-maintainer beschreef de SQL in Codeberg issue #7638:

-- Downgrade the recorded schema version to the v1.22 baseline (PostgreSQL/MySQL)
UPDATE version SET version=305 WHERE id=1;

Daarna volg je het ondersteunde pad alsof je op v1.22 zit. De belangrijke kanttekening: de maintainer bevestigde dit alleen specifiek voor Gitea v1.23.1, niet voor alle v1.23.x-versies. Het schemaversienummer is exact; de verkeerde doelwaarde toepassen op de verkeerde Gitea-release kan de database in een staat achterlaten waaruit geen migratie kan herstellen. Dit geldt voor PostgreSQL/MySQL, het is niet officieel ondersteund en het is niet getest als algemene procedure.

Pro tip: door version=305 direct in te stellen, sla je de migratie van 304 naar 305 over, die de manier waarop TOTP-geheimen worden gecodeerd heeft veranderd. Codeberg issue #8210 documenteert dat dit tweefactorauthenticatie voor getroffen gebruikers corrumpeert. De oplossing is de versie op 304 te zetten, de migratie te laten draaien, of de rijen in de two_factor-tabel te wissen zodat gebruikers zich opnieuw registreren. Sla dit niet over als een account TOTP gebruikt.

Optie B: opeenvolgende SQL-downgradescripts (Gitea 1.24–1.25.2)

Voor versies tussen 1.24 en 1.25.2 is een enkele versiepatch niet genoeg: het schema doorliep meerdere tussenliggende staten. De community-scripts op xlrl/prepare-gitea-migration-to-forgejo voert het schema terug door de tussenliggende versies naar v1.22, waarna je het ondersteunde pad volgt. Deze scripts zijn communitywerk, geen gezaghebbende procedure, en richten zich primair op SQLite. Voer ze alleen uit tegen een database waarvan je al een back-up hebt gemaakt.

Optie C: repo-voor-repo API-migratie (Gitea 1.26+ of elke versie)

Het repo/API-pad behoudt Git-gegevens het meest betrouwbaar. Afhankelijk van de bron, de rechten en de migratiemethode kan optionele metadata zoals issues, pull requests, labels, mijlpalen, releases, wikigegevens en reacties ook beschikbaar zijn, maar behandel die als best-effort en controleer ze per repo. Voor een archief dat alleen code bevat, is dit meestal prima; voor een server waar de issue tracker het geheugen van het team is, test je de overdracht van metadata voordat je voor dit pad kiest.

Twee experimentele tools proberen uitgebreidere migraties voor 1.23+, maar hebben elk hun eigen tekortkomingen. pacnpal/gitea2forgejo (GitHub) voert een volledige dump plus API-synchronisatie uit en vereist een overeenkomende SECRET_KEY om versleutelde velden over te zetten, maar het verplaatst geen Personal Access Tokens, Actions runners, webhook callback-URL's of 2FA. nicoverbruggen/gitea-to-forgejo (GitHub) is een op Podman gebaseerde experimentele tool die gebruikers, sleutels, organisaties, repo's, issues, PR's, releases en mirrors overzet, maar geen 2FA-tokens, Actions-runtimedata of loshangende OCI-pakketmanifesten. Behandel beide als experimenteel en controleer het resultaat aan de hand van de overzettingsmatrix hieronder.

Kern van deze sectie: er is geen officieel ondersteund direct pad vanaf Gitea 1.23+. Kies de optie waarvan je het gegevensverlies kunt accepteren, en maak een back-up voordat je begint.

Migreren op een nieuwe server is veiliger, maar omzeilt de versiegrens niet

Een nieuwe server is de veiligste plek om de migratie voor te bereiden en te verifiëren, maar het is geen apart pad voor schemacompatibiliteit. Als je bron Gitea v1.22 of ouder is, installeer dan eerst Forgejo v10.0.x op de doelserver, herstel of kopieer de Gitea-data daarheen, laat Forgejo de ondersteunde databasemigraties uitvoeren en upgrade die Forgejo v10-instantie vervolgens naar de huidige Forgejo-release.

Als je bron Gitea v1.23 of nieuwer is, herstel de Gitea-database dan niet zomaar in de huidige Forgejo en verwacht niet dat die opstart. Je hebt nog steeds een van de hierboven genoemde niet-ondersteunde 1.23+-benaderingen nodig: een gefaseerde SQL-downgrade of terugdraaiing, een community-migratietool, of een repo/API-migratie. De nieuwe server verlaagt het rollback-risico omdat de originele Gitea-machine onaangeroerd blijft; het neemt de noodzaak om de mismatch in databaseversie aan te pakken niet weg.

Dit is waar Cloudzy's one-click Forgejo app kan helpen: gebruik het als de schone doelinstantie, en voer vervolgens de migratiemethode uit die past bij jouw Gitea-versie. De marketplace-image van Cloudzy geeft je een kant-en-klaar Forgejo-doel op onze krachtige VPS, zodat je je kunt richten op de herstel-, verificatie- en overschakelstappen in plaats van de eerste installatie. Het migratieplan hangt nog steeds af van of je vóór of na de Gitea 1.22-grens zit.

Wat wordt overgedragen en wat je opnieuw moet doen

Een deel van je gegevens verhuist automatisch, een deel verhuist alleen als aan een voorwaarde wordt voldaan, en een deel verhuist nooit en moet handmatig opnieuw worden aangemaakt. Weten wat wat is voordat je begint, is het verschil tussen een schone overgang en een week vol verwarde gebruikers.

Vier zaken raken het hardst omdat ze stilletjes stukgaan of elke gebruiker treffen, dus behandel ze bewust: gebruikers moeten hun Personal Access Tokens opnieuw aanmaken of controleren, je moet je Actions runners opnieuw registreren tegen de nieuwe hostnaam, je moet de Bleve-zoekindex verwijderen zodat Forgejo hem netjes opnieuw opbouwt, en je moet elke uses: korte verwijzingen in je Actions-workflows naar volledige GitHub-URL's, omdat Forgejo en Gitea acties uit aparte mirrors halen en een relatieve verwijzing naar de verkeerde plek verwijst.

Pro tip: als je Gitea en Forgejo tijdens de migratie parallel draait en beide naar dezelfde Redis-instantie wijzen, zet Forgejo dan voor je begint op Redis db=1. Beide staan standaard op db=0, en als ze deze delen, verbruikt Gitea de migratie-events van Forgejo en vernietigt het de migratiewachtrij. (blog.mei-home.net documents this exact failure.)

Kern van deze sectie: Personal Access Tokens, Actions-runners, deploy keys per repo en de Bleve-zoekindex zijn altijd handmatig. Plan ze als migratietaken, niet als bijzaak achteraf.

Controleer of de migratie is geslaagd

Begin met de doctor, controleer vervolgens de cijfers en test daarna de dingen die gebruikers daadwerkelijk doen. De doctor vangt problemen op databaseniveau op; de handmatige controles vangen de problemen met gegevensverlies en toegang op die de doctor niet kan zien.

1. Voer uit forgejo doctor check --all --log-file /tmp/doctor.log, lees dan het logboek voordat je wijzigingen aanbrengt. Gebruik --fix alleen voor een specifieke reparatie die je begrijpt.
2. Controleer of het aantal repositories, het aantal issues en PR's, en het aantal LFS-objecten plus de totale omvang allemaal overeenkomen met je cijfers van vóór de migratie. Een verschil hier betekent dat er iets niet is overgekomen.
3. Test een SSH-push en -pull. Als clients een host-key mismatch krijgen, heb je /etc/ssh/ssh_host_* niet naar de nieuwe server gekopieerd.
4. Log in en controleer of 2FA werkt voor een account dat het gebruikt. Als TOTP niet werkt, zie de kanttekening bij Optie A hierboven.
5. Genereer Personal Access Tokens opnieuw, registreer Actions-runners opnieuw, en voer een testworkflow uit.

Een paar symptomen na de migratie hebben bekende oorzaken. Een ontbrekend favicon of logo betekent dat je brandingbestanden zich nog in public/assets/img/ bevinden in plaats van in custom/, waar Forgejo ze nu verwacht. 404-fouten op pakketroutes wijzen op verkeerd geconfigureerde opslagpaden. Actions die mislukken met "repository not found" is de uses: mirrorprobleem. Schakel over naar volledige URL's. Een lege of 500-pagina na inloggen bij een SQLite-database betekent dat je onder het minimum zit, wat de upgradedocumentatie stelde het op Forgejo v1.19.3-0.

Wanneer het zinvol is om bij Gitea te blijven

Migreren is een keuze, geen verplichting. Als je de grens al bent gepasseerd en de complexiteit van de migratie zwaarder weegt dan het bestuurs- of functievoordeel voor jouw situatie, is op Gitea blijven een legitieme keuze. Gitea wordt actief onderhouden (meerdere releases per maand, momenteel op v1.26.4), en CommitGo biedt commerciële opties waaronder Gitea Enterprise, Gitea Cloud, en SOC 2 Type 2-certificering voor teams die ze nodig hebben.

Er is ook de EOL-tussenstap om eerlijk tegen elkaar af te wegen. Het ondersteunde directe pad vereist het kortstondig installeren van Forgejo v10.0, dat sinds april 2025 EOL is. Dat is acceptabel als tijdelijke migratiestap waar je direct weer vanaf upgradet, maar sommige beheerders zullen hier op beleidsgronden bezwaar tegen maken. Voor hen kan repo/API-migratie naar een nieuwe Forgejo-instantie de EOL-tussenstap volledig vermijden, terwijl een nieuwe-server-staging nog steeds afhankelijk is van de migratiemethode die je kiest.

Als je reden om over te stappen ontwikkelactiviteit is, ondersteunen de gegevens Forgejo als het actievere project: een analyse van honeypot.net telde 3,039 Forgejo-commits tegenover 1,228 Gitea-commits over de periode juli 2024 tot mei 2025, en 232 Forgejo-bijdragers tegenover 153 voor Gitea over het jaar dat eindigde in mei 2025. Dat is één signaal onder meerdere; weeg het af tegen je migratierisico in plaats van het als doorslaggevend te beschouwen.

Kern van deze sectie: migreren is niet verplicht. De beslissing is een afweging tussen voorkeur voor bestuur en activiteit tegenover migratierisico, en beide keuzes zijn verdedigbaar.

Kies je pad en maak eerst een back-up

Jouw migratiepad komt neer op één getal: jouw Gitea-versie. Bij v1.22 of eerder volg je het ondersteunde tweestapspad via Forgejo v10. Bij v1.23 of nieuwer kies je een workaround op basis van het gegevensverlies dat je kunt accepteren: SQL/schema-downgrade, community-scripts, repo/API-migratie, of een nieuwe-server-staging-migratie. Welk pad je ook kiest, maak eerst een back-up van je datadirectory en database, voer forgejo doctor achteraf uit, en controleer of het aantal repositories, issues en LFS-objecten overeenkomt met waar je mee begon.

Identificeer je versie, maak de back-up en volg de bijbehorende rij. Het pad is ingewikkelder dan de oude tutorials beloofden, maar het is duidelijk gedefinieerd zodra je weet waar je staat ten opzichte van de versiegrens.

Veelgestelde vragen

Kan ik direct upgraden van Gitea naar Forgejo?

Ja, als je Gitea v1.22 of eerder draait: upgrade direct naar Forgejo v10.0, upgrade daarna Forgejo v10 naar de huidige release. Nee, als je Gitea v1.23 of nieuwer draait. Forgejo v10.0 was de laatste release die een transparante directe upgrade ondersteunde, dus nieuwere Gitea-versies hebben in plaats daarvan een workaround nodig.

Welke versie van Gitea is compatibel met Forgejo?

Gitea v1.22 en ouder hebben een ondersteund direct upgradepad naar Forgejo (tot Forgejo v10.0, en daarna verder naar de huidige versie). Gitea v1.23 en nieuwer hebben geen officieel ondersteund direct pad, omdat Forgejo vanaf releases na v10.0 stopte met het ondersteunen van transparante upgrades vanaf Gitea v1.23+.

Kan ik migreren van Gitea 1.26 naar Forgejo?

Ja, maar niet via een ondersteunde directe upgrade. Je opties zijn een repo/API-migratie, waarbij Git-geschiedenis het betrouwbare onderdeel is en metadata per repo getest moet worden, een experimenteel migratiescript, of een nieuwe-server-staging-migratie met een van de bovenstaande niet-ondersteunde 1.23+-methoden. Er is geen officieel ondersteund in-place pad vanaf Gitea 1.26.

Worden mijn Personal Access Tokens overgezet?

Plan om Personal Access Tokens na de migratie opnieuw aan te maken of te vervangen. Sommige migratiepaden behouden ze niet, en zelfs als tokens behouden blijven, moeten gebruikers de scopes controleren voordat ze er weer op vertrouwen. Scripts of integraties die oude tokens gebruiken, moeten na de overgang worden getest en bijgewerkt.

Werken mijn Gitea Actions-workflows in Forgejo?

Grotendeels, met twee vereiste correcties. Workflow uses: korte verwijzingen breken omdat Forgejo en Gitea acties uit aparte mirrors halen. Verander ze naar volledige GitHub-URL's (bijvoorbeeld uses: https://github.com/sammcj/dotenv-output-action@main). Je moet ook je Actions runners opnieuw registreren, omdat hun registratietokens gekoppeld zijn aan de oude hostnaam.

Hoe zit het met migreren van Gogs naar Forgejo?

Dat is een andere migratie met een ander pad en valt buiten het bestek hiervan. Deze gids behandelt specifiek Gitea naar Forgejo; raadpleeg voor een Gogs-bron de officiële migratiedocumentatie van Forgejo voor de Gogs-specifieke procedure.