Skip to main content

Move the experience without losing the decisions inside it.

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.

Treat migration as a release, not a copy operation.

Platform concepts rarely line up one for one. A useful migration makes those differences inspectable before developers encounter them.

  1. Inventory what carries meaning

    Separate authored guidance, navigation, redirects, examples, API definitions, and SDK configuration from theme chrome and platform-specific metadata.

  2. Import with a mapping record

    Bring supported files and configurations into Doctorine, then review what mapped exactly, what degraded, and what still requires a human decision.

  3. Verify before switching traffic

    Preview routes, redirects, reference, artifacts, and machine surfaces against the candidate release before changing the active portal pointer.

Bring forward the sources Doctorine can verify.

Every import path names its boundary. That is more useful than claiming universal support and discovering the exceptions after launch.

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.

yaml · json · refs

API definitions

Bring an OpenAPI definition when it exists, including multi-file structures. Validation and diagnostics identify structural problems before release.

mapped · degraded · blocked

SDK configuration

Translate supported configuration from Fern, Stainless, Speakeasy, or ReadMe into a Doctorine draft with explicit mapped, degraded, and unsupported buckets.

Cut over with a way back.

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.

  • Compare source inventory with imported pages and navigation.
  • Resolve degraded configuration instead of silently accepting it.
  • Exercise critical public routes, SDK builds, and agent discovery before cutover.
  • Record the activated release and preserve rollback evidence.

Know what the importer does not claim.

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.

Map the migration before changing production.

Bring one representative project. Review the fidelity record, close the real gaps, and switch only when the candidate release is ready.

Plan an assisted migration