Fern-specific config needs to be separated from OpenAPI truth.
Provider migration
Migrate from Fern to Sourced
Fern combines docs and SDKs, so the migration needs to preserve both the public docs site and the developer-facing SDK surface. On this page: what to scan in your Fern setup, the migration checks Sourced runs, and a preview of the generated SDK and docs you would get.
Unlimited previews. No credit card required.
01Checks
What to check
Generated SDK import paths and constructors need compatibility checks.
Docs routes, product switches, and versions need redirect coverage.
Custom React components or MDX need replacement components.
02Checks
Migration checklist
Separate fern.config.json + generators.yml from the underlying OpenAPI — Sourced reads OpenAPI directly.
Diff Fern-generated SDK public surfaces against Sourced-generated ones via the compatibility report before package swap.
Map Fern's product/version switcher to Sourced's project structure (one project per API surface).
Replace any MDX/custom React docs components with Markdown that emits cleanly to both HTML and llms.txt.
Plan SDK package version coordination — bump major when public surface changes, keep the previous version published during cutover.
03Details
Why Sourced fits
Sourced keeps SDKs + docs from one OpenAPI workflow, same model as Fern — but with a written compatibility report between any two SDK versions.
Migration report runs on every spec push so you see the breaking-change radius before publishing.
Per-API-project pricing replaces Fern's docs+SDK bundle pricing; no separate generator-count line items.
Honest trade-off: Fern's SDK language coverage (Java, Go, Ruby, C#) outpaces Sourced today. Sourced is TypeScript + Python first-class; other languages are on the roadmap. If you need Java/Go/Ruby SDKs now, stay with Fern.