Custom templates need an inventory before replacement.
Provider migration
Migrate from OpenAPI Generator to Sourced
OpenAPI Generator is flexible and free, but many teams end up maintaining template forks, custom scripts, and SDK patches by hand. On this page: what to scan in your OpenAPI Generator 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 surface area may change dramatically.
Build scripts and package metadata need migration checks.
Docs previews and launch reports usually need separate infrastructure.
02Checks
Migration checklist
Inventory custom Mustache templates and post-processing scripts — these typically don't transfer; expect a Sourced output that differs in shape.
Run the Sourced compatibility report against your existing published SDK to see the breaking-change radius before customer cutover.
Audit your openapi-generator-cli config and version pin — Sourced emits deterministic output, so the 'reproducible build' problem the CLI sometimes has goes away.
List every patched file in the generated output that your team manually edits — these patches need to become spec changes or Sourced config.
Plan hosted-docs migration separately; OpenAPI Generator teams typically have ad-hoc Redoc/Swagger UI hosting that Sourced replaces wholesale.
03Details
Why Sourced fits
Trades template ownership for a managed pipeline — no more template fork to maintain across openapi-generator-cli version bumps.
SDK + docs + llms.txt + release checks all in one workflow.
Deterministic output (same spec → byte-identical tarball) which OpenAPI Generator sometimes loses across CLI versions.
Honest trade-off: if your team genuinely needs custom template surgery for a non-standard generation requirement, sticking with OpenAPI Generator is the right call.