Why teams leave GitHub Wiki

GitHub Wikis are easy to start and surprisingly hard to scale. The most common reasons teams move:

Two viable paths

There are essentially two ways to make this move, and they answer different questions:

Path A: Migrate the content Path B: Regenerate from source
What moves Existing wiki pages, exactly as written Nothing. Fresh documentation written from current code
Preserves history? Yes — wording, decisions, screenshots No — only what's still in the code today
Carries stale pages? Yes, unless you curate first No — the AI only sees current source
Effort Scripted pandoc + REST API, or paid migration tool Connect the app once, generate per repo
Stays current? No. Same staleness problem as before Yes — re-run on commit or schedule
Best for Architecture decisions, RFCs, post-mortems API references, module overviews, onboarding

The honest recommendation: use both. Migrate the small subset of pages that capture decisions and history (Path A). Regenerate the larger volume of "what does this code do" pages from source (Path B). Don't bulk-migrate everything.

Path A — migrate wiki content with pandoc

Every GitHub Wiki is itself a Git repository. You can clone it and convert Markdown to Confluence storage format with pandoc, then push to Confluence via REST.

Step 1: Clone the wiki repo

git clone https://github.com/your-org/your-repo.wiki.git
cd your-repo.wiki
ls *.md

Step 2: Convert Markdown to Confluence storage format

for f in *.md; do
  pandoc "$f" -f gfm -t html -o "out/${f%.md}.html"
done

Pandoc emits XHTML close enough to Confluence storage format for most pages. Code blocks, headings, lists, tables, and inline formatting come through cleanly. Things that need a manual pass: relative links between pages, embedded images, and custom GitHub macros (e.g. <details> blocks).

Step 3: Create pages via the Confluence REST API

POST /wiki/rest/api/content
{
  "type": "page",
  "title": "Architecture Overview",
  "space": { "key": "ENG" },
  "body": {
    "storage": {
      "value": "<html content from pandoc>",
      "representation": "storage"
    }
  }
}

Wrap the loop in a script that maps each Markdown file to a page title and a parent page. Run it once into a sandbox space first, review the result, then fix up the script before running it against the real space.

Watch out for: internal wiki links of the form [[Page Name]]. Pandoc doesn't know they refer to other wiki pages, so they come through as plain text. Run a post-processing pass that rewrites these into Confluence links using the new page IDs.

Path B — regenerate from source with CodeDoc AI

The second path skips the migration entirely. Instead of moving the existing wiki, you point an AI documentation tool at the source repository, choose how the output should be structured, and let it write fresh pages directly into Confluence.

CodeDoc AI for Confluence is one such tool, built on Atlassian Forge. The workflow:

  1. Connect an AI provider — bring your own key for Anthropic Claude, OpenAI, or Google Gemini.
  2. Connect GitHub with a personal access token (read access to the repos you want to document).
  3. Add the repository — browse and select, or paste the URL with a branch.
  4. Create a job — pick a documentation preset (Developer Documentation, Onboarding Guide, Quick Reference, Compliance & Audit, etc.), pick a language, pick a trigger.
  5. Pick a target space — choose which Confluence space the page should be created in.
  6. Run it — the AI reads the code, generates structured documentation, and publishes it as a Confluence page.

What this path is — and isn't

This is not a wiki content migrator. CodeDoc AI does not read your GitHub Wiki pages; it reads the source code in the main repository. The output is documentation that reflects the code as it exists today. If your wiki has an architecture decision log or an onboarding tutorial that doesn't live in code, that part has to be captured separately (Path A is the right tool for it).

What you get for free, though, is that the generated documentation stays current. Set the trigger to on commit via webhook, or on a schedule (daily / weekly / monthly), and the Confluence pages refresh automatically when the code changes. That is the failure mode the original wiki was suffering from — pages that drifted from the code over years — solved by removing the human gap entirely.

Tip: If you only want to try it, the Quick Reference preset is the cheapest in tokens — five sections, tech stack table, key commands, project structure. A medium repository typically costs a few cents on Gemini's free tier.

Don't migrate dead pages

The biggest mistake in any wiki migration is treating it as a copy operation. Most GitHub Wikis carry a long tail of partial drafts, outdated architecture sketches, and instructions that no longer apply. Migrating that into Confluence preserves the rot — and now your stakeholders, who never had access to the wiki, get to see it too.

Before either path:

A combined timeline

For most teams the cleanest sequence is:

  1. Audit the wiki. Tag keep / regenerate / archive.
  2. Migrate the keep pages with pandoc + REST API into a fresh Confluence space.
  3. Install CodeDoc AI, point it at the same Confluence space, set up jobs for each repository.
  4. Wire the jobs to your CI: webhook trigger on push to main, so the docs refresh whenever the code does.
  5. Archive the old GitHub Wiki — keep it read-only as a reference, point the README at Confluence.

Frequently asked questions

How do I migrate a GitHub Wiki to Confluence?

Two viable paths. One is a content migration: clone the wiki repository, convert the Markdown to Confluence storage format with a tool like pandoc, and import the result via the Confluence REST API. The other is a regeneration approach: keep the source code in GitHub, but generate fresh documentation from the code itself directly into Confluence using an AI documentation tool such as CodeDoc AI. The first preserves history; the second avoids migrating stale pages.

Does Atlassian provide a tool to import a GitHub Wiki into Confluence?

Confluence has a Markdown import option for individual pages, but no built-in migrator for an entire GitHub Wiki repository. You either import pages one at a time, script the conversion with pandoc and the Confluence REST API, or regenerate the documentation from source code with a Marketplace app.

Should I migrate my entire GitHub Wiki to Confluence?

Usually not. Most GitHub Wikis have a long tail of stale pages — partial drafts, outdated architecture sketches, instructions that no longer apply. Migrating all of it preserves the rot. The better approach is to identify the pages that are still actively referenced, migrate those, and regenerate the rest from current source code.

Does CodeDoc AI migrate wiki content?

No. CodeDoc AI reads source code from a Git repository and generates documentation from it — it does not read existing wiki pages. Use pandoc + the Confluence REST API for true content migration; use CodeDoc AI to replace the "what does this code do" subset of the wiki with always-current pages generated from source.

Can the documentation in Confluence update automatically when code changes?

Yes, if you use the regeneration path. CodeDoc AI supports webhook triggers (regenerate on every push or merge to a chosen branch) and scheduled triggers (daily, weekly, monthly). Pages migrated manually via pandoc do not auto-update — they are static copies.

Replace your GitHub Wiki with always-current Confluence docs

CodeDoc AI generates documentation from your source code and publishes it directly to Confluence. Bring your own AI key. Free trial on the Atlassian Marketplace.

See CodeDoc AI →