What you can export from GitBook and what stays behind
If a renewal, a pricing change or a data residency requirement is pushing you to leave GitBook, start with Git Sync. It is the documented path for getting your content out as Markdown into a GitHub or GitLab repository, and it runs in both directions. Git Sync is available on every GitBook plan, so the practical question is who on your side can enable it. Confirm with GitBook which roles can connect a repository and which repository permissions the connection needs. A sync set up through a personal account or by an employee who is about to leave can cause trouble later. Plan the export as a project with a named owner, a target repository in your own organization and a fixed date for the final check.
Git Sync carries the page content, which is the part that matters most for a migration. Everything else needs a separate inventory. Site settings, such as custom domains, branding, visibility and search configuration, do not come across in the Markdown, so record them before you cancel. Integrations and their configuration, including single sign-on and embedded third-party tools, will have to be rebuilt on the new platform. Assume that user accounts, team access, comments and analytics history stay behind unless the repository shows otherwise. Ask GitBook in writing which elements the sync excludes, and build your inventory from that answer and from a review of the live site settings.
Before you end the contract, verify the repository as a complete copy. Clone it locally, then compare the page count and titles against the live site. Open a sample of pages from each section and check that the images and attachments referenced in the Markdown resolve to files in the repository. Confirm that the navigation file lists every section you expect, because one missing entry can hide a whole chapter. Keep a dated snapshot, such as a tagged commit or an archive in your own storage, so the evidence survives after the subscription ends. Record who performed each check and what they found. That record also helps a later audit or data protection review, although it does not replace their assessment.
Which GitBook content exports to Markdown through Git Sync
This table lists the main content types that GitBook Git Sync is expected to move into a GitHub or GitLab repository, with the format each takes and what to verify. The sync behavior for each type is not fully documented in the sources used here, so the right-hand column names the points to confirm with GitBook in writing before you treat the repository as your only copy.
| Content type | How it exports through Git Sync | What to confirm with GitBook |
|---|---|---|
| Space pages | Page text is written to the connected repository as Markdown files | Confirm that every page in each space, including pages in draft or restricted areas, appears in the repository |
| Page structure and navigation | Sidebar order and nesting are expected to appear as a navigation or summary file | Check that the navigation file lists every page and that nesting matches the GitBook sidebar |
| Images and attachments | Referenced images are expected to sync as files, with paths written into the Markdown | Confirm which uploaded files and embedded media are copied, and open a sample page to check that image links resolve |
| Embeds and integrations | Embedded blocks may convert to Markdown, keep raw markup or be dropped | List each embed type used in your spaces and check how each one appears in the repository |
| Site settings and branding | Expected to stay in GitBook rather than in repository content | Record custom domains, theme, visitor access, redirects and team permissions, since these must be rebuilt elsewhere |
| Revision history | Git commits record changes made after sync is enabled | Ask whether earlier GitBook page versions are carried into commit history or stay only in GitBook |
| Comments and annotations | Unlikely to appear as Markdown content in the repository | Export comments separately if you need them, and ask GitBook how they can be retrieved |
| Completeness check | The repository is the only complete copy once the contract ends | Compare page count and file list against each space, keep a dated snapshot of the repository and sign off the checklist before cancelling |
What Git Sync does not carry and how to recover each item
Git Sync moves page content, not the configuration and access model around it. The cards below cover the items that stay behind in GitBook, how to record or rebuild each one, and what to confirm with GitBook before the contract ends.
Site settings and branding
Site title, custom domain, navigation structure outside the repository, favicon, theme and footer links live in GitBook's site configuration rather than in the synced Markdown. Before ending the contract, screenshot every settings page and record the custom domain, redirects and public URL structure in a file in the repository. Ask GitBook which settings, if any, are represented in the synced files, because this varies by how the space was set up.
Integrations and embedded tools
Third-party integrations, OAuth connections, webhooks and embedded widgets are configured inside GitBook and are not stored as Markdown. List each integration, its purpose and the system it feeds, then note which pages depend on embeds so you can replace them with plain links or the equivalent embed in the target wiki. Confirm with GitBook which integrations are active on the space and whether any were set up by a former administrator.
Permissions and user accounts
Space visibility, invitations, roles, groups and SSO assignments are managed in GitBook's administration area and are not exported through Git Sync. Export the member list and role for each space while you still have admin access, and map each role to the permission model of the target platform. Store the export outside GitBook, since it will not be available after the contract ends. Confirm with GitBook how to export the member list and whether contractor or guest accounts appear in it.
Analytics and search history
Page view counts, search queries, feedback votes and visitor data are collected by GitBook's hosted service and do not appear in the repository. Decide whether this history matters for content planning or audit evidence, and if so, export whatever reports the admin dashboard offers as files. Do not assume a Git export carries it. Confirm with GitBook the available export formats and how far back the data goes.
Published site customizations
Custom CSS, layout overrides, custom code blocks, hidden or password-protected sections and public site access rules are applied in GitBook's publishing layer. Inventory each customization on the live site, rebuild it in the target platform's theme or page settings, and test the public URLs against your redirect map. Confirm with GitBook whether any customization is stored in the repository and whether the published site will remain reachable after the subscription ends.
Enabling Git Sync and running a complete export
This sequence connects GitBook's Git Sync to a repository your organization controls, copies the full site into it, and confirms the copy matches the source before edits stop. It produces a verified Markdown snapshot that you keep independently of the GitBook subscription.
Confirm who can enable Git Sync
Ask the workspace owner or an organization admin to confirm which role may set up Git Sync on each site, since permissions can depend on plan and organization settings. Check GitBook's current documentation for this before you start. Record the names of the people who will authorize the repository connection, run the final sync and approve the sign-off. The output is a short written list of accounts with the access each one needs, which you can check against the owner list of the target repository in GitHub or GitLab.
Connect the GitHub or GitLab repository
An admin opens the Git Sync settings for the site in GitBook and authorizes the GitHub or GitLab account that will own the target repository. Use a new, empty repository owned by the organization, so the export is not tied to an individual's account. Grant GitBook only the repository access it requests, and confirm the write permission on the host side. The check is that the connection shows as active in GitBook and the repository appears under the account you expected.
Choose the branch that holds the export
Select a dedicated branch for the sync, such as one named for the migration, so the default branch stays clean until you decide what to promote. Record the branch name in your migration log. Before the first sync runs, confirm that the branch GitBook will write to matches the one you selected. The output is a documented branch name and a repository you can clone to a local machine for later checks.
Wait for the first full sync
Let GitBook complete the initial sync, which pushes the pages and assets of the site to the selected branch. Run time depends on the size of the site and is not fixed, so watch the sync status in GitBook and the commit history in the repository before you assume it has finished. Do not edit content during this run, because changes made mid-sync can leave the copy in an uncertain state. The check is that the initial push appears complete in the commit history and GitBook reports no sync error.
Compare page counts and spot-check images
Count the Markdown pages in the repository and compare the total with the page list in GitBook's navigation, including pages nested under groups and any hidden or unpublished pages you need to keep. Open a sample of pages that contain images, embeds and tables. Confirm the image files are committed to the repository and that pages do not depend only on links to files hosted by GitBook. Record every mismatch. The output is a reconciled count with a written list of known differences.
Freeze edits for the final pass
Announce a content freeze to the authors and apply the restriction your team has agreed on, such as limiting edit rights on the site for the duration of the final pass. Any edit made after the last sync will be missing from the repository, so the freeze is what makes the export complete. Ask each editor to confirm in writing that their work is saved and published. The check is that no new changes are expected, and the most recent page edit in GitBook predates the freeze.
Run the final sync and recheck the repository
Trigger a final sync after the freeze, then repeat the page count and image checks against the new commit. Clone the repository fresh to a clean machine, confirm the Markdown renders, and confirm that the navigation structure matches the site. Save the final commit hash in your migration records. The output is a complete, dated repository snapshot that you can archive before the GitBook contract ends.
How to check the repository is complete before ending the contract
Start by treating the Git repository as a claim that needs testing, not a finished copy. Before you give notice on GitBook, build a page inventory from the GitBook side: list every published page and every draft in each space, including pages hidden in unpublished changes and anything sitting in a space that is not public. Record each page's path in the navigation tree. Then compare that list with the repository. Count the Markdown files, check that the folder structure mirrors the navigation order, and confirm that the SUMMARY.md file or equivalent table of contents lists every page you expected. Gaps usually appear in drafts, in pages nested several levels deep, and in pages whose titles were changed after they were first synced.
Next, open a sample of pages by hand, and choose the ones most likely to break. Pick pages with tables, code blocks, embedded content such as videos or third-party widgets, callouts, tabs, and images. Check that tables survived the conversion, that code fences kept their language tags, that embeds became plain links or were removed deliberately, and that every image file exists in the repository and renders from its relative path. Then test internal links across the whole set, not only the sample, using a link checker run against the exported files. A link that points to a GitBook-only URL form will not resolve in Wiki.js, BookStack or Docmost, so log those and decide how each one will be rewritten.
Finally, keep a dated snapshot and get the gaps in writing. Tag the commit you verified, archive a copy of the repository outside GitBook, and record the export date beside the page inventory. Then ask GitBook to confirm in writing which content does not sync through Git Sync, such as site settings, custom domains, integrations, and access and permission configuration, and which known limitations apply to your spaces. Anything they name goes on your own list to rebuild or retain. Do this before the contract ends, while your administrators can still reach the GitBook space to compare what they see against the repository.
Which export path fits your team: Git Sync, manual export or a migration partner
If the site is a few dozen pages made mostly of text, a team can often move it by hand or by enabling Git Sync and making a short cleanup pass. The effort comes from reading pages and checking formatting, so it grows with page count and with how many GitBook-specific blocks the pages use.
- Copy by hand. Paste pages into Markdown files or directly into the target wiki editor. This works when there are few pages and few attachments to track.
- Use Git Sync first. Turn on Git Sync so the content lands as Markdown in a GitHub or GitLab repository, then review and fix those files directly.
- Check formatting. Look for tables, callouts, embedded content and tabbed blocks that may not carry over cleanly to plain Markdown.
- Count the staff hours. The main cost is people's time for reading and correcting pages. It is mostly one-time, although any pages you keep editing in two places during an overlap period add recurring effort.
Before you end the contract, compare the page count in GitBook with the number of Markdown files in the repository and note any gaps.
Sites with many spaces, deep navigation, versioned content or large image libraries make manual copying impractical. Git Sync can carry the Markdown into a repository, but image handling, link rewriting and navigation mapping become scripted or reviewed work that needs a named owner.
- Repository structure. Confirm how Git Sync maps spaces, navigation and page order to folders and files before you build anything on top of that structure.
- Images and attachments. Check whether referenced images are stored in the repository or still point to hosted storage, and decide where they will be served from after the move.
- Link rewriting. Internal links often depend on GitBook URL paths. Script the rewrite, then test a sample of pages across every space.
- Staff time. Effort is driven by the number of spaces, the image count, link density and how many people review the output. The move itself is one-time work, while keeping two sites in step during overlap is recurring.
Ask your GitBook administrator which assets Git Sync includes and which remain external before you size the work.
Banks, healthcare providers and public bodies often need to show who exported their documentation, when, and that nothing was lost. Git Sync gives you a versioned history, but defining, retaining and presenting the evidence trail is your responsibility, and the format must suit your assessor.
- Export record. Keep the repository commit reference, the date, and the name of the person who enabled Git Sync, filed alongside your change records.
- Completeness check. Compare the page inventory in the repository with the list of pages in GitBook, and sign off the result as evidence.
- Repository access. Restrict who can read exported documentation, especially where some GitBook content was public and other content was private, so permissions carry over correctly.
- Retention. Decide how long the exported repository and a final snapshot are kept, aligned with your records retention policy.
- Control time. Designing the evidence and reviewing it is recurring effort in each audit cycle. DeployOpen prepares systems, controls and evidence for assessment, but independent auditors and certification bodies issue any audit report or certification.
Confirm with your assessor which evidence format they accept before the export starts, so the record is not rebuilt afterward.
A migration partner takes on planning, scripted conversion, verification and cutover under a written scope. This suits teams with limited staff time, large content volumes, or a fixed contract end date. DeployOpen plans and implements these engagements as fixed-scope work, with scope, deliverables and timelines agreed in writing before work starts.
- Scope and deliverables. Ask for the export, the completeness check, the target setup and the cutover each to be a named deliverable with an agreed timeline.
- Verification. Ask for a page-by-page comparison between GitBook and the repository, which your own reviewers can sign off.
- Target platform setup. Hosting, backups, access control and sign-in for the new wiki are separate components that appear in the quote.
- Quote drivers. Number of spaces, asset volume, link complexity, approval steps and length of any overlap period all change the price. Ask for each to be listed separately.
- Recurring costs. Support, upgrades and continuous testing are available as retainers, so ongoing cost depends on whether you keep a support arrangement after cutover.
Before you sign, ask the partner to show how the completeness check will be recorded and who on your side accepts it.
Questions buyers ask before exporting from GitBook
How much effort does a full GitBook export take?
The effort depends mostly on how much content is in scope and how much of it uses GitBook-specific structure. Turning on Git Sync is a configuration step, but the work that takes the most time is reviewing the output, converting custom blocks and embeds, and fixing internal links and images. The main drivers are:
- The number of sites, spaces and pages in scope
- How many GitBook-only blocks, embeds and custom components need rewriting in plain Markdown
- The volume of images, attachments and internal links to check
- The target platform, since Wiki.js, BookStack and Docmost each handle Markdown imports differently
No supplied figure gives a duration for this work. Ask any partner to size it from an inventory of your actual sites and pages, and ask GitBook which parts of your content it syncs as Markdown.
Can a GitBook admin export content without outside help?
Often yes, for the sync itself. An admin with the right role can connect a GitHub or GitLab repository and turn on Git Sync, which writes the content out as Markdown. Confirm in GitBook's current documentation which roles are allowed to enable it, because that depends on your plan and workspace setup. Outside help becomes useful afterward, when someone has to review the repository, decide how to handle GitBook-specific blocks, and load the content into the new platform. Docmost's import dialog accepts Markdown files in a ZIP archive, so the exported files can be tested there before any commitment. Check the Docmost import and export documentation for the current formats it accepts.
What does the internal team need to provide during the export?
The team needs a few named people, and the work goes faster when each role is decided before the sync starts. Plan for these roles:
- A GitBook admin who can enable Git Sync and confirm which sites are included
- A repository owner on GitHub or GitLab who controls access, branch protection and retention for the exported content
- A content owner for each major space who signs off on the review
- An identity owner if the new wiki will use single sign-on, since sign-in settings are configured separately
- A hosting or DNS owner for the target platform and the docs domain
Agree in writing who approves the final repository, because that approval is the handoff point before the GitBook contract ends.
How long does a GitBook export take to complete?
No supplied fact gives a duration for GitBook's Git Sync or for the review that follows, so no figure should be planned from this page alone. The time depends on the size of each site, the number of pages and attachments, and how many items need manual cleanup. Ask GitBook support how long a sync of a site of your size is expected to take, and ask your implementation partner to base the timeline on a dry run against a copy of your largest site. A written timeline should separate the sync, the review and cleanup, the test import into the new platform, and the final cutover, because each stage has a different owner.
Does a GitBook export carry over page history and past versions?
Confirm this before you rely on it. Git Sync writes the current published content into the repository as Markdown, and the Git history in that repository starts from the point the sync is set up. Earlier GitBook revisions may not appear as individual commits, so the history you keep in the new platform may be shorter than what GitBook shows. If past versions matter for audit or internal reference, keep a separate archive of the GitBook site before you end the contract, and record what that archive contains. Ask GitBook directly which revisions are included in the repository, and ask any partner how they plan to preserve history that does not sync.
What does Git Sync leave behind, such as site settings and integrations?
Git Sync moves page content, not the configuration around it. Site settings, integrations, access rules, custom domain setup, analytics and search configuration are typically outside the Markdown content, so they must be rebuilt on the new platform. Confirm the exact list in GitBook's current documentation for your plan. Plan to recreate these items in the target system:
- Navigation and table of contents, which may need to be rebuilt from the repository's structure
- Sign-in and access rules, configured again through the target's own authentication settings
- Integrations and embeds that depend on GitBook services
- Custom domain and redirects for existing public links
Wiki.js can use Git storage that synchronizes in both directions, which is useful if the repository stays the source of truth during a transition. Check the Wiki.js storage documentation for how that sync is configured.
How do I confirm the repository is complete before ending the GitBook contract?
Treat the repository as complete only after a documented check passes. Compare the page count in GitBook with the Markdown file count in the repository, then sample pages from each space and read them against the live site. Check that every image and attachment resolves, that internal links point to the right files, and that no GitBook-only markup appears as raw text. Load a copy into the target platform as a test import, and keep the export and the check results in a dated record. Keep the GitBook contract active until that test import and the sign-off are complete. This record supports your own change and records process, but it is not an audit report or certification.
What should I ask a partner for in a written export quote?
Ask for a written, fixed scope that names each deliverable, so the quote can be compared with other options. DeployOpen works from agreed written scopes, and a quote follows from that scope, so the document should list:
- Which GitBook sites, spaces and revisions are in scope
- The export method and who enables Git Sync
- How GitBook-specific blocks and links will be converted, and what is excluded
- The verification method and the evidence delivered at the end
- The target platform installation, configuration and data load
- Your responsibilities, such as repository ownership, reviewers and DNS changes
- Support or retainer options after cutover
Ask what is one-time and what recurs, including hosting and maintenance of the new platform, which are your costs regardless of who does the work.
What to plan before the GitBook contract ends
The GitBook export is only as complete as the steps around it. Notice periods, read access, repository ownership, backups, domains and sign-off decide whether the Git copy can stand in for the live site. Work through these cards before you send a non-renewal notice.
Confirm the notice window and renewal date
Ask GitBook in writing for your renewal date, the notice period and whether the contract renews automatically. Export work takes time, so the Git copy should be complete before the last date you can cancel without another billing period. Note which sites and seats are on the invoice, because per-site and per-user fees can continue for every item still active on the renewal date.
Keep read access through cutover
Decide whether teams need to read GitBook while the new wiki goes live. Keep the workspace and published sites open until the self-hosted copy has passed review, and confirm with GitBook which access level remains after the contract ends. Plan one owner for every link that points at a GitBook site so readers are not sent to a dead address during the switch.
Assign the repository owner
Name one person or team that owns the GitHub or GitLab repository created by Git Sync. That owner controls who can merge, delete branches and change repository settings. Keep at least two administrators on the account so the repository does not become inaccessible if one person leaves. Record who holds the Git Sync connection and revoke it once the export is confirmed.
Back up the repository before the contract ends
Make a full clone of the synced repository, including all branches and history, and store it outside the hosting provider. Keep a second copy in your own storage that you control. Verify the clone by opening a fresh checkout and reading several pages, including long pages and pages with images. A backup taken before the final sync can miss the last edits, so repeat it after freezing content.
Map custom domains and redirects
List every custom domain, subdomain and public URL that points to GitBook. Decide where each address will point after cutover and who updates DNS records. Build a table of old paths and new paths so search engine links, bookmarks and internal references keep working. Remember that a Wiki.js instance needs its own dedicated domain or subdomain and cannot sit under a subfolder.
Name who signs off on completeness
Set a written acceptance step before the contract ends. Assign a content owner to compare page counts, navigation and key documents against the live GitBook site, and a second reviewer to confirm access and backups. Record what does not sync, such as site settings, integrations and analytics, so that gaps are known and accepted rather than discovered later. Keep the sign-off record with the contract file.
Where the exported Markdown goes next
The Git repository is the portable copy of your GitBook content, so treat it as the thing you are migrating, not as an intermediate step. Once the repository holds every page and asset you need, the destination tool is a separate decision. Wiki.js can read the repository directly through its Git storage module, which synchronizes content in both directions, so pages edited in the wiki can be committed back to the repository. The stable line is Wiki.js 2.x, with the repository at requarks/wiki-v2 and the release v2.5.316 published on October 2, 2026. The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and not for production use, so confirm the current status of 3.0 before you plan around it. Check the Wiki.js storage documentation for the exact Git module settings, branch and credentials your setup needs.
BookStack and Docmost take a different route. Neither reads a Git repository as a live source, so you import content by file. Docmost's import dialog accepts Markdown and HTML files, including inside a ZIP archive, and it lists a Notion export ZIP and a Confluence export among its inputs. Its documentation also lists the Confluence, DOCX and PDF importers as paid-edition features, so confirm which importers your edition includes before you plan an import. BookStack is MIT licensed, and its v26.09.1 release, published on September 29, 2026, requires PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 or later. Whichever tool you choose, test the import on a copy of the repository, then compare page counts, internal links and image paths against the source before you cut over.
The migration pages cover the detail for each path: syncing content to a repository, connecting the wiki, cleaning GitBook-specific blocks, mapping navigation and redirects, and cutting over the docs domain. Read the Wiki.js migration page before you decide, because a live Git connection changes who owns the source of truth after cutover. Ask your team which system will hold the canonical copy of each page, and who may write to it, before the first import runs.
How DeployOpen scopes and delivers a GitBook exit
DeployOpen treats a GitBook export as a scoped engagement with written deliverables, not a one-off copy job. We agree what content, repositories and checks the exit covers, build the target platform in your own infrastructure, and document how the Git export was verified before the contract ends.
How we scope
- Inventory every GitBook space, published site and content revision to be exported, and record which ones are in scope
- Confirm who in your organization can enable Git Sync and which GitHub or GitLab repository will receive the Markdown
- List site settings, integrations and custom domains that Git Sync does not carry, so each one is handled by hand
How we build
- Set up the Git Sync repository and check the Markdown structure, navigation files and attachment paths against the live site
- Compare exported pages with GitBook page counts and spot-check representative pages, including embeds and GitBook-specific blocks
- Load the content into the chosen target, such as Wiki.js, BookStack or Docmost, and test internal links and redirects
How we hand over
- Deliver a written export record covering the repository location, commit history, page inventory and known gaps
- Document the steps your team would follow to repeat the export or keep the repository current before the contract ends
- Provide a checklist of settings, users and integrations to recreate manually, with owners named in the written scope
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Ask for a written quote that follows from the agreed scope, since DeployOpen does not publish a price list
