How to migrate from GitBook to Wiki.js through Git
If your GitBook renewal is coming up, or a per-site and per-user cost review or a residency requirement has put hosted documentation outside your control, the migration path runs through a Markdown repository that both tools can read. GitBook's Git Sync writes your content to GitHub or GitLab as Markdown, and Wiki.js's Git storage module can read that repository back and keep it in step. The real work is content cleanup, navigation mapping and the domain cutover, not a data transfer. Platform or docs engineers usually run the migration with a content owner who knows which spaces are current, which are public and which can be retired. Plan for the cleanup to take the most effort, since GitBook-specific blocks such as hints, embeds and tabs will not render the same way in Wiki.js and must be converted by hand or with a scripted pass that the team reviews.
Choose Wiki.js 2.x for production. The stable line is 2.x, with v2.5.316 published on October 2, 2026, in the requarks/wiki-v2 repository. The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and not for production use, so do not plan a live docs site on it. Confirm the current 2.x release and its supported database before you build, because Wiki.js 2.x recommends PostgreSQL 9.5 or later and needs the pg_trgm extension for its PostgreSQL search module. Wiki.js also requires a dedicated domain or subdomain, so the docs domain you cut over to will need its own hostname rather than a subfolder of your marketing site.
Run a short pilot on one space before you move everything. Export the space through Git Sync, point a test Wiki.js instance at the repository, and check navigation order, internal links, images and redirects from the old GitBook URLs. Record the decisions you make for each block type so the same rules apply to the rest of the content. Keep GitBook live and read-only until the new site has passed your review, and confirm with your identity team which sign-in method the Wiki.js authentication module will use before you open the site to readers. Ask your own environment owners to confirm the hosting, backup and sideloading arrangements for any air-gapped or residency constraints, because those decisions shape the effort more than the Markdown conversion itself.
Which GitBook features move cleanly to Wiki.js
This table maps the GitBook capabilities most teams rely on to their Wiki.js equivalents and marks each as clean, needs rework, or gap. Read it as a checklist for the content you actually have: clean rows move with little change, rework rows need conversion work, and gap rows need a decision or a confirmed alternative before cutover.
| GitBook capability | Wiki.js equivalent | Status |
|---|---|---|
| Markdown pages in a Git-synced space | Git storage module, two-way sync with a GitHub or GitLab repository | Clean |
| Spaces and collections | Page tree and path structure; map each space to a top-level path | Needs rework |
| GitBook-specific blocks and embeds | Standard Markdown or custom HTML blocks; convert hints, tabs and embeds by hand | Needs rework |
| Visual editor content | Wiki.js visual editor; confirm that layout blocks survive the export | Needs rework |
| Navigation (SUMMARY.md) | Wiki.js navigation editor; rebuild the tree from the summary file | Needs rework |
| Redirects from old GitBook URLs | Confirm redirect handling in your Wiki.js version and at the proxy or DNS layer | Gap to confirm |
| Custom domain and public docs site | Dedicated domain or subdomain; Wiki.js cannot run in a subfolder | Needs rework |
| Site-level settings and integrations | No direct equivalent; list each integration and confirm a replacement | Gap to confirm |
| Analytics | Not built in as a GitBook equivalent; choose and self-host a separate tool | Gap to confirm |
| Permissions and SSO | Wiki.js authentication modules including SAML and OpenID Connect; verify parity with your current GitBook plan | Gap to confirm |
What data and integrations to move from GitBook
A GitBook migration to Wiki.js has four separate inventories: the content in Git, the assets that sit beside it, the user identities, and the integrations around the site. Only the first is covered by a documented export path, so the others need to be listed by hand before the contract ends.
Content through Git Sync
Enable GitBook Git Sync so every page is written to a GitHub or GitLab repository as Markdown, then treat that repository as the single source for the migration. Confirm the sync is two-way and current, because Wiki.js will read from the same repository. Check that every space and every published variant appears in the repo, and compare page counts against the GitBook site before you end the contract. Pages that exist only in the editor are not part of this path.
Assets and images in the repository
Images, PDFs and other attachments must be present in the repository, not only referenced by GitBook-hosted URLs. Search the Markdown for links that point to GitBook's asset host and plan to download and rewrite them to repository paths. Large binaries also affect repository size, so decide early whether they stay in Git or move to object storage. Confirm which file types your Wiki.js instance will serve from Git storage.
User identities and access
GitBook accounts and space permissions do not move with the Markdown. Recreate access in Wiki.js through an authentication module such as SAML 2.0, OpenID Connect or LDAP, and map the groups that currently hold edit or view rights in GitBook. Decide which pages stay public, which need sign-in and which are restricted to named groups. Confirm TOTP requirements for administrators before cutover.
Webhooks and automation
Any GitBook webhook, Slack notification or CI job that publishes or reacts to doc changes has no equivalent in the export. Inventory each one in GitBook's integration settings and decide whether it is rebuilt against the Git repository, replaced by a Wiki.js webhook, or dropped. Note who depends on each one, since a dropped notification is often discovered only after cutover.
Search, analytics and embedded tools
GitBook's hosted search, page analytics, feedback widgets and embedded third-party content are configured in site settings, which the Git export does not include. Record each script, iframe, embed and analytics tag by hand. Wiki.js provides its own search through the PostgreSQL search module, which needs the pg_trgm extension, so confirm that behavior matches what readers expect. Replace or drop each embed and document the decision.
Custom domain and site settings
Site settings such as custom domains, redirects, navigation structure, visibility and SEO metadata must be recorded manually from the GitBook admin pages. Wiki.js requires a dedicated domain or subdomain and cannot run from a subfolder, so the docs URL structure will change. Build a redirect list from the old public URLs before the DNS cutover, and confirm how your reverse proxy will serve it.
The migration sequence from inventory to decommission
This sequence moves GitBook content into a Git repository that Wiki.js reads, proves the copy is complete, and retires GitBook only after both systems have been checked against each other. Each step produces an artifact that the next step depends on.
Inventory spaces, pages, assets, users and public URLs
Before moving anything, list every GitBook space, its page tree, the images and files each page embeds, the people with edit and view rights, the integrations and custom domains attached to each site, and every public URL that other sites or search results link to. The docs owner for each space signs off the list, and the output is a URL map that pairs each current GitBook address with its planned Wiki.js path. Without this map, the cutover later has no reference for redirects.
Sync GitBook content to a Git repository
Enable GitBook's Git Sync for each space so the content lands in a GitHub or GitLab repository as Markdown. Someone with the right GitBook permissions must enable it, because the sync covers page content and not site settings or integrations, which the inventory must record separately. Compare the repository against the page list and the asset list from step one, and confirm that every page and image appears. The output is a verified repository with a short completeness report that names any gaps and how each was closed.
Clean GitBook-specific blocks in the repository
GitBook adds its own syntax, such as hint blocks, embeds, tabs and content references, that Wiki.js does not render as written. Convert these blocks to standard Markdown or to the Wiki.js equivalents, rewrite internal links to match the URL map, and fix the table of contents file that defines navigation. Run a link checker across the repository so broken internal references are found before the pilot rather than by readers. The output is a branch where the content renders cleanly in a local preview.
Run a Wiki.js 2.x pilot on a dedicated subdomain
Install the stable Wiki.js 2.x line from the requarks/wiki-v2 releases on a dedicated domain or subdomain, because Wiki.js cannot be mounted under a subfolder of an existing site. Use PostgreSQL, which the requirements documentation recommends for 2.x, and enable the pg_trgm extension if search is needed. Connect the Git storage module to the verified repository, set it to sync in both directions only after the team has agreed where edits are made, and set up the authentication module your identity provider uses. Ask the pilot reviewers to check navigation, search, permissions and the redirect plan, and record their sign-off in writing. The output is a pilot sign-off that lists any open defects.
Run a parallel period with one editing source
While readers use both systems, name one system as the editing source for each space and state it in the repository README and on the GitBook space home page. Changes made in the other system must be moved across or reverted, so the team should decide early whether Git or the Wiki.js editor is the source of truth. Re-run the completeness check on the repository at intervals agreed by the owners, and compare sample pages in both systems for drift. The output is a dated record of which system owned each space and a list of content that was reconciled.
Cut over the docs domain and publish the redirect map
Write a cutover runbook that lists the DNS change for the docs domain, the redirect rules from each old GitBook address to its Wiki.js path using the URL map, the rollback steps, and the people who approve each action. Run the cutover in a window the owners agree, then test a sample of redirects from outside the network and watch access logs for 404 errors on old paths. The output is a live docs domain and a runbook marked as executed, with the rollback path still documented.
Archive the GitBook export and decommission
Keep the repository and a dated export of the GitBook spaces, including the asset folders, in storage your organization controls, and record the checksum or retention location so the copy can be found later. Confirm that GitBook has no remaining public links that readers depend on, remove integrations and custom domains, and then request cancellation through your contract terms after checking the notice period with GitBook. The output is an archive record, a closed decommission ticket and the contract cancellation confirmation.
What drives the cost and duration of the migration
This table lists the cost components and the effort drivers for moving GitBook spaces into a Git-backed Wiki.js site. Read the driver rows first to size the work, then the cost rows to see who is paid and which costs recur. No duration figure is supplied, so confirm estimates against your own page inventory.
| Driver or component | Why it moves cost or effort | How to keep it down or what to confirm |
|---|---|---|
| Page and asset volume | Every page needs a Markdown file, and every image or attachment must be copied into the repository and re-linked. Volume sets the review and QA workload more than the sync itself. | Prune stale, duplicate and draft pages before the first sync. Ask for a page and asset count per space before agreeing scope. |
| Number of spaces and variables | GitBook variables and space-level settings do not carry over automatically. Each space that needs its own navigation or variables adds restructuring work. | Consolidate related spaces into one Wiki.js site where the audience allows. Document every variable and its replacement in a mapping sheet. |
| GitBook-specific blocks and embeds | Hints, tabs, cards, embedded widgets and proprietary blocks must be converted to Markdown or Wiki.js syntax, or removed. Each block type is a repeatable fix, but unusual embeds need manual rework. | Inventory block types across the repository with a search before migration. Standardize templates so fewer block patterns remain. |
| Public versus private docs | Public spaces need an anonymous read path, a stable public address and checks that no internal content leaks. Private spaces need group-based access rules configured per page or path. | Separate public and private content into distinct paths or sites early. Review access rules with the content owners before cutover. |
| Identity integration complexity | Wiki.js offers several authentication modules, including SAML 2.0 and OpenID Connect, but each needs group mapping, test accounts and a sign-in check. Complexity grows with the number of identity sources. | Confirm which identity provider is the source of truth. Map groups to Wiki.js permissions once, in writing, and test with real roles. |
| Public URLs needing redirects | Existing GitBook links, including deep links and search-indexed pages, break when the path structure changes. Each unmapped URL is a support ticket or a dead link. | Export the list of public URLs from analytics or the sitemap. Build a redirect map from old paths to new paths before the domain change. |
| Editor retraining | Editors used to GitBook's visual editor and Git Sync must learn the Git workflow, Markdown conventions and Wiki.js editing. Time spent on training depends on how many people edit content. | Count active editors per space. Provide a short guide for the Git workflow and a template for each common page type. |
| Internal staff time (one-time) | Staff time covers inventory, conversion, review, redirect mapping, access testing and cutover. Most of this is paid once, as internal salary or contractor time. | Ask your team to log hours by task during the pilot so the next estimate is based on your own data. Confirm who signs off each space. |
| Server, database and backups (recurring) | Wiki.js needs a host with at least 1 GB of RAM on Linux, a supported database such as PostgreSQL 9.5 or later, and backups. These are paid monthly or yearly, and they continue after cutover. | Right-size the host with your own traffic data. Include backup storage and monitoring in the running cost, not only the initial build. |
| DNS, TLS and domain setup (one-time and recurring) | Wiki.js needs a dedicated domain or subdomain, and it cannot run under a subfolder. The domain change is a one-time setup, and certificate renewal recurs. | Confirm the subdomain and the certificate renewal process with your network team before cutover. Keep the old GitBook domain redirecting for a set period. |
| External implementation fee (optional, one-time) | A partner can plan, convert, test and cut over the migration under a written fixed scope. Fees depend on the agreed scope, not on a published price list. | Ask for a written scope listing spaces, pages, identity integration, redirects, training and handover. Request the quote to show each deliverable and any ongoing support as a separate item. |
How to run both docs sites in parallel and cut over the domain
During the parallel period, pick one editing source and make it the Git repository. Once Wiki.js is connected to the same repository through its Git storage module, which synchronizes in both directions, authors change Markdown in the repository or in the Wiki.js editor, and both paths end up in one history. The risk to plan for is split edits: a page fixed in GitBook while the same page is changed in Wiki.js produces a merge conflict or a silently lost change. Freeze the GitBook space for editing once the sync is verified, or agree in writing which team edits which space and for how long. Confirm with your GitBook plan owner whether Git Sync keeps pushing changes from GitBook to the repository while you test, and whether anyone can still edit in GitBook after you stop relying on it.
Wiki.js needs its own domain or subdomain and cannot be mounted on a subfolder, so the existing GitBook URLs will not carry over by moving paths. Plan the redirect layer at DNS or at the edge, for example a reverse proxy or CDN rule that maps each old path to its new address. Build the redirect map from the repository's file list and the GitBook navigation, then test a sample of old URLs, deep links, anchors and search-engine landing pages against the new site before any DNS change. Run a link checker across the Wiki.js site and check that internal links, images and attachments resolve, and that search returns the expected pages. Lowering the DNS TTL on the docs record well ahead of the change lets you roll back quickly if something breaks. Keep the GitBook site and its published domain configuration intact until the rollback window has closed, and record who can make the switch back and how long it takes them to do so.
What goes wrong in a GitBook to Wiki.js migration
Most failed GitBook to Wiki.js moves fail in the same few places: the export, the links, the release channel, the database setup, the cutover window and the public URLs. Each card below names one of these risks and the check to run before the docs domain changes hands.
Incomplete Git export
GitBook Git Sync carries page content and assets, but site settings, integrations, navigation configuration and some published-site details may not appear in the repository. Treat the repository as a content copy, not a full site backup. Before cutover, compare the page count and asset folders against the live GitBook space, and list every setting you rely on (navigation order, custom domain, search, access rules) so you can recreate it by hand in Wiki.js.
Broken internal links after path changes
GitBook links often point to relative paths or to pages by their GitBook URL. Wiki.js builds page paths from the storage folder layout, so a file moved into a different folder changes its address and every link pointing at it breaks. Run a link check across the imported Markdown, rewrite internal references to the new Wiki.js paths, and confirm that image and attachment links still resolve after the sync.
Wiki.js 3.0 beta in production
The main requarks/wiki repository holds Wiki.js 3.0, which its README marks as beta and not for production use. Pin production deployments to the stable 2.x line in the requarks/wiki-v2 repository, and record the exact release you tested. Ask your platform team to confirm the release channel in your change ticket before anyone points the docs domain at the new instance.
Database and search misconfiguration
Wiki.js 2.x recommends PostgreSQL 9.5 or later, and its PostgreSQL search module needs the pg_trgm extension. If the extension is missing, search can fail or return poor results while the wiki still appears to work. Create the extension during installation, run a search test against migrated pages, and confirm the database version meets the documented minimum in your staging build.
Edits in both systems after cutover
Once Wiki.js is live, teams may keep editing GitBook out of habit, and Wiki.js Git storage syncs in both directions, so conflicting changes can collide in the repository. Set a freeze date for GitBook edits, make the repository the single source of truth, and turn GitBook into a read-only archive or remove editor access before the docs domain moves. Agree who owns merge decisions for the first weeks.
Lost redirects for public URLs
Public GitBook URLs are likely to be bookmarked, linked from support tickets and indexed by search engines. Wiki.js requires a dedicated domain or subdomain and cannot be mounted under a subfolder, so every old path needs a planned mapping. Build a table of the most-visited GitBook URLs, configure redirects from the old domain to the new paths, and check a sample of them after the switch.
How the migration changes by team size and starting point
When the GitBook space already syncs to a GitHub or GitLab repository, most of the content is already Markdown under version control. The migration becomes mainly a question of pointing Wiki.js at that repository and deciding how the two-way Git storage will behave in production. Engineers can own the work because the content, review process and history already live in Git, and the GitBook export step is largely verification rather than extraction.
- Sequence: confirm the repository is complete, then stand up Wiki.js and connect its Git storage module to the same repository before any content changes.
- Owners: the repository maintainers and a platform engineer who runs the Wiki.js host, with the docs owners reviewing the rendered output.
- Effort drivers: GitBook-specific syntax in the Markdown, such as embedded blocks and custom components, and any pages that depend on GitBook's own site settings.
- Branch strategy: decide which branch Wiki.js tracks and how pull requests are merged, since two-way sync can write changes back.
- Ownership of the repo: confirm who holds admin rights so the sync credentials are scoped to this repository only.
Before cutover, check that a sample of pages renders correctly in Wiki.js and that edits made in either direction arrive where expected.
When product managers, support staff or operations editors work in GitBook's visual editor, the technical move is smaller than the change in daily habits. Those editors will need to learn Wiki.js editing, whether that is its visual editor or Markdown, and they may no longer have GitBook's familiar interface for comments, change requests and published previews. Plan the migration around training and content ownership as much as around the import.
- Sequence: identify which spaces have non-engineer editors, pilot one space with them, and only then move the rest.
- Owners: a content lead for each space who decides the editing workflow, plus the platform team for storage and permissions.
- Effort drivers: the number of visual-editor users, how much content they change each week, and whether they expect a Git-based review step.
- Editing model: decide whether these editors write directly in Wiki.js or submit changes through Git, and document that choice.
- Access: map which GitBook roles correspond to Wiki.js groups and check each editor can still reach the pages they maintain.
Confirm with the editors that every page they own has been reviewed in its new form before the old space is made read-only.
A public documentation site with many pages and years of inbound links changes the migration mainly through its URLs. Readers and search engines arrive at existing GitBook paths, so the plan must map every old path to its new location and keep those redirects working after the docs domain is moved. Wiki.js also requires a dedicated domain or subdomain and cannot be mounted under a subfolder, which shapes how the cutover is planned.
- Sequence: build the full URL inventory first, then the mapping table, then stand up Wiki.js on the new hostname, then cut over DNS.
- Owners: the docs lead for content and navigation, the web or platform team for DNS and redirects, and whoever manages search and analytics.
- Effort drivers: the number of indexed URLs, the number of external links pointing into the site, and how many pages depend on GitBook navigation.
- Redirects: decide where redirect rules live, and test a sample of high-traffic paths before the switch.
- Public hosting: confirm where the self-hosted site will be served and how it will handle traffic spikes.
Check the redirect map against the analytics for the last full year, so high-value legacy URLs are not missed.
An internal wiki used across the company usually needs its sign-in, access groups and audit expectations to carry over unchanged. Wiki.js offers several authentication modules, including SAML 2.0, OpenID Connect, LDAP and Active Directory and TOTP two-factor authentication, so the identity work is mostly configuration and testing. The effort depends on how cleanly access in GitBook maps onto the groups in the identity provider.
- Sequence: set up the identity provider connection in a non-production instance first, then migrate content, then restrict access on the production site.
- Owners: the identity team for the provider configuration, the security team for access rules, and the platform team for hosting.
- Effort drivers: how many access groups exist, whether pages are restricted per space or per page, and whether the identity provider already holds the right group membership.
- Access review: export the current GitBook membership and reconcile it with the directory before users are moved.
- Logging: confirm which sign-in and access events the team needs to retain.
Check with the security team that the access model in Wiki.js matches the approved policy before any internal user is pointed at it.
Questions buyers ask before migrating from GitBook to Wiki.js
How much effort does a GitBook to Wiki.js migration take, and who does the work?
The effort depends mainly on how many spaces, pages and custom blocks you have, and on how much of the new setup you want handled for you. The work usually splits into four parts: exporting the content to a Git repository, cleaning GitBook-specific blocks into standard Markdown, standing up and connecting Wiki.js, and cutting over the docs domain. Your team supplies repository access, content owners for review and sign-off. Wiki.js setup and migration can be done by your own platform or documentation team or by an implementation partner such as DeployOpen under a written scope. Ask any partner to break the effort down by these four parts so you can see where your own staff time goes.
How long does a GitBook to Wiki.js migration take?
The timeline is set by content volume, the number of custom blocks that need rewriting, how many review rounds your content owners need, and how quickly repository, DNS and identity changes are approved. A small space with mostly plain Markdown moves much faster than a large multi-site estate with embedded integrations and many owners. Wiki.js has its own setup dependencies that can add time: it needs a dedicated domain or subdomain because it cannot be mapped to a subfolder, and its 2.x line recommends PostgreSQL 9.5 or later. Ask for a timeline tied to phases and sign-off gates in the written scope rather than one overall date.
Can our own team migrate from GitBook to Wiki.js without outside help?
Yes, many teams can do this in-house if they have someone comfortable with Git, Markdown, Linux server administration and a database. The skills most often missing are Wiki.js administration, OIDC or SAML configuration with your identity provider, and a repeatable process for rewriting GitBook blocks across many pages. Before deciding, check who will own the Git storage sync after launch, who will apply Wiki.js upgrades, and who will handle backups. Outside help is usually most useful for the cutover and for the first upgrade cycle. Confirm the 2.x line you plan to run in the official Wiki.js release notes before you commit.
What does our organization need to provide during the migration?
Plan for five inputs from your side:
- Repository owners who grant access to the GitHub or GitLab repository holding the exported Markdown and the Wiki.js sync account.
- DNS access to create the dedicated domain or subdomain for Wiki.js and to plan the redirect for the old docs domain.
- Content owners for each space who review rewritten pages and confirm navigation.
- An identity contact for SAML or OIDC settings, and a server or cloud account for hosting.
- A named sign-off approver for cutover and for ending the GitBook contract.
Confirm the exact approval chain with your change board, because cutover often needs a maintenance window and a rollback plan.
Is GitBook's Git Sync enough to export everything we need?
Git Sync is a strong starting point because it writes your page content to a repository as Markdown, and it is available on every GitBook plan according to our export guide. It does not automatically carry everything a documentation site relies on. Site settings, integrations, some visual layout choices, and access permissions are typically not part of the repository, so you must recreate them. Before ending the contract, compare the repository against the live site page by page, check images and attachments, and record navigation and redirects in a spreadsheet. Confirm with GitBook what Git Sync includes for your site type, since the export scope is not something this page can verify for every configuration.
How does Wiki.js Git storage keep content in sync with the repository?
Wiki.js offers a Git storage module, and per its storage documentation, some modules including Git synchronize content in both directions. That means edits made in the Wiki.js editor can be pushed back to the repository, and changes committed to the repository can flow into the wiki. This matters for teams that still want Git as the source of truth. Decide early which side is authoritative for each space, because two-way sync with conflicting edits is where teams most often lose content. Test the sync with a sample space, including image paths and deleted pages, before you cut over the production domain.
What does a written scope need to contain before we ask for a quote?
A useful scope lists the spaces and approximate page counts, the GitBook features in use such as custom blocks, integrations and private or published sites, the target Wiki.js version and database, the hosting location and identity provider, the redirect and domain plan, and the acceptance criteria for each phase. DeployOpen does not publish a price list. Most engagements are fixed-scope, so the quote follows from the written scope, with deliverables and timelines agreed before work starts. Ask any provider to itemize hosting, database, identity setup, content conversion, testing, cutover and post-launch support, and to state which items recur each year.
What recurring costs should we expect after moving to self-hosted Wiki.js?
Wiki.js has no license fee under its AGPL-3.0 license, so recurring costs come from the infrastructure and people that run it. Expect a server or container host, a PostgreSQL or other supported database, backups, TLS certificates, a CDN if you publish public docs, and staff time for upgrades and patching. The stable 2.x line is distributed from the requarks/wiki-v2 repository, and the main requarks/wiki repository holds the 3.0 beta, which its README says is not for production use. Ask any quote to separate one-time migration work from these recurring items so you can compare it to your current GitBook invoice.
How DeployOpen scopes and runs the migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Wiki.js instance, its Git storage connection and its database stay in your accounts. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Inventory every GitBook space, its published sites, custom domains and visibility settings before any content moves
- Agree in writing which spaces, pages and attachments are in scope and which stay in GitBook
- Confirm the target Git provider, repository layout, Wiki.js 2.x deployment model and database engine
How we build
- Set up the Git Sync export and verify the Markdown repository is complete against the GitBook space
- Configure Wiki.js Git storage for two-way sync, with authentication and TOTP two-factor settings agreed with you
- Clean GitBook-specific blocks, map navigation and build a redirect table for the docs domain before testing
How we hand over
- Deliver a cutover runbook covering DNS changes, redirects, rollback steps and a sign-off checklist
- Document the Git repository workflow, backup procedure and admin tasks so your team can run the instance
- Hand over the written record of what was migrated, what was dropped and what needs manual review
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after cutover
- Plan Wiki.js version upgrades against the release notes and test them in a staging copy first
- Keep backup and restore checks on a schedule agreed in the written scope
