pages · nav · redirects Documentation sources
Import a documentation archive or supported public repository content. GitHub, GitLab, and Bitbucket are available for public-repository migration input.
A migration should preserve the guidance developers rely on and expose the assumptions a platform encoded—not hide both behind a one-click promise. Doctorine turns supported source material into a reviewable draft and a visible fidelity record.
Platform concepts rarely line up one for one. A useful migration makes those differences inspectable before developers encounter them.
Separate authored guidance, navigation, redirects, examples, API definitions, and SDK configuration from theme chrome and platform-specific metadata.
Bring supported files and configurations into Doctorine, then review what mapped exactly, what degraded, and what still requires a human decision.
Preview routes, redirects, reference, artifacts, and machine surfaces against the candidate release before changing the active portal pointer.
Every import path names its boundary. That is more useful than claiming universal support and discovering the exceptions after launch.
pages · nav · redirects Import a documentation archive or supported public repository content. GitHub, GitLab, and Bitbucket are available for public-repository migration input.
yaml · json · refs Bring an OpenAPI definition when it exists, including multi-file structures. Validation and diagnostics identify structural problems before release.
mapped · degraded · blocked Translate supported configuration from Fern, Stainless, Speakeasy, or ReadMe into a Doctorine draft with explicit mapped, degraded, and unsupported buckets.
Keep the current portal live while the candidate is reviewed. Activate by release identity, preserve the redirect plan, and retain the previous pointer for rollback.
Doctorine does not scrape an arbitrary rendered website back into authored source. Public GitLab and Bitbucket repositories can be migration inputs; ongoing first-class Git sync is currently GitHub. Unsupported vendor behavior remains explicit in the fidelity record.
Bring one representative project. Review the fidelity record, close the real gaps, and switch only when the candidate release is ready.