Made in DeveloperHub
Import from Any Tool with AI
Moving from Docusaurus, MkDocs, Sphinx, GitBook, VitePress, or another tool? Your AI coding agent can do the move for you with the migrate-docs Agent Skill. It converts your pages to DeveloperHub Markdoc, rebuilds your navigation, copies your images, and hands you a folder to import with GitHub Sync.
Your writing is kept as it is. Only the syntax around it changes, and your original docs are never edited.
These have a built-in importer that needs no agent. See Import from Mintlify and Import from Zendesk.
Before You Start
An AI coding agent that supports Agent Skills, such as Claude Code, Cursor, or Codex.
Your docs in a form the agent can read: a folder on your computer, a Git repository, or an export from your current tool. If you have none of these, the agent can read your published site instead, though less structure comes across that way.
A GitHub repository to import the result from. A new, empty private one is fine.
Step 1: Install the Skills
The skill does not come with your agent, so install it first. It ships with two other skills it relies on, so install the whole package.
In Claude Code, run:
In Cursor, Codex, or another agent, run this in a terminal:
Then start a new session in your agent so it picks the skills up. For other ways to install, and how to keep the skills up to date, see Writing Markdoc with AI Agents.
Step 2: Ask Your Agent to Migrate
Open your agent and ask it to move your docs to DeveloperHub, pointing it at where they are:
A repository link, an export file, or the address of your live site works too. In Claude Code, you can also start the skill directly with /dh-skills:migrate-docs.
Tell the agent where to put the result. If you do not, it suggests a new folder next to your docs.
Step 3: Answer Its Questions
The agent looks through your docs first and reports what it found: how many pages, and the sections, versions, and languages they sit in. It then asks, in one go, about anything your current setup does not settle, such as:
Which sections become separate documentation sections, and which stay as groups in one sidebar.
Which versions and languages to bring across.
Whether a blog or release notes become a changelog.
Each question comes with a recommended answer, so you can reply "go with the defaults".
Step 4: Check the First Pages
Before converting everything, the agent converts three to five representative pages and shows them to you. Check that they look right, and tell it what to change. It applies your feedback to the rest of the migration, not just those pages.
Step 5: Review the Result
When it finishes, the agent checks its own output and hands you a folder containing:
Your pages, navigation, and images in the layout GitHub Sync expects.
MIGRATION.md, a report of what was migrated, the choices made, any pages whose address changed, and anything that needs your attention.redirects.txt, a list of redirects from your old page addresses to the new ones.
Read MIGRATION.md before you import. Anything that could not come across exactly is listed there with its file and line, so nothing is lost without you knowing.
Step 6: Import with GitHub Sync
Push the folder to your GitHub repository. It can sit at the root or in a subfolder.
Set up GitHub Sync with that repository. If the folder is in a subfolder, enter it as the Base path.
Set First sync to Import, and click Start sync.
When it finishes, check the Activity tab of the Docs Sync pane for warnings.
A new project starts with sample content: a documentation section with a Getting Started page, and a sample API reference. An import never deletes anything, so this stays next to your docs. Remove it once the import is done. Your agent's handoff notes tell you which parts are safe to delete.
Step 7: Keep Your Old Links Working
When you point your domain at DeveloperHub, paste the contents of redirects.txt into URL Redirects. Links to your old pages, from search engines and other sites, then lead to the same pages on DeveloperHub.
Need help? Visit our community forums or contact us.