
Plenty of APIs are still described in Swagger 2.0, the format that later became OpenAPI 3. The newer versions are more expressive and better supported by modern tools, so migrating is usually worth it.
Swagger Editor reads both, which makes it a good place to check the before and after side by side.
The big structural changes
- Version field.
swagger: "2.0"becomesopenapi: 3.0.3or3.1.0. - Servers.
host,basePathandschemesmerge into aserverslist of full URLs. - Components.
definitions,parameters,responsesandsecurityDefinitionsmove undercomponents, and every$refpath changes with them. - Request bodies. Body and form parameters are replaced by
requestBodywith acontentmap keyed by media type. - Responses. A response schema now sits inside
content, so one response can offer JSON and XML separately. Globalproducesandconsumesdisappear.
Before and after
# Swagger 2.0
parameters:
- in: body
name: book
schema:
$ref: '#/definitions/Book'
# OpenAPI 3
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/Book'
Automated conversion
Converters can do most of the mechanical work in seconds. Run one, open the output in the editor and treat it as a first draft.
Converters cannot know your intent, so watch for duplicated media types, lost examples and file uploads, which change shape in version 3.
3.0 or 3.1?
OpenAPI 3.1 aligns schemas with JSON Schema, replaces nullable: true with a type list such as [string, "null"], and adds webhooks. If your generators and gateways support 3.1, use it.
If any tool in your chain lags behind, 3.0.3 is the safe choice and moving up later is a small step.
A migration checklist
- Convert automatically and fix parser errors.
- Clear every validation error and warning in the editor.
- Compare operation counts and paths with the original.
- Regenerate one client and run its tests against a real server.
- Replace the old file in the repository in a single reviewed change.