| 1 | # HedgeDoc migration |
| 2 | |
| 3 | `bash tools/import-hedgedoc.sh evil-hedgedoc-preview-f6eb07a4` restored Zenith's HedgeDoc database into a disposable stage and copied its uploads. The importer checked the upload copy by checksum, backed up the stage database, compared the restored table counts with Zenith, and restarted the stage. On 2026-09-26 both sides had 39 notes, 8 users, 183 revisions, and 68 authors. The stage returned HTTPS 200; `/auth/oauth2` redirected to the staged Forgejo OAuth client at `git.evil.studio.test` with the stage callback URL. No note bodies or repository contents were inspected. |
| 4 | |
| 5 | The seven HedgeDoc OAuth profile IDs all resolve to the same Forgejo usernames on Zenith and the VM when matched by numeric user ID. That checks account continuity for the imported database; an interactive sign-in remains the final identity check. |
| 6 | |
| 7 | For production, keep the Forgejo user IDs stable. Stop Zenith's HedgeDoc and the Snow Globe HedgeDoc job, set `STUDIO_DEPLOY_HOST` and `STUDIO_DEPLOY_PORT` for the new host, then run `bash tools/import-hedgedoc.sh evil-hedgedoc`. The importer refuses a running source or destination, verifies the uploads and four table counts, leaves a pre-import destination database dump, and leaves Snow Globe stopped. Promote a tested preview to start the new service, then verify HTTPS and a Forgejo sign-in before switching the public route. The old HedgeDoc data stays in place until cutover is accepted. |
| 8 | |
| 9 | For a same-machine OS replacement, use the [legacy PostgreSQL handoff](legacy-handoff.md) and set `STUDIO_LEGACY_HANDOFF` when running the production importer. It verifies the retained dump and reads uploads from the mounted old apps dataset without contacting old Docker. |